Screen OS

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?

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 

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

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.

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 

Hi,

 

Routing table and dialup vpn policy attached.

 

Thank you for looking at this.

 

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.

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

Hi,

 

Debug and config file are attached.

 

Thanks,

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

Hi Andy,

 

I've been over the config with a fine tooth comb and it looks fine to me.  Frustratingly we have another FW into our Datacenter with the same config for the VPN which works fine.

 

After comparing the two the only difference I could see was in the debug logs highlighted in red in one of my earlier posts.

 

The set up is  Client Laptop (192.168.1.108) -> ADSL Router (125.239.53.75) -> WWW -> (xxx.xxx.224.226) SSG 520 -> internal network (10.51.1.205)

 

There is NAT at both ends, but enabling NAT Traversal makes no difference (have tried already) and as it is not enabled on the working VPN to our Datacenter FW I don't think it is required.

 

If the return packet is being put back into the tunnel why isnt it arriving at the client?  I don't believe the problem is with the client as the VPN with the Datacenter (10.55.1.0/24) is working with identical setup at the client (and FW).

 

As this has been a fresh install and pretty much configured following instructions from Juniper course material I'm getting a bit stumped.  I have put an ISA Box behind it and can VPN to that with no problems however that adds cost and has some issues supporting some of the SIP protocols I am wanting to run through it so it is not an ideal solution.

Hmmmm, not easy to work out without being able to jump on the box and have the vpn client to test. Have you tried connecting a different laptop running NSRemote to the Branch office using the VPN configuration???? If you haven't give it a go and only create the branch conneciton on NSRemote and not the Datacentre connect to see if that causes a problem .

 

Regards

 

Andy

Hi Andy,

 

I have installed the Netscreen Remote on a clean image, and set up a connection to our branch office.  Same deal - connects, but no traffic gets back to the client - I have confirmed via Wireshark that the ICMP packets are hitting the host inside the network and being sent back.

Doh, it is never easy is it. Not sure what is going on as everything seems to be ok with the config, since it works with your data centre set up NS remote should be ok. The only thing is the version of code difference between the devices, although I have had a look through the release notes and cant see anything in there, might be worth and upgrade to see if that has and effect.

 

Other than that its trying to replicate the situation in a test lab to see what happens. Unfortunately I dont have access to any kit as I have just move to New Zealand so cant try this out for you. Might be a case of raising a JTAC case, if you haven't already.

 

Regards

 

Andy

You could try setting up Xauth on the Dialup vpn and assign a IP address to the client to see if that forces the Firewall to send the traffic down the VPN.

 

Although as you said it should work the way you have it. Might be worth a try though.

 

Andy

Hi Andy,

 

Thanks for you continuing assistance.  We're based in Ellerslie, Auckland if you're really keen to get hands on! 😉

 

Just for comparison I have done a debug on the working DC firewall to look at the same traffic as on the not working one.

 

Attached below along with the original for comparison.

 

 

I have been playing with an L2TP IPSec VPN as well, but I am concerned that if the issue here is routing or session related then I imagine changing the transport / tunnel won't make much difference.

 

Cheers,

James

Hi James,

 

Who do you work for??? I have just moved into Titirangi so not far away, could drop in if you want.

 

Andy

Well after examining those 2 debugs, the only difference was this line on the new FW here:

 

post addr xlation: 10.51.1.205->192.168.1.108.

 

I have enabled NAT Traversal on the gateway on the new FW and now its working - previously I was enabling NAT on the policy, so guess it could have been solved earlier. 

 

Cheers!

Glad that Nat-traversal had solved it, thought it might have helped.

 

Such a small world that your based just down the road

 

Andy