Topic: Problems with traffic one way on a route based VPN

[lstoll]

Hi All,
   I currently have a route based VPN set up from a remote location to the datacenter, and are having some problems with it. Traffic from the remote location to the datacenter is fine - I can VNC/SSH/RDC to machines etc, however any traffic initiated from the datacenter to the remote location doesn't work. If I set a deny policy for the traffic with log I see this:

==============================================================================================
Date       Time       Duration Source IP        Port Destination IP   Port Service  SessionID
Reason                         Xlated Src IP    Port Xlated Dst IP    Port ID
==============================================================================================
2008-04-01 22:43:22    0:00:00 172.16.105.30   21772 172.16.2.100      512 ICMP     0
Traffic Denied                 0.0.0.0             0 0.0.0.0             0
2008-04-01 22:43:17    0:00:00 172.16.105.30   21516 172.16.2.100      512 ICMP     0
Traffic Denied                 0.0.0.0             0 0.0.0.0             0


- showing that its being translated to 0.0.0.0 , which is strange. I then removed that and created a policy to permit any from trust to the vpn zone, and nothing shows up in the log for that rule. Doing a little more troubleshooting shows this:

RETURN PACKETS FOR TRAFFIC FROM REMOTE TO DATACENTER:

****** 1851433.0: <Trust/redundant1> packet received [52]******
  ipid = 22736(58d0), @1d5e2114
  packet passed sanity check.
  redundant1:172.16.105.30/5900->172.16.2.100/53080,6<Root>
  existing session found. sess token 4
  flow got session.
  flow session id 46897
  vsd 0 is active
  tcp seq check.
  post addr xlation: 172.16.105.30->172.16.2.100.
  going into tunnel 4000004f.
  flow_encrypt: pipeline.
chip info: DMA. Tunnel id 0000004f
(vn2)  doing ESP encryption and size =56
ipsec encrypt prepare engine done
ipsec encrypt set engine done
ipsec encrypt engine released
ipsec encrypt done
   put packet(4212d38) into flush queue.
   remove packet(4212d38) out from flush queue.

Which looks fine. However,

TRAFFIC FROM DATACENTER TO REMOTE:

****** 1851433.0: <Trust/redundant1> packet received [60]******
  ipid = 22733(58cd), @1d565114
  packet passed sanity check.
  redundant1:172.16.105.30/22284->172.16.2.100/512,1(8/0)<Root>
  no session found
  flow_first_sanity_check: in <redundant1>, out <N/A>
  chose interface redundant1 as incoming nat if.
  flow_first_routing: in <redundant1>, out <N/A>
  search route to (redundant1, 172.16.105.30->172.16.2.100) in vr trust-vr for vsd-0/flag-0/ifp-null
  [ Dest] 15.route 172.16.2.100->172.16.2.100, to tunnel.3
  routed (x_dst_ip 172.16.2.100) from redundant1 (redundant1 in 0) to tunnel.3
  policy search from zone 2-> zone 101
 policy_flow_search  policy search nat_crt from zone 2-> zone 101
  RPC Mapping Table search returned 0 matched service(s) for (vsys Root, ip 172.16.2.100, port 62543, proto 1)
  No SW RPC rule match, search HW rule
  Permitted by policy 99
  No src xlate ## 2008-04-01 22:43:33 : NHTB entry search not found: vpn none tif tunnel.3 nexthop 172.16.2.100
  packet dropped, no way(tunnel) out

Shows the packet being dropped - and I can't make sense why

Any ideas? Driving me nuts.

[The Invincible]

You have more than one phase 2, destined to different locations, binded to tunnel3 right?

Can you paste the config? I will give you the solution

Cheers,

[screenie.]

He I quote :

"showing that its being translated to 0.0.0.0 , which is strange"

This isn't strange. a deny policy allways shows this, indicating no translation occurs.

[lstoll]

You have more than one phase 2, destined to different locations, binded to tunnel3 right?

Can you paste the config? I will give you the solution

Cheers,

I like the way you talk! Yep, three phase two's, on tunnel.3 . Here's the parts of the config that I think are relevant:

set vpn "trust-lincs_home" gateway "lincs_home-gw" no-replay tunnel idletime 0 sec-level standard
set vpn "trust-lincs_home" id 79 bind interface tunnel.3
set vpn "dmz-lincs_home" gateway "lincs_home-gw" no-replay tunnel idletime 0 sec-level standard
set vpn "dmz-lincs_home" id 76 bind interface tunnel.3
set vpn "oobmgmnt-lincs_home" gateway "lincs_home-gw" no-replay tunnel idletime 0 sec-level standard
set vpn "oobmgmnt-lincs_home" id 81 bind interface tunnel.3
set vpn "trust-lincs_home" proxy-id local-ip 172.16.105.0/24 remote-ip 172.16.2.0/24 "ANY"
set vpn "dmz-lincs_home" proxy-id local-ip 172.16.106.0/24 remote-ip 172.16.2.0/24 "ANY"
set vpn "oobmgmnt-lincs_home" proxy-id local-ip 172.16.107.0/24 remote-ip 172.16.2.0/24 "ANY"
set ike gateway "lincs_home-gw" address 60.x.x.x Main outgoing-interface "redundant3" preshare "xxxxxxx" sec-level standard
set interface tunnel.3 ip unnumbered interface redundant3
set zone id 101 "linc-zone"
set interface "tunnel.3" zone "linc-zone"
set policy id 99 from "Trust" to "linc-zone"  "Any" "Any" "ANY" permit log
set policy id 75 from "linc-zone" to "Trust"  "172.16.2.0/24" "172.16.105.0-LAN" "ANY" permit log

Let me know if you need anything else. Thanks heaps!

[screenie.]

when you bind more then 1 vpn to a tunnel interface you've got to deal with Next Hob Tunnel Binding. It's sonething like a routing table for VPN's. When you peer with Netscreen 5.0 or above it should be filled automaticly. If you tunnel with third parties you should add info staticly. Basicly you just say thar nexthop x.x.x.x is to be found using vpn yyyy. The nexthop should correspond to the nexthop from the routing table. In gui you'll find a NHTB tab on tunnel interface.

[lstoll]

when you bind more then 1 vpn to a tunnel interface you've got to deal with Next Hob Tunnel Binding. It's sonething like a routing table for VPN's. When you peer with Netscreen 5.0 or above it should be filled automaticly. If you tunnel with third parties you should add info staticly. Basicly you just say thar nexthop x.x.x.x is to be found using vpn yyyy. The nexthop should correspond to the nexthop from the routing table. In gui you'll find a NHTB tab on tunnel interface.

Thanks for that - I'm not sure how to apply this to my environment though, Basically I have two locations - one location has one network, and the location with the SSG has 3 - So I've created a single gateway, 3 vpn's (one with a proxy ID for each net), and set them on the one tunnel interface. The tunnel interface is unaddressed, and the route points to the tunnel - and has no next hop address. So I'm not too sure how to set up NHTB.

I also tried creating a tunnel interface for each VPN, and using source interface routing on each of the redundant interfaces to push it down the appropriate tunnel - but that didn't seem to work. If I set a normal static route down one of the tunnels it works for that net, but not the others (obviously.. but proves the tunnels are up).

Any advice? Thanks in advance, this is doing my head in.

Linc.

[screenie.]

Calm down, don't panic!! 

What I did in a simular situation was simply add a fake gateway adress to the route and ofcourse specify the tunnel interface. In the tunnel interface I used this adres in the NHTB setting and this worked. If your talking to a policy based VPN, you'll be ok with this. Nothing will be done with the nexthop address but to use it for Routing to the right VPN.

[lstoll]

Great, thanks! Thats got me very close - close enough that its getting the job done, so I'm happy.

Only issue is that there is one remote network, and 3 behind the SSG - So I can only set the NHTB for one VPN at a time (because there is only one route to the remote location for 3 vpns). That leaves all traffic originating from the remote location working to all net's behind the SSG, but only one of the nets behind the SSG can initiate the connection. This is good enough for what I need now, but is there any way around this, for future reference?

Thanks heaps again screenie, you've got me up and going and I'm very happy - I owe you a beer!

Linc.

[screenie.]

Where do I get that beer ?

[ajaydand65]

I am facing a similar situation. My HO has Juniper SSG320 with 2 subnets - 192.168.1.0/24 & 172.20.0.0/28 and the remote end has Cisco-Linksys RV082 with 1 subnet - 192.168.2.0/24. VPN Tunnels are up and running but my route-based VPN is allowing traffic from Remote to HO, but not vice-versa i.e. Remote end users can access resources on both subnets in HO, but HO cannot access Remote LAN. I am planning to shift this over to Policy based VPN with the solution that Screenie has suggested (if this works, I too owe you a beer!). But one challenge. HO has 2 ISPs and I _must_ use them for fallback VPN. How do I achieve this in Policy Based VPN? Essentially, I am not sure, if the Juniper box would allow creating 2 policies with same source and dest but using 2 different tunnels, and also how do i set up the priorities? I can define 2 routes with different metrics to the same remote subnet using the 2 different tunnel interfaces, but would that work?

[screenie.]

That wouldn't work, because only the first policy would be hit. What comes to my mind using a vpn group. I never tried it myself but as long as the cisco supports ike heart beat it should work I think. Normally You would use it to move the von from one location to another, with the same addresses. I think the backup is kept inactive so this is what i suggest:

configure two vpn's on the the HO side to the remote location. Both have the same remote gateway ofcourse (the public address of the cisco). Enable ike heartbeat on them. place both vpn's in a vpn group. Or use DPD as failover method.

A description of VPN groups is here (page 309 and furher) http://www.juniper.net/techpubs/software/screenos/screenos6.2.0/ce_v5.pdf. Again: all theory, no guarantees (:-

I'm not sure you can configure the cisco to support this, same problem maybe, only the first VPN hits. Don't know enough about ios to advice you on this.

Please keep me posted, interesting problem!

[ajaydand65]

Thanks Screenie. Do you think, using the Multiple Proxy ID feature in v6.3 help in this scenario? Then it would obviate the need for NHTB and that would let my route-based VPN work? Also, in a policy based VPN scenario, is it possible to decouple the tunnel interface from the outgoing interface? If that is possible, then the tunnel can simply take the outgoing interface determined by the routing table.

[screenie.]

I think the bigest problem is on the cisco side. Multple proxy id's will work I think. But does the cisco allows two vpn's to the same privater addresses?

[ajaydand65]

No, Cisco does allow me to define a redundant gateway IP, in the same VPN configuration. So, that is not the problem. The problem I am facing is because my version is 6.2, I do not have the liberty to define multiple proxy IDs. You see, actually, on the HO end, there are 2 subnets that the remote end has to access. I have created 2 tunnel interfaces, bound to the 2 respective ISP addresses. However, since there are multiple tunnels (1 for each subnet) through the same TI, NHTB has to come into picture, and that's where things get complicated. And as you pointed out, policy based VPNs would hit the first policy, so that wouldn't help me with redundant gateways. The only possible solution I can see as of now, is to upgrade to v6.3, and use multiple proxy IDs through the same VPN. However, would that allow me to skip the NHTB part? That's where I am not sure. Unless we can somehow decouple the TI and the outgoing interface, policy based VPNs are not the answer in my scenario. I am planning to do the upgrade once I get the go ahead for the downtime from the customer. If you can think of something else, please do post. Thanks for your suggestions.

[screenie.]

The NHTB can't be a problem I think. You can set a (fake if needed) next hop in the routing table. Then configure static NHTB entries on the tunnel interface. Same next-hop address and the correct vpn. In 6.2 you can just configure 2 phase 2's over the same phase 1. That should work as well.

[ajaydand65]

Here's what I did:

I set 4 routes:
192.168.2.0/24->GW2.0.0.1->tun.71->metric 1
192.168.2.0/24->GW2.0.0.2->tun.71->metric 1
192.168.2.0/24->GW2.0.1.1->tun.72->metric 10
192.168.2.0/24->GW2.0.1.2->tun.72->metric 10

I have set up 2 tunnels - 71, 72 for redundant ISP. And since I have 2 subnets - 192.168.1.0/24 for LAN & 172.20.0.0/28 for DMZ,

I set the NHTB like this:
tun.71->GW2.0.0.1->VPN1 for LAN
tun.71->GW2.0.0.2->VPN1 for DMZ
tun.72->GW2.0.1.1->VPN2 for LAN
tun.72->GW2.0.1.2->VPN2 for DMZ

I am able to ping from 192.168.1.x network, but not from 172.20.0.x network. Debug tells me that the NHTB route that is being taken is through 2.0.0.1, whereas actually it should take the route through 2.0.0.2.

How can I force the route through 2.0.0.2? Do you think creating 4 Tunnel Interfaces, instead of 2 (1 for each subnet/ISP combo) should do the job?

[ajaydand65]

I am attaching a diagram of my setup to help understand it better.

[screenie.]

Did you configure static NHTB entries? If think creating two seperated tunnels can work, but use the same phase 1!

[ajaydand65]

Thanks for the response Screenie. Unfortunately, even that does not work. With the same tunnel for both HO subnet, I am not allowed to specify different NHTB gateways for the same remote subnet. And even when I created separate tunnels with same phase 1, it only recognizes the first configured NHTB route, and hence it tries to push the outgoing traffic through the tunnel bound to that route. So in effect, I can only get one HO subnet to talk to the remote subnet in either of the case. Drats! There must be a better way to handle this. I get the same results, even after upgrading from 6.2 to 6.3. Moreover, strangely, I cannot define multiple proxy IDs in v6.3 with the same remote ID!!! It has to also be different! This is surely a case of flawed logic!

[ajaydand65]

Ok. Finally got it to work. I had to go the Multiple Proxy ID route. I must have overlooked something, when I reported it as not working earlier. But now it is working fine. Thanks to all for support, especially Screenie. The beer is still on, if you're in my part of the world!