Screen OS

active route failover ns204/208

I have ten remote sites with two internet connections each. I use virtual routers so that both connections are up and have active gateways at the same time. If one connection goes down, interface monitoring marks the default route inactive and the second default route with metrc ten takes over and routes traffic to the next vr (usually untrust-vr)

At remote site this works perfect.

At central site not so much. I have two tunnels: tunnel.1 and tunnel.2. Tunnel.1 has VPNS for all 10 remote sites primary ISP. tunnel.2 has VPNs for all 10 remotes sites secondary ISP. I then created two route for each site as show below

*    10.2.7.0/24    10.2.7.1    tunnel.1    metric:1
     10.2.7.0/24    10.2.7.1    tunnel.2    metric:10

normally if site looses primary connection primary vpn will become inactive. but the route for tunnel.1 does not become inactive. it stays active even though the vpn is down :(:(:( so i end up manually maintaining routes to keep things going.

What do i need to do to mark the route inactive when VPN is down?

Strange thing is with some sites, it works as anticipated and others (the ones that complain the most) it doesnt. I think it has something to do with having multiple vpns on a single tunnel which leaves the tunnel interface status as 'ready' instead of up or down, but i cant nail down exactly how this is happening so i can get my failover to failover properly

I hope everything i typed makes sense. Any help you can provide would be greatly appreciated.

THANKS

Hi,

 

You use the same IP as the next hop (gateway) in both routes and this IP is reachable through both tunnels. That's why this does not work. You should use different IPs. The best choice is the IP of the remote tunnel interface. If you configure the first route with the IP of  the tun.1 on the remote GW and the second route with the IP of the tun.2 on the remote GW, this would work. With other words: gateway 1 must be reachable through VPN 1 only and gateway 2 - through VPN 2 only. Also check the Untrust-to-Untrust policy to avoid any ICMP access through one tunnel to the IP of the tunnel interface of the second tunnel (and vise versa).

Do not forget to edit NHTB tables.

Please also read KB15387 and KB6221.

 

Kind regards,

Edouard

What i had done was set the route with different metrics as described in in a KB article from the juniper site. I will post the exact KB# later since i do not have access to my work PC at the moment.

 

Is this procedure incorrect? I have been using it for some time and even set two default routes using the same technique and it works fine when i have interface monitoring enabled. Primary ISP goes down and monitoring then marks the interface as logically down. The default route becomes inactive and the secondary default route then takes over routing traffic to the untrust-vr and out to the Backup ISP from there. With VPNs interfaces that have more than one destination VPN this does not happen consistently. For some remote sites it works perfect. for others it is hit or miss.

 

Beacuse the remote tunnel interface IP is the same as the LAN ip of the remote network i use that IP as the next hop in the route statement. If this too is not the best way to do it, i am willing to adjust my techniques to better suit the capabilities of the equipment deployed.

 

Thanks for you input. Let me know if there is anything else in my setup i should be modifying or adjusting to help make this work better.

Hi,

 

You may want to test VPN monitor without a destination IP.  It's my understanding this will bring down any route that is pointed at the bound tunnel interface when the SA is "down" or "inactive".  I've come across scenarois where VPN monitoring with destination IP's resulted in active routes that should be down, especially when using multiple VPN's.  I agree with what was already posted, just thought this may help.

 

John

Hi,

 

If VPN Monitoring is configured without a destination IP, ScreenOS uses the remote gateway IP per default but sends ICMP packets into the tunnel. VPN Monitoring, as a method to manage static routes, works fine both in a NHTB and in a non-NHTB environment. If multiple VPNs are terminated at a single tunnel interface (NHTB case), it would be a disasterious solution to bring this interface and all assosiated VPNs down, as soon as one of the SAs has failed. The tunnel interface stays up but specific route is deactivated, provided that the IP, used as the gateway, is not reachable anymore. I prefer to use the remote tunnel interface IPs for this.

 

Kind regards,

Edouard

I do have VPN monitoring enabled for all my Autokey IKEs. I set the source interface and destination interface as deafault so in theory it should work as i anticipated. And for the most part it works for majority of my VPn tunnels. Its just a handful of site out of site remote locations where it just doesnt do what it is supposed to.

 

 

I will remove the vpn setting and reconfigure it just to make sure i didnt make a typo anywhere and wait for the site ISP to failover. Hopefully with all the info you have provided i can get this working properly again.

 

thanks

 

The problem was VPN monitoring without the dstination IP. I understand that without it monitors the remote tunnel interface IP, but since i was using un-numbered tunnels that didnt work as anticipated. As soon as i manually configured a destination IP to monitor a server IP on the other side, my tunnels failover as anticipated

I have been struggling with this same issue using unnumbered tunnels which are bound to the trust side of the network. However I do have separate tunnel interfaces for each VPN tunnel. When the primary internet connection goes down at a site, that site's routes adjust accordingly, but all the sites with VPN connections to that site still have their tunnel interfaces in a "ready" state instead of "down" which seems to leave the routes still active. I'm hoping this last post is the answer. I'm just wondering which interface you specified as the source interface for monitoring. The one the tunnel interface is bound to? I have seen that if I manually cause a connection to fail over things work as expected, and remote tunnel interfaces say "down," but when we really lose connectivity to the primary ISP, that's when the remote tunnels stay "ready" and the routes on those tunnels stay active.

This is really Phreddrick again, but the system made me pick a new name.

I found the solution to my problem. In the tunnel monitoring options I did not have re-key checked, because the description in the help made it sound like that would make the tunnel always show as UP. Instead it makes the tunnel only show as UP when it is up and DOWN when it is down instead of READY. Which makes the routes fail over as they should. I found this from KB6221 where it talks about Option #3 and explains what this does.

Another option to consider may be dynamic routing. Then if routing protocol cannot talk over a particular link for any reason, routes will go away accordingly.

Hi,

 

The gateway IPs are used per default. If you correctly configure vpn monitoring both on the local and remote sites the failed routes will be deactivated nearly simultaniously.

I also recommend to disable tcp-syn check for the tunneled sessions using unset flow tcp-syn-check-in-tunnel. This will prevent the sessions from being re-established after a VPN-failover.

Further, I would select Optimized in the VPN monitor settings. A havy VPN traffic may disrupt the VPN monitoring and cause an undesired failover.