Site-to-site IPsec VPN with overlapping subnets

This recipe describes how to construct a site-to-site IPsec VPN connection between two networks with overlapping subnets, such that traffic will be directed to the correct address on the correct network, using Virtual IP addresses and static routes.

1. Create the IPsec VPN tunnel on FGT_1

Go to VPN > IPsec > Wizard.

Select Site to Site – FortiGate. Give it an appropriate Name and click Next.

Set Remote Gateway to the IP address used by the Internet-facing interface of FGT_2. The Outgoing Interface will automatically populate.

Enter a Pre-shared key and click Next.

Set Local Interface to your Internet-facing interface. The Local Subnets will automatically populate. Set Remote Subnets to the VIP of the internal network for FGT_2 (10.31.101.0/24) and click Create.
The VPN Wizard automatically creates the required objects, policies, and static route required for the tunnel to function properly.
You can verify the policy creation under Policy & Objects > Policy > IPv4.

2. Add the Virtual IP Range on FGT_1

Go to Policy & Objects > Objects > Virtual IPs and create a Virtual IP range to redirect the traffic to the correct subnet.

Select Virtual IP from the Create New drop down menu. Select IPv4 for the VIP Type and give the VIP an appropriate name.

Set the Interface to the IPsec VPN Site to Site interface from the drop down menu.

Set External IP Address/Range to a range in the subnet you will be redirecting from (10.21.101.1 – 10.21.101.254) and Mapped IP Address/Range to the internal network range (192.168.1.1 – 192.168.1.254).

Select OK.

3. Create the IPsec VPN tunnel on FGT_2 

Go to VPN > IPsec > Wizard.

Select Site to Site – FortiGate. Give it an appropriate Name and click Next.

 

Set Remote Gateway to the IP address used by the Internet-facing interface of FGT_1. The Outgoing Interface will automatically populate.

Enter a Pre-shared key and click Next.

Set Local Interface to your Internet-facing interface. The Local Subnets will automatically populate. Set Remote Subnets to the VIP of the internal network for FGT_1 (10.21.101.0/24) and click Create.

The VPN Wizard automatically creates the required objects, policies, and static route required for the tunnel to function properly.

As before, you can verify the policy creation under Policy & Objects > Policy > IPv4.

4. Add the Virtual IP Range on FGT_2

Go to Policy & Objects > Objects > Virtual IPs and create a Virtual IP range to redirect the traffic to the correct subnet.

Select Virtual IP from the Create New drop down menu. Select IPv4 for the VIP Type and give the VIP an appropriate name.

Set Interface to the IPsec VPN Site to Site interface from the drop down menu.

Set External IP Address/Range to a range in the subnet you will be redirecting from (10.31.101.1 – 10.31.101.254) and Mapped IP Address/Range to the internal network range (192.168.1.1 – 192.168.1.254).

Select OK.

5. Results

Go to VPN > Monitor > IPsec Monitor. Right-click on the Site to Site VPN and select Bring Up.

You will be able to see Incoming and Outgoing Data in the IPsec Monitor.

 

 

Keith Leroux

Keith Leroux

Technical Writer at Fortinet
Keith Leroux is a writer on the FortiOS 'techdocs' team in Ottawa, Ontario. He obtained a Bachelor's degree from Queen's University in English Language and Literature, and a graduate certificate in Technical Writing from Algonquin College. He spent a year teaching ESL in South Korea. Annyeong!
Keith Leroux

Share this recipe:

Facebooktwittergoogle_pluslinkedin

Leave a comment:

Before commenting, please read the site's comment policy. Only questions related to documentation will be answered. For other concerns, please contact Fortinet support.

  • Vincent

    Hi Keith,
    Thank you for this recipe.
    If you have a second wan link on each side and if you want a failover vpn ipsec.
    Is it possible to maintain overlapping subnets without fixing interface to any in VIP ?
    Thank you.
    Best regards,

    • Keith Leroux

      Hello,
      I’m attempting to get some clarification on IPsec VPN with regard to wan-load-balance so I can improve the IPsec VPN handbook chapter and potentially create some Cookbook material. In the meantime, I would advise contacting support.fortinet.com with your query; Support would be able to facilitate a proper dialogue with you concerning your particular environment, and they have much greater subject matter expertise than I can provide, especially regarding WAN links.

      • Avineet

        Remote gateway is wrongly configured in above example in step 1 and 3 .

        • Keith Leroux

          Ah yes! It would seem those graphics got flipped. Thanks Avineet! I’ll update immediately.

  • Israel Ramirez

    Hi Keith,

    Thank you for this recipe.

    I have a question, I’m watching the video and the instructions at the same time, and when creating the IPSEC Tunnel step 3 (Policy and Routing) the video says Set the Local Interface to your Internet Facing Interface and it chooses WAN1 and the instructions above select the Port1 (Local or LAN). Which one is the correct way to do it?

    Just a heads up… I’m newbie in the Fortinet world.

    Best Regards,

    Israel

    • Keith Leroux

      Hello Israel,

      Thank you for your comment. I believe the instructions in the video will let you create a VPN tunnel successfully, but it wouldn’t necessarily allow direct access to the internal network. I recommend using the instructions in the recipe above.

      I’ll follow up with the video producer. Thanks again!

  • Yves

    Hi,
    I’ve tried your recipe. It did create a VPN that can be brought up. but I cannot reach 192.168.1.250 on one end of the tunnel from 192.168.1.162 on the other end… Is there soemthing that I overlooked?

    Thanks,

    Yves

    • Nils

      I don’t have the feeling, that this recipe is complete. “Virtual IPs” are being created but never applied to any policy. I wonder if anyone can confirm this recipe as working.

  • Jordan Marendiuk

    This does not work. I’ve just tried it.

    Once the steps are followed and a tunnel is live, no traffic passes, not even in the local Ipv4 policies on the router . As another commenter pointed out, the VIP created to do the static NAT *is not applied* to any policies.

    How can this conceivably work in the first place? I totally get the concept here with static NAT and the 2 subnets the IP sec are mapped to. However when your network is operating on a switch behind the fortigate, none of the internal subnet’s layer3 IP traffic is going to even touch the fortigate for the static NAT to route your traffic to the other site. Your hosts are not going to send local traffic to the gateway… just going to switch only.

    Also, the video makes an odd mistake (I followed the written instructions which are right in this regard), when creating the IPSEC tunnel @ 1:27 , for the *internal* interface and subnet they set the WAN Interface and WAN IP in the “Policy and routing”.

    • Jordan Marendiuk

      After digging into this I found the documentation this article was created from, and there is steps missing in this cookbook article for adding the VIP to the Policies (if you use the wizard modify the policies). There are also steps missing indicating enabling/disabling of NAT of certain policies. See page 70 -> http://docs.fortinet.com/uploaded/files/1086/fortigate-ipsec-vpn-50.pdf

      Also, this solution only allows you to use the alternate VIP subnets to communicate with hosts across the tunnel. Example, at site A you want to communicate with another IP like 192.168.1.50 in the overlapping subnet at site B, you have to use the static NAT’d address so from site A user IP 10.31.101.50.

    • Jordan Marendiuk

      Found the source this article is based off of, see http://docs.fortinet.com/uploaded/files/1086/fortigate-ipsec-vpn-50.pdf . The exact scenario is in the PDF and does show what to do with the VIPs (they go in the IPv4 IPSEC policies).

      Also, this does not connect the sites so you communicate between the 2 sites with the same subnet. If your trying to reach a host in the remote location you have to use the NAT translated IP. Example if you are in site A, to reach a host in the overlapping subnet at site B you would use 10.31.101.X.