NetscreenRemote - VPN connects but no datatransfer

[JamesBellaart]

Hi,

Setting up a new Netscreen-Remote VPN to a SSG520.

The NetScreen-Remote connects successfully, but I can not ping or browse anything through the connection.

Using a local user, preshared key, nothing tricky.  I have a untrust to trust policy for Dialup User two way policy set up.  Source Translation is turned on.  The firewall is receiving traffic, but nothing is making it back to the VPN client - as per logs below:

Date/Time | Source | Address/Port | Destination Address/Port | Translated Source Address/Port | Translated Destination Address/Port | Service | Duration | Bytes Sent | Bytes Received | Close Reason

2008-07-16 | 11:48:57 | 192.168.1.108:1205 | 10.51.1.158:80 | 10.51.1.4:4682 | 10.51.1.158:80 | HTTP | 22 sec. | 210 | 210 | Close - AGE OUT

2008-07-16 | 11:47:41 | 192.168.1.108:11264 | 10.51.1.21:512 | 10.51.1.4:4681 | 10.51.1.21:512 | ICMP | 4 sec. | 78 | 78 | Close - RESP

2008-07-16 | 11:47:35 | 192.168.1.108:11008 | 10.51.1.21:512 | 10.51.1.4:4680 | 10.51.1.21:512 | ICMP | 3 sec. | 78 | 78 | Close - RESP

Prior to source translation being enabled it looked like this:

2008-07-16 | 11:19:57 | 192.168.1.108:4096 | 10.51.1.21:512 | 192.168.1.108:4096 | 10.51.1.21:512 | ICMP 62 sec. | 78 | 0 | Close - AGE OUT

2008-07-16 | 11:19:51 | 192.168.1.108:3840 | 10.51.1.21:512 | 192.168.1.108:3840 | 10.51.1.21:512 | ICMP 62 sec. | 78 | 0 | Close - AGE OUT 

Here are the policies I have set up:

From Untrust To Trust, total policy: 1 ID Source Destination Service Action Options Configure Enable Move 2 Dial-Up VPN 10.48.0.0/12 ANY tunnel Logging           From Trust To Untrust, total policy: 2 ID Source Destination Service Action Options Configure Enable Move 3 10.48.0.0/12 Dial-Up VPN ANY tunnel Logging          

Any ideas on how I can get the return traffic going through correctly?

[Kashif-rana]

Hi James,

first of all there is no need to make dialup vpn policy bidirectional becasue as in policy based dialup vpn traffic cannot initiate from trust to untrust. So keep policy only from untrust to trust.

Turn off source translation in dialup vpn policy and try again. What version of screen OS u r using???

can u post ur routing table??

Thanks 

[NaToR]

turn off the source NAT, in the policy and configure the Proxy ID in AutoKey IKE  , these must match with the values of remote client

[JamesBellaart]

Some more info:

We are having difficulty implementing a Netscreen Remote VPN with a new Juniper SSG 520M in a Branch Office. We have an existing SSG-520 in our Datacenter with almost identical config which is working fine.

The config on the Branch Office firewall has been copied from that on the Datacenter so both VPNs are configured identically. The client is a laptop connected via an ADSL router with Netscreen Remote installed and an identity for each VPN/Firewall. Both VPNs connect successfully, the Datacenter VPN works fine, the Branch Office VPN doesn’t.

On the Branch Office VPN when pinging a server on the VPN we can see the traffic in the firewall logs and arriving at the server’s NIC (using wireshark) we can also see the packet leave the server, and a reply is shown in the Firewall log.

The only difference we have found is in the traffic leaving the firewall down the tunnel in the debug logs below.

Data center Firewall: Juniper ScreenOS 5.4.0r1.0

Branch Office Firewall: Juniper ScreenOS 5.4.0r6.0

Debug on return Packets:

Branch Office Firewall

****** 4921596.0: <Trust/ethernet0/0> packet received [60]******
  ipid = 24717(608d), @2e4ae910
  packet passed sanity check.
  ethernet0/0:**BranchOfficeServerIP**/512->**ClientLaptopIP**/11008,1(0/0)<Root>
Not IKE nor NAT-T nor ESP protocol.
  existing session found. sess token 4
  flow got session.
  flow session id 63969
  existing vector list 5-56b1b80.
  skipping pre-frag
  going into tunnel 4000000d.
  flow_encrypt: pipeline.
chip info: PIO. Tunnel id 0000000d
(vn2)  doing ESP encryption and size =64
ipsec encrypt prepare engine done
ipsec encrypt set engine done
ipsec auth done
ipsec encrypt engine released
ipsec encrypt done
        put packet(4a23ac0) into flush queue.
        remove packet(4a23ac0) out from flush queue.

**** jump to packet:**BranchOfficeFWPublicIP**->**ClientADSLPublicIP**
  out encryption tunnel 4000000d gw:**BranchOfficeNextHopIP**
  no more encapping needed
  send out through normal path.
  flow_ip_send: ea4b:**BranchOfficeFWPublicIP**->**ClientADSLPublicIP**,50 => ethernet0/2(112) flag
 0x0, vlan 0
  mac 009069f3747e in session
  **** pak processing end.

Datacenter Firewall - this is working correctly

****** 21816786.0: <Trust/ethernet0/0> packet received [60]******
  ipid = 58583(e4d7), @2e60d910
  packet passed sanity check.
  ethernet0/0:**DataCenterServerIP**/512->**ClientLaptopIP**/14848,1(0/0)<Root>
Not IKE nor NAT-T nor ESP protocol.
  existing session found. sess token 4
  flow got session.
  flow session id 57828
  existing vector list 5-672a650.
  skipping pre-frag
  going into tunnel 4000002c.
  flow_encrypt: pipeline.
chip info: PIO. Tunnel id 0000002c
(vn2)  doing ESP encryption and size =64
ipsec encrypt prepare engine done
ipsec encrypt set engine done
ipsec auth done
ipsec encrypt engine released
ipsec encrypt done
        put packet(49da9c0) into flush queue.
        remove packet(49da9c0) out from flush queue.

**** jump to packet:**DataCenterFWPublicIP**->**ClientADSLPublicIP**
  out encryption tunnel 4000002c gw:**DataCenterNextHopIP**
  no more encapping needed
 flow_send_vector_, vid = 0, is_layer2_if=0
  **** pak processing end.

[Kashif-rana]

The debug output shows that ur return traffic is not passing through tunnel, its passing through physical wan interface. Can u post ur routing table and dialup vpn policies???

Thanks 

[JamesBellaart]

Hi,

Routing table and dialup vpn policy attached.

Thank you for looking at this.

[JamesBellaart]

Still working on this issue.  Using wireshark to look at packets as they hit devices inside the network.

Packets are travelling Client -> VPN tunnel -> Juniper FW -> host ok, the problem is occuring on the return. 

The return packet travels Host -> Juniper FW -> ISP Router -> Next ISP Router -> Loop.

Here is a message from Wireshark showing the Ping echo reply is timing out:

218.101.61.8     10.51.1.205     ICMP     Time-to-live exceeded (Time to live exceeded in transit)

This Traceroute shows that this is the expected result given a packet to that private IP goes out the internet gateway. 

 Tracing route to 192.168.1.108 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  10.51.1.4
  2     1 ms    <1 ms    <1 ms  203.167.224.225
  3     *        *        *     Request timed out.
  4     1 ms     1 ms     1 ms  ge-1-0-0-927.ie1.telstraclear.net [218.101.61.8]

  5     *        *        *     Request timed out.
  6     2 ms     1 ms     1 ms  ge-1-0-0-927.ie1.telstraclear.net [218.101.61.8]

  7  ^C

The Packet arrives at the Host with the clients Private IP as its return address.

Taking a look at the packets, and I have compared packets between our working VPN to our Datacenter and the new VPN to our branch office and I can't see any encapsulation or injection indicating that the packet is a VPN packet, so the only indicator the FW has that the packet needs to be routed back down the VPN tunnel is the source address. 

Is there any setting or route that needs to be added to the SSG520 to tell it to route those packets down the VPN tunnel they came from instead of out the www gateway?

It looks to me like the firewall is not keeping track of sessions correctly.  Since the original post we have upgraded to 6.0.0r5a.0 which has not made a difference.

Message Edited by JamesBellaart on 07-20-2008 08:19 PM

[AndyC]

Hi,

You shouldn't need to add any additional information to tell it to route back down the tunnel as it should be part of the session when the packet came through.

Would be good if you could post your config file.

Also you could do a debug flow basic to see if the firewall is seeing it as being part of the session and what it is doing with it.

From the console (you will need to use something like hyper terminal as you will need to capture text:

get ffilter - check to see if you have any filters set already, if you do unset ffilter to clear

set ffilter dst-ip x.x.x.x (replace x's with destination ip you are pinging down the vpn)

set ffilter src-ip x.x.x.x (replace x's with same IP as dst-ip to give return packet)

clear db

debug flow basic

perform ping from ssl box that fails.

undebug all

You will then need to capture the following text from the command

get db str

Regards

Andy

[JamesBellaart]

Hi,

Debug and config file are attached.

Thanks,

[AndyC · Accepted solution]

Hi,

I have had a look at the config and everything seems good there. Looking at the debug it seems like the ping is getting to the firewall and it is being matched against and existing session and being put back into the VPN.

****** 242103.0: <Trust/ethernet0/0> packet received [60]******
  ipid = 7948(1f0c), @2e564110
  packet passed sanity check.
  ethernet0/0:10.51.1.205/512->192.168.1.108/40962,1(0/0)<Root>
Not IKE nor NAT-T nor ESP protocol.
  existing session found. sess token 4
  flow got session.
  flow session id 127887
  existing vector list 5-710532c.
  post addr xlation: 10.51.1.205->192.168.1.108.
  skipping pre-frag
  going into tunnel 40000014.
  flow_encrypt: pipeline.
chip info: PIO. Tunnel id 00000014
(vn2)  doing ESP encryption and size =64
ipsec encrypt prepare engine done
ipsec encrypt set engine done
ipsec auth done
ipsec encrypt engine released
ipsec encrypt done
        put packet(5f5ab90) into flush queue.
        remove packet(5f5ab90) out from flush queue.

**** jump to packet:xxx.xxx.224.226->125.239.53.75
  out encryption tunnel 40000014 gw:xxx.xxx.224.225
  no more encapping needed
  send out through normal path.
  flow_ip_send: 8a49:xxx.xxx.224.226->125.239.53.75,50 => ethernet0/2(112) flag 0x0, vlan 0
  mac 009069f3747e in session
  **** pak processing end.

Is the remote client behind a NAT device?? If so you might want to enable NAT Traversal and UDP checksum on the VPN configuration under the advance settings of the VPN gateway configuration.

Regards

Andy