How to configure VPN tunnel should get up if point to point link goes down

[ShripadBuwa]

Customer has single point to point link between two branch offices and customer wants to have s2s vpn tunnel in between the branch offices if the point to point link goes. how to configure such s2s vpn in this scenario?

[Maarten_Sjouw]

This is one of those "I want something that is not simple" questions that customers have.
There are a number of issues here that make this a difficult to answer item:

• Routing, how will the traffic know which path to take?
• Encrypt or not? How does the gateway know when to encrypt or decrypt the traffic?
• A domain based VPN does not support dynamic routing
• VPN interfaces are supporting dynamic routing, they are not supported in VSX.
  • VPN interfaces are configured in GAIA and depending on the number of sites you need an exponential growing number of interfaces, if you want a full mesh.

In our experience this type of setup is best solved by adding:

• either a GRE tunnel on the router which is routed over a IPSEC tunnel between the Check Points
• or a IPSEC tunnel directly between both routers by using a NAT IP for both routers (requires SEC license on the routers) 

Last resort would be running dynamic routing on both Check Points and the routers and use a route based VPN between the Check Points.

[mdjmcnally]

To expand on what was said then so much what you do will depend upon the topology and where the Point to Point Link actually terminates.

Would also depend upon how the Branch Office Network route is put into the Central Office and if Traffic normally goes through the Check Point anyway.

So to give a more detailed answer then would have to see a high level topology for how this fits together.

How I would do is

Router at each location that is running Dynamic Routing.  This then advertises the Remote Network into the Core at the Location.  So effectively the Check Point Gateway and the P2P Router are on stub networks hanging off the Core Switch, and the Core Switch makes the decision to send to the P2P router or the Check Point.

Route Based VPN between the Branch Office and the Central Location, which will also advertise the routes but make sure have a Higher Cost so that traffic would route to the Router rather then over the VPN.

In the event that the Link OR the actual Router goes down at a location then the Route via the Point 2 Point link is no longer learnt and so the Route Based VPN would take over.

I tend to favour this as that way if any of the traffic does have to go through the Check Point, maybe accessing a DMZ resource so normally comes over the P2P link and then upto the Check Point Box to access the Server then the Check Point see's the connection via the P2P link and forwards accordingly.

If a Domain Based VPN would simply send over the VPN and end up with Assymetric Routing.

Of course if don't need to access any resources in a DMZ and the Traffic from the Branch Office never normally goes near the Check Point then could simply have a Domain Based VPN and if the P2P link goes down then the traffic would revert to going to the Check Point and over the Domain Based VPN by reason of no route via the P2P.

Hence why would need to know more fully the details if someone to advise what may be best for your specific environment.

As previously said whilst seemingly a simple question then gets very complex depending upon how the network actually fits together.

[Ryan_Ryan]

We have this running on one of our customers. Its fairly straight forward assuming both ends are Checkpoint

* configure a site to site vpn normally (public Ip on each)

* configure the WAN interface, set a tracked static route via the WAN interface to the external IP of the remote side

* in guidbedit set the value "vpn_trusted" on the WAN interface

Now what happens is, the VPN is active across the WAN but its unencrypted (thanks to vpn_trusted value). And now if the remote peers external IP is not pingable across the WAN interface for whatever reason, the tracked route will get removed from the table, you will then revert to the default route (Internet) and because Internet interface is not set with vpn_trusted then the traffic will be encrypted like a normal vpn.

[ShripadBuwa]

@Ryan_Ryan thanks for the reply! Let me explain you the scenario again. Customer has P2P link, no redundancy is there for P2P link. when P2P goes down they want to pass their traffic over internet link through VPN. Once P2P restore traffic should pass through it again and VPN tunnel should go down. Can you please explain "VPN_Trusted" value in brief and how to configure it?

[Ryan_Ryan]

Hello yes, trusted_vpn value essentially means do not encrypt vpn traffic (send in clear text) this value is set per interface, so although you will set vpn encrption parameters in the community, the interface setting will override this and not actually encrypt it. So what you are going to do is configure an ipsec vpn over the p2p link, (but it wont be encrypted) and with the tracked route if the branch office is no longer pingable then the tracked route via p2p link will get removed and the vpn will then establish via the internet (which will be encrypted), this will take about 1-5 seconds failover. You do not have to worry about static routes for the LAN subnets as the encryption domain will take care of that. 

You can verify the solution is working, tcpdump on the p2p interface and traffic should be clear text, shutdown the p2p link and you should see encrypted traffic to the remote branch peer IP address with minimal disruption to traffic.

This solution only works when both sides are checkpoint firewalls. There was an SK article for this, but I cannot find it for the life of me.

[ShripadBuwa]

@Ryan_Ryan other end gateway is fortigate. and as you said it works with both side checkpoint only. Is there any provision like cisco SLA based tracking for route redundancy.

[Ryan_Ryan]

Yes there is, in Fortigate there is option called"dead gateway detection" which achieves the same thing. In this case since both sides are not Checkpoint, I would recommend not using the vpn_trusted value on Checkpoint and therefore you will be encrypting on the primary link and the backup link - because I am not sure there is any way to make Fortigate not encrypt vpn on a specific interface. 

So essentially you will do a normal IPsec vpn over the WAN, if the WAN is unavailable tracked route/dead gateway detection will remove the route and vpn will run over the Internet instead. There is no real disadvantage of this except maybe a tiny bit of performance decrease over the WAN due to encryption overhead.

[FedericoMeiners]

I'm wondering if Multi Hop PBR can be used to solve this:

First PBR - DST: Branch office / Default gateway: P2P gateway

Second PBR - DST: Branch office / Default gateway: WAN

On probing I would set up to test if P2P peer es reachable, if not, second PBR rule will come into place.

To prevent asymmetric routing you will have to setup a similar solution on the other side or do some nating to add diferent routes.

Let me know if you try it

___

[ShripadBuwa]

@FedericoMeiners thanks for the reply! I will try this PBR in lab first and let you know. Can we consider Route based VPN for such scenario?