Author
Topic: Problems with traffic one way on a route based VPN (Read 15206 times)

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:

- 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:

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.

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).

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.

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!

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?

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.

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.

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.

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.

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 LANtun.71->GW2.0.0.2->VPN1 for DMZtun.72->GW2.0.1.1->VPN2 for LANtun.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?

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!

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!