VPN between Netscreen 5XT and Watchguard edge X10e

[Beecky]

Hi,

I'm trying to setup a branch office vpn tunnel between a netscreen 5XT and a Watchguard Edge X10e.
I'm familiar with Watchguard but not with Netscreen.
So far I could condigure the VPN and Phase 2 is initated and completed. I can see that the SA is active, but no traffic goes over the VPN. This is an extract from the netscreen logs.

2006-12-16 10:53:38 info IKE<84.194.173.99> Phase 2 msg ID <46478372>: Completed negotiations with SPI <6f372264>, tunnel ID <5>, and lifetime <3600> seconds/<0> KB.
2006-12-16 10:53:38 info IKE<84.194.173.99> Phase 2 msg ID <46478372>: Responded to the peer's first message.

But the VPN monitor status shows as follows

VPN_to_x 00000005 28/29 84.194.173.99 AutoIKE Active Down

There must be something that I forgot, but I don't know what.

Thanks for your help

Greetz Beecky

 

[Packet7]

Hi,

OK, did you create a basic rule of a VPN rule? Now that the route has been added and VPN is up, a vpn rule is required to encrypt the data. Create or modified rules from the trust to untrust and untrust to trust. From the action drop down menu, select "Tunnel". Also select the proper proper VPN from the Tunnel/VPN menu. Just make sure the objects used in the policy match the remote side. In a policy based VPN, the proxy id is derived during from the policy, not like route based where it's defined in the proxy id section. Keep me posted.

Rgds,

John

 

[Beecky]

John,

I have a a rule from trust to untrust that says
Lan - Lan_Arlon action tunnel log enabled
and I have a rule from untrust to trust that says
Lan_Arlon - Lan action tunnel log enabled.
Both rules are above the normal policy
The service is any and the vpn tunnel is VPN_to_Arlon
The proxy id's are filled in correctly.
Somehow I have my doubts on the static route that we have added previously.
* 192.168.119.0/24 192.168.2.1 untrust S 1 Root
I don't think that we need this route.

rgds

Beecky

 

[Packet7]

Hi,

Is the VPN bound to a tunnel interface? If so, the route is needed to send the traffic via the correct interface. Since this is a policy based VPN, I would make sure the VPN is not bound to the Tunnel Int. Once that is done, remove the route. Upon completion, paste the output of the "get sa". I want to make sure the VPN is "Active" and that the VPN Monitor is disabled ("-"). I have come across issues where the tunnel is Active, but the VPN monitor downs phase two. I apologize for all the back and forth. We'll get it. BTW, once the changes have been made, can you look at the logs on the remote side? It's best to have info from both sides of the tunnel in order to pin point the problem. Keep me posted.

Rgds,

John

 

[Beecky]

John,

The vpn is not bound to a tunnel interface. Like you already said, there is no need to use tunnel interfaces in policy based vpn.
I have removed the route. This is what is left in the routing table.
ns5xp-> get route
untrust-vr (0 entries)
--------------------------------------------------------------------------------
C - Connected, S - Static, A - Auto-Exported, I - Imported, R - RIP
trust-vr (3 entries)
--------------------------------------------------------------------------------
ID IP-Prefix Interface Gateway P Pref Mtr Vsys
--------------------------------------------------------------------------------
* 4 0.0.0.0/0 untrust 192.168.2.1 C 0 1 Root
* 2 192.168.2.0/24 untrust 0.0.0.0 C 0 0 Root
* 1 192.168.1.0/24 trust 0.0.0.0 C 0 0 Root


This is the result of the get sa note that the monitor is inactive.
ns5xp-> get sa
total configured sa: 2
HEX ID Gateway Port Algorithm SPI Life:sec kb Sta PID vsys
00000005< 84.194.173.119 500 esp:3des/md5 55cce887 3599 unlim A/- 29 0
00000005> 84.194.173.119 500 esp:3des/md5 55b7078d 3599 unlim A/- 30 0
00000007< 83.134.210.70 500 esp:3des/md5 55cce818 expir unlim I/I 31 0
00000007> 83.134.210.70 500 esp:3des/md5 76cd8dcf expir unlim I/I -1 0

This what I have in the WG vpn log.
BUNDLE (0)(Tunnel) refcnt = 2
84.194.173.119(71dc0797)(ESP): (Mature) refcnt(1)SRC:217.136.182.75 PROXY:217.136.182.75
AUTH: MD5-HMAC Authentication
CRYPT: 3DES-CBC Encryption
Create Time: 000000000001574a First Use: 0000000000000000
Bytes: 0000000000000000 Packets: 00000000
Soft Timeouts: After First Use: 000000cef
Hard Timeouts: After First Use: 000000e0f
BUNDLE (0)(Tunnel) refcnt = 2
84.194.173.119(0e640798)(ESP): (Mature) refcnt(1)SRC:217.136.182.75 PROXY:217.136.182.75
AUTH: MD5-HMAC Authentication
CRYPT: 3DES-CBC Encryption
Create Time: 0000000000015766 First Use: 0000000000000000
Bytes: 0000000000000000 Packets: 00000000
Soft Timeouts: After First Use: 000000d5b
Hard Timeouts: After First Use: 000000e0f
BUNDLE (0)(Tunnel) refcnt = 1
217.136.182.75(55cce892)(ESP): (Mature) refcnt(1)SRC:84.194.173.119 PROXY:84.194.173.119
AUTH: MD5-HMAC Authentication
CRYPT: 3DES-CBC Encryption
Create Time: 0000000000015766 First Use: 0000000000000000
Bytes: 0000000000000000 Packets: 00000000
Soft Timeouts: After First Use: 000000d37
Hard Timeouts: After First Use: 000000e0f

I don't know if you are familiar with wg, the the wg soho log is pretty basic and you don't see anything in the logging.
For your information. I'm testing the vpn now with a soho instead of an edge because the edge is now installed at the customer site, so I'm using a soho for test purpose.

regards

Beecky

 

[Packet7]

Can you test from a PC on the Netscreen side? If so, try the following:

set ff src-ip x.x.x.x ip-proto 1 (x.x.x.x = IP of test machine)
debug flow basic
clear db
send a ping test from test machine to internal IP on remote LAN
undebug all
get db str
paste results

Since the VPN is up, we have to identify what the NS is doing with the traffic. If it's not encrypting the traffic, the debug should help us identify why. BTW, can you list out the rule objects in your next reply. Thanks.

Rgds,

John

 

[Beecky]

****** 28588.0: <Trust/trust> packet received [60]******
ipid = 21879(5577), @000bb84e
packet passed sanity check.
trust:192.168.1.2/64307->192.168.119.1/512,1(8/0)<Root>
chose interface trust as incoming nat if.
search route to (192.168.1.2->192.168.119.1) in vr trust-vr for vsd-0/flag-0/ifp-null
route 192.168.119.1->192.168.2.1, to untrust
routed (192.168.119.1, 0.0.0.0) from trust (trust in 0) to untrust
policy search from zone 2-> zone 1
Permitted by policy 30
No src xlate choose interface untrust as outgoing phy if
no loop on ifp untrust.
session application type 0, name None, timeout 60sec
service lookup identified service 0.
existing vector list 5-168d520.
Session (id:767) created for first pak 5
--- more ---
cache mac in the session
flow got session.
flow session id 767
post addr xlation: 192.168.1.2->192.168.119.1.
going into tunnel 40000005.
flow_encrypt: vector=664ddc.
chip info: PIO. Tunnel id 00000005
(vn2) doing ESP encryption and size =64
ipsec encrypt prepare engine done
ipsec encrypt set engine done
ipsec encrypt engine released
ipsec encrypt done
out encryption tunnel 40000005 gw:192.168.2.1
no more encapping needed.
packet send out to 0001710113e4 through untrust
****** 28589.0: <Trust/trust> packet received [60]******
ipid = 21883(557b), @000bd84e
packet passed sanity check.
trust:192.168.1.2/64563->192.168.119.1/512,1(8/0)<Root>
chose interface trust as incoming nat if.
search route to (192.168.1.2->192.168.119.1) in vr trust-vr for vsd-0/flag-0/ifp-null
route 192.168.119.1->192.168.2.1, to untrust
--- more ---
routed (192.168.119.1, 0.0.0.0) from trust (trust in 0) to untrust
policy search from zone 2-> zone 1
Permitted by policy 30
No src xlate choose interface untrust as outgoing phy if
no loop on ifp untrust.
session application type 0, name None, timeout 60sec
service lookup identified service 0.
existing vector list 5-168d520.
Session (id:270) created for first pak 5
cache mac in the session
flow got session.
flow session id 270
post addr xlation: 192.168.1.2->192.168.119.1.
going into tunnel 40000005.
flow_encrypt: vector=664ddc.
chip info: PIO. Tunnel id 00000005
(vn2) doing ESP encryption and size =64
ipsec encrypt prepare engine done
ipsec encrypt set engine done
ipsec encrypt engine released
ipsec encrypt done
out encryption tunnel 40000005 gw:192.168.2.1
--- more ---
no more encapping needed.
packet send out to 0001710113e4 through untrust
****** 28591.0: <Trust/trust> packet received [128]******
ipid = 21886(557e), @000bf84e
packet passed sanity check.
trust:192.168.1.2/1024->192.168.1.100/4340,1(0/0)<Root>
existing session found. sess token 2
flow got session.
flow session id 1043
existing vector list 0-13067a0.
post addr xlation: 192.168.1.2->192.168.1.100.
packet is for self, copy packet to self
copy pakcet to us.
processing packet through normal path.
packet passed sanity check.
self:192.168.1.100/4440->192.168.1.1/1024,1(8/0)<Root>
policy id = 320000(Deny), tunnel = 0
search route to (0.0.0.0->192.168.1.1) in vr trust-vr for vsd-0/flag-2000/ifp-trust
route 192.168.1.1->0.0.0.0, to trust
routed 192.168.1.1 next hop 192.168.1.1, from self
existing vector list 0-13067a0.
processing packet from self
--- more ---
route to 192.168.1.1
arp entry found for 192.168.1.1
nsp2 wing prepared, ready
flow got session.
flow session id 702
skip ttl adjust for packet from self.
post addr xlation: 192.168.1.100->192.168.1.1.
packet send out to 000cf1c745a1 through trust
****** 28591.0: <Trust/trust> packet received [60]******
ipid = 21887(557f), @000a104e
packet passed sanity check.
trust:192.168.1.2/64819->192.168.119.1/512,1(8/0)<Root>
chose interface trust as incoming nat if.
search route to (192.168.1.2->192.168.119.1) in vr trust-vr for vsd-0/flag-0/ifp-null
route 192.168.119.1->192.168.2.1, to untrust
routed (192.168.119.1, 0.0.0.0) from trust (trust in 0) to untrust
policy search from zone 2-> zone 1
Permitted by policy 30
No src xlate choose interface untrust as outgoing phy if
no loop on ifp untrust.
session application type 0, name None, timeout 60sec
service lookup identified service 0.
--- more ---
existing vector list 5-168d520.
Session (id:707) created for first pak 5
cache mac in the session
flow got session.
flow session id 707
post addr xlation: 192.168.1.2->192.168.119.1.
going into tunnel 40000005.
flow_encrypt: vector=664ddc.
chip info: PIO. Tunnel id 00000005
(vn2) doing ESP encryption and size =64
ipsec encrypt prepare engine done
ipsec encrypt set engine done
ipsec encrypt engine released
ipsec encrypt done
out encryption tunnel 40000005 gw:192.168.2.1
no more encapping needed.
packet send out to 0001710113e4 through untrust
****** 28592.0: <Trust/trust> packet received [60]******
ipid = 21890(5582), @000a284e
packet passed sanity check.
trust:192.168.1.2/65075->192.168.119.1/512,1(8/0)<Root>
chose interface trust as incoming nat if.
--- more ---
search route to (192.168.1.2->192.168.119.1) in vr trust-vr for vsd-0/flag-0/ifp-null
route 192.168.119.1->192.168.2.1, to untrust
routed (192.168.119.1, 0.0.0.0) from trust (trust in 0) to untrust
policy search from zone 2-> zone 1
Permitted by policy 30
No src xlate choose interface untrust as outgoing phy if
no loop on ifp untrust.
session application type 0, name None, timeout 60sec
service lookup identified service 0.
existing vector list 5-168d520.
Session (id:464) created for first pak 5
cache mac in the session
flow got session.
flow session id 464
post addr xlation: 192.168.1.2->192.168.119.1.
going into tunnel 40000005.
flow_encrypt: vector=664ddc.
chip info: PIO. Tunnel id 00000005
(vn2) doing ESP encryption and size =64
ipsec encrypt prepare engine done
ipsec encrypt set engine done
ipsec encrypt engine released
--- more ---
ipsec encrypt done
out encryption tunnel 40000005 gw:192.168.2.1
no more encapping needed.
packet send out to 0001710113e4 through untrust
existing vector list 0-13067a0.
existing vector list 0-13067a0.
existing vector list 0-13067a0.
existing vector list 0-13067a0.
****** 28595.0: <Trust/trust> packet received [128]******
ipid = 21946(55ba), @000a604e
packet passed sanity check.
trust:192.168.1.2/1024->192.168.1.100/4540,1(0/0)<Root>
existing session found. sess token 2
flow got session.
flow session id 752
existing vector list 0-13067a0.
post addr xlation: 192.168.1.2->192.168.1.100.
packet is for self, copy packet to self
copy pakcet to us.
processing packet through normal path.
packet passed sanity check.
self:192.168.1.100/4640->192.168.1.1/1024,1(8/0)<Root>
--- more ---
policy id = 320000(Deny), tunnel = 0
search route to (0.0.0.0->192.168.1.1) in vr trust-vr for vsd-0/flag-2000/ifp-trust
route 192.168.1.1->0.0.0.0, to trust
routed 192.168.1.1 next hop 192.168.1.1, from self
existing vector list 0-13067a0.
processing packet from self
route to 192.168.1.1
arp entry found for 192.168.1.1
nsp2 wing prepared, ready
flow got session.
flow session id 1954
skip ttl adjust for packet from self.
post addr xlation: 192.168.1.100->192.168.1.1.
packet send out to 000cf1c745a1 through trust
****** 28599.0: <Trust/trust> packet received [128]******
ipid = 21994(55ea), @000a984e
packet passed sanity check.
trust:192.168.1.2/1024->192.168.1.100/4740,1(0/0)<Root>
existing session found. sess token 2
flow got session.
flow session id 395
existing vector list 0-13067a0.
--- more ---
post addr xlation: 192.168.1.2->192.168.1.100.
packet is for self, copy packet to self
copy pakcet to us.
processing packet through normal path.
packet passed sanity check.
self:192.168.1.100/4840->192.168.1.1/1024,1(8/0)<Root>
policy id = 320000(Deny), tunnel = 0
search route to (0.0.0.0->192.168.1.1) in vr trust-vr for vsd-0/flag-2000/ifp-trust
route 192.168.1.1->0.0.0.0, to trust
routed 192.168.1.1 next hop 192.168.1.1, from self
existing vector list 0-13067a0.
processing packet from self
route to 192.168.1.1
arp entry found for 192.168.1.1
nsp2 wing prepared, ready
flow got session.
flow session id 607
skip ttl adjust for packet from self.
post addr xlation: 192.168.1.100->192.168.1.1.
packet send out to 000cf1c745a1 through trust

 

[Packet7]

OK, everything looks OK on the NS side. What is 192.168.2.1? Is there a way to check the remote side or debug inbound VPN access on the WG end? Let me know.

Rgds,

John

 

[Beecky]

John,

192.168.2.1 is the internal IP of the internet router. This router does NAT. On the LAN interface of the router I have 192.168.2.1 and the untrust IP of the NS is 192.168.2.2.
There is not very mug to debug on the WG site, because of the poor logging.
NAT shouldn't be the issue either because I can connect without any problems with my mobile user client.

Rgds

 

[Packet7]

Hi,

OK, if we can't obtain any info from the WG, we'll need to try and capture the traffic before and after it enters the WG. Are you familiar with Ethereal? If so, try and capture traffic outside and inside the Firewall. You can filter the external inbound traffic with the IP address of the Netscreen. When capturing the traffic inside the WG LAN, run a ping from the NS side to a host on the WG LAN. This will help us determine if the packets are making it across the tunnel. Sometimes, problems exist with the return path. Once you confirm that the inbound IPSEC packets are arriving at your WG from the NS, you can move to the inside of your LAN.

Hope this helps.

Rgds,

John

 

[Beecky]

Hi John,

Good idea. I always ask my customers to take ethereal captures, and now I forgot it for myself ...(stupid)
I will try to take some captures, but I can oly take them on the trusted site.

I'll keep you posted

rgds

Beecky

 

[Beecky]

No luck with the captures, there is no traffic comming out of the tunnel. I will setup a syslog server and enable the hidden IKE trace in the watchguard. I keep you posted

Beecky

 

[Beecky]

John,

No clear signs in the logging, and in the packet captures I don't see traffic in the tunnel.
We will replace the netscreen with another WG.

rgds

Beecky

 

[Packet7]

Were you able to capture incoming packets into the WG? In the past, I've connected a hub int between the router and Firewall so I could capture the inbound traffic before reaching the Firewall. I'm guessing you tried to capture traffic on the internal side of the WG. Let me know how you make out. Cheers.

Rgds,

John

 

[Beecky]

John,

It's not possible to take captures on the inside because the edge has an inbound switch. Placing a hum on the external could be usefull, allthoug the traffic that you see there is encrypted so that wouldn't make sence either.

rgds

Beecky

 

[Packet7]

Hello,

Actually, since we have our hands tied witht he WG, we need to see if the encrypted ICMP packets are reaching your WG. If so, we would then look to see if they are being decrypted and switched out on the local LAN. Since I'm not familiar with WG, I really don't know what else to try.

We could try applying a flow filter on the NS and run a debug on traffic initiating at the WG. This should help us understand if the WG is doing it's job.

Rgds,

John