VPN Hair-Pinning on Fortigate Firewalls

Here is an issue I get questions about all the time.

Use Case

Customer has two VPNs.

Customer wants to get traffic from 10.3.3.0/24 (spoke 2) to 10.2.2.0/24 (spoke 1) using the Fortigate as the hub.  Currently, there each spoke has a site-to-site VPN already established.

Usually customers running Checkpoint have a difficult time understanding the concept because normally, Checkpoint is a strict Policy-based VPN solution.  They DO have route-based VPN capabilities, but you would be hard-pressed to even find Checkpoint employees that have mastered or use this feature.  It is called VTI or Virtual Tunnel Interfaces. In case you are interested in VTI, here is a link.  Cisco ASA is also Policy-Based VPN so it suffers from the same limitation.  As for Fortigate, PaloAlto, Juniper and even SonicWall, Route-based VPNs are readily available.

Configuration

Here we go:

Here we can see that we have the Site-to-Site VPN to Spoke 1 and we can see that the Phase II Selector shows Local Address of 10.1.1.0/24 to Remote Address 10.2.2.0/24 and the peer IP is 2.2.2.2

On this screenshot, we have our Site-to-Site VPN to Spoke 2 and we can see that the Phase II selector shows Local Address of 10.1.1.0/24 to Remote Address 10.3.3.0/24 and the peer IP is 3.3.3.3

Now we are showing the IPv4 Policies showing the access from Spoke2 to port2 (Inside) and the same with Spoke1.

In our requirement, we need to get traffic from 10.3.3.0/24 to 10.2.2.0/24 using the 10.1.1.0/24 as the hub.

You will need to add 10.3.3.0/24 as a “LOCAL” address to the VPN going to 10.2.2.0/24 .  This is because the firewall needs to know that this new traffic will be considered as Interesting Traffic and as such will encrypt it the proper IPsec VPN.

Here we can see the Spoke 2 - to - Spoke 1 Phase II selector completed with the additional networks.

This is the the Spoke 2 VPN Phase II selectors with the additional networks.

Now we can see that  a policy to permit traffic from Spoke 2 to Spoke 1 and Spoke 1 to Spoke 2 is needed. Pay particular attention to the Source and Destination Interfaces.

Remember, if you are using Central NAT you will need to add a Spoke1 to Spoke2 with NAT Disabled and the same in reverse.  

Other Options

Option 1

ADVPN – Using AD VPN, you will be able to have Spoke 2 bring up a dynamic VPN tunnel between Spoke 2 and Spoke 1 and the reverse would be true as well.  In this configuration, you would use BGP internally to learn routes that leave at each spoke.

Option 2

Quad Zeros – Instead of defining the Phase II selectors with specific IP addresses, you could set Phase II selectors to 0.0.0.0/0 on the local side, and 0.0.0.0/0 on the remote side.  Then you can use routing (either static or dynamic) to route traffic accordingly.  Remember that the VPN tunnel interfaces use a 0.0.0.0 address because it is unnumbered, but you CAN assign an IP address to the tunnel interface and configure  routing inside the tunnel (e.g. OSPF).

Hope this helps.