IPSEC tunnel now active when Static route on WAN connection is larger than primary

[SmokeyMountian_Tech]

60D on 6.0.9

I've run into this issue before for other clients and haven't figured it out.

When in a multi-WAN scenario:

Primary Private fiber connection: Wan2 (OSPF) Static Route with Distance of 10

Backup ISP: DMZ static route with a distance of 20

IPsec tunnel on DMZ port with Static route with a distance of 10

This IPsec tunnel will not stay active unless we change the Distance of the Backup ISP to 10?

But this puts our WAN2 and DMZ in a load-balancing scenario, and we want to keep active-passive setup.

How can we keep the backup ISP in a passive state and keep the VPN tunnel up?

[Toshi_Esumi]

I'm assuming you meant "static default route" by "static route".

My first suggestion is if the IPsec peer public IP is static (not dynamic), setting /32 static route for the peer IP toward the DMZ port, so that regardless the priority/distance of the default routes to the WAN2 and the tunnel, the tunnel always comes up and stays up.

If that's not an option, the second suggestion is to set a low "priority" on the default route to DMZ (higher number of priority) to the DMZ port. It might not establish the tunnel from local end, but since it's still in the routing-table if the other side's tunnel establishment attempts would be returned to the port it came in (DMZ port). 

You didn't explain how you want to utilize two default route paths; WAN2 and Tunnel when the tunnel is up. But based on your distance settings they would load-balance with ECMP logic.

[SmokeyMountian_Tech]

I'm assuming you meant "static default route" by "static route". My first suggestion is if the IPsec peer public IP is static (not dynamic), setting /32 static route for the peer IP toward the DMZ port, so that regardless the priority/distance of the default routes to the WAN2 and the tunnel, the tunnel always comes up and stays up.

-We're using static Ip's 

  If that's not an option, the second suggestion is to set a low "priority" on the default route to DMZ (higher number of priority) to the DMZ port. It might not establish the tunnel from local end, but since it's still in the routing-table if the other side's tunnel establishment attempts would be returned to the port it came in (DMZ port).    You didn't explain how you want to utilize two default route paths; WAN2 and Tunnel when the tunnel is up. But based on your distance settings they would load-balance with ECMP logic.

-What we're trying to do is have:

1. Primary Internet and private network access to use WAN2 always

   -At the same time that WAN2 is being used we need to have the IPsec VPN tunnel always up on the DMZ internet connection.

Currently, we have 3 static routes configured for this:

1. 0.0.0.0/0 DMZ Distance = 20

2. 0.0.0.0/0 WAN2 Distance = 10

3. public IP  VPN interface on the DMZ port = Distance = 20

If the WAN2 Distance is lower than the Distance on the DMZ the VPN tunnel fails to come up.

If we change the Distance on WAN2 to be the same or higher (25) then DMZ the VPN tunnels comes up right away.

How can we keep a lower distance to prioritize traffic to use WAN2 and also keep the VPN tunnel up on the DMZ port?

[sw2090]

hm

we got plenty of IPSec S2S Tunnels here. Each is connected to a specific lan while SD-WAN takes care for the internet traffic. Those all work fine. Even redundant routing with different prios and distances for subnets that have to be reached via tunnels works fine here.

[Toshi_Esumi]

You don't need the default route to DMZ (No.1), you just need the (No.3) /32 route to DMZ. Your symptom indicates this /32 route is not working.

Either the detination IP is wrong or GW IP is wrong (or dynamic-gateway). Take the default route out on DMZ and try pinging the destination IP. I guess is you can't even ping the IP. Is that circuit static/DHCP/PPPoE?

[brycemd]

If routes do not have the same distance(for competing subnets) it gets removed from the route table until the primary goes down. It effectively makes DMZ(in this scenario) inactive and unable to respond back to any incoming traffic.

You need to have the same distance so both routes end up in the route table and use priority to define which is used by default.

[SmokeyMountian_Tech]

Yes! I just posted this fix right before your post showed up.

Since they both have 0.0.0.0/0.0.0.0 Static routes for internet access that make sense.

Assuming we had static routes that did not overlap it would stay up with different Distances set.

Thank you, thank you.

[SmokeyMountian_Tech]

Thank you all for the input.

Turns out we had to make the Distance the same on both WAN2 and DMZ (Primary and backup) connections.

After the Distance is set the same, I changed the Priority to 10 on the DMZ and left it 0 on WAN2.

This allowed the tunnel to come up on the DMZ port and all traffic is still going out WAN2 as expected.

I also updated the link monitoring to make sure it has failover detection.