Help
FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
Gab_FTNT
Staff
Staff

Created on ‎01-06-2023 07:37 AM Edited on ‎11-04-2024 08:31 AM By Moderator

Article Id 242267

Technical Tip: How to configure an IPsec tunnel with Overlapping Subnets using VIPs

Description This article describes how to configure an IPsec tunnel with Overlapping Subnets using vips.
Scope FortiGate.
Solution

This method is used as a workaround if changing the subnet is not possible. The real fix for this issue is to change the subnet on one side.  Only use this method as a last resort.

This article will describe two scenarios:

Scenario 1: Overlapping subnets, subnet to subnet NAT for a single IPsec tunnel

Scenario 2: Subnet to subnet NAT for two or more IPsec tunnels

 

Scenario 1: Overlapping subnets, subnet to subnet NAT for a single IPsec tunnel

 

Gab_FTNT_0-1673017477725.png

 
In this example, computer 10.10.10.22 wants to communicate with computer 10.10.10.56 on the other side of the tunnel.
To achieve communication, it is necessary to create a new subnet on both sides and translate the traffic using a VIP.

 

  • FortiGate A internal Subnet 10.10.10.0/24 is going to be mapped to 1.1.1.0/24.
  • FortiGate B internal Subnet 10.10.10.0/24 is going to be mapped to 2.2.2.0/24.

 

Note that 1.1.1.0/24 and 2.2.2.0/24 subnets are used as examples. Use a private IP range for configuration.

Let's review the configuration:

Configuration on FortiGate A.

Go to Policy & Objects -> Addresses and select 'Create New'.

 

  1. Create the local subnet address:

 

Gab_FTNT_1-1673017549784.png

 

  1. Create the new local Subnet for IPsec:

 

Gab_FTNT_2-1673017564138.png

 

  1. Create the new Remote subnet Address:

 

Gab_FTNT_3-1673017577297.png

 

  1. Change the local and remote subnet on the IPsec Phase 2 Selectors for the new subnet.

 

Gab_FTNT_4-1673017593304.png

Gab_FTNT_5-1673017609281.png


It is also either possible to choose the Named Address previously created or Select Subnet and add manually.

If there are multiple subnets to route on the tunnel, it is also possible to use 0.0.0.0/0 as the local and remote subnets.

 

  1. Create the VIP. Go to Policy & Object -> Virtual Ips and select 'Create New'.

 

 

Gab_FTNT_6-1673017637599.png

 

The purpose of this VIP is to translate traffic coming from 1.1.1.0 to the internal subnet 10.10.10.0. For example, inbound traffic with destination 1.1.1.46 will be routed to 10.10.10.46

Make sure to select the IPsec tunnel in the Interface Option:

 

Gab_FTNT_7-1673017676006.png

 

Otherwise, this can cause routing issues from Lan to Wan.

 

  1. Apply the VIP to the Inbound Policy only.
      

Gab_FTNT_8-1673017709993.png

 

Gab_FTNT_9-1673017722163.png

 

Gab_FTNT_9-1673017722163.png


There is now an Inbound Policy with destination VIP and Outbound policy to Destination New remote subnet.

 

Gab_FTNT_10-1673017782260.png

 

  1. Configure the static route: Go to Network -> Static Route.

 

Gab_FTNT_11-1673017813817.png

This route says that to reach 2.2.2.0/24, send the traffic over the IPSec tunnel.

 

Note:

Considering not needing to use an IP Pool for SNAT. Like using specific subnets allowing both sites to communicate, it can use nat-source-vip enable, set srcintf-filter <the vpn interface> in the vip configuration in FortiGate (v7.0, and above). Then in the outgoing policy no need to use IPPOOL.

config firewall vip


Configuration on FortiGate B.

Go to Policy & Objects -> Addresses and select 'Create New'.

 

  1. Create the local subnet address:

 

Gab_FTNT_12-1673017844226.png

 

  1. Create the new local Subnet for IPsec:

 

Gab_FTNT_13-1673017856720.png

 

  1. Create the new Remote subnet Address:

 

Gab_FTNT_14-1673017870350.png

 

  1. Change the local and remote subnet on the IPsec Phase 2 Selectors for the new subnet.

 

Gab_FTNT_15-1673017891689.png

Gab_FTNT_16-1673017898461.png

If there are multiple subnets to route on the tunnel,l it is also possible touse 0.0.0.0/0 as the local and remote subnets.

 

  1. Create the VIP. Go to Policy & Object -> Virtual Ips and select 'Create New'.

 

Gab_FTNT_17-1673017932154.png


Make sure to select the IPsec tunnel in the Interface Option.

 

  1. Apply the VIP to the Inbound Policy only.
      

Gab_FTNT_18-1673017960534.png

 

Gab_FTNT_19-1673017974907.png

 

Gab_FTNT_19-1673017974907.png


There is now an Inbound Policy with destination VIP and an Outbound policy to Destination New remote subnet.

 

Gab_FTNT_20-1673018033682.png

 

  1. Configure the static route: Go to Network -> Static Route.

 

Gab_FTNT_21-1673018053887.png

 

This route says that to reach 1.1.1.0/24, send the traffic over the IPsec tunnel.

Test the behavior.

Computer 10.10.10.22 on FortiGate A side wants to communicate with Computer 10.10.10.56 on FortiGate B side. Computer 10.10.10.22 will need to send traffic to the new assigned subnet by replacing 10.10.10.56 by 2.2.2.56.

Gab_FTNT_22-1673018078775.png

 

The same goes for Computer 10.10.10.56 which wants to communicate with Computer 10.10.10.22. Computer 10.10.10.56 will need to send traffic to the new assigned subnet replacing 10.10.10.56 by 1.1.1.22.

Gab_FTNT_23-1673018095611.png


Troubleshooting steps

 

  1. Start a Debug Flow on the FortiGate side to the traffic flow.


Open the CLI and run the following:


diagnose debug flow filter addr 1.1.1.22  
diagnose debug flow filter proto 1 
diagnose debug flow trace start 999
diagnose debug enable

 

  1. Send continuous ping from one side to the other.


C:\Users\Fortinet>ping 1.1.1.22 -t

  1. Read the debug. This will give a good understanding of where the issue resides.

If the issue persists, contact Fortinet Support for more assistance.

 

Scenario 2: Subnet to subnet NAT for two or more IPSec tunnels

 topology subnet to subnet.png

It is a common requirement to have primary and backup tunnels to a location. When a subnet-to-subnet NAT is needed, it is required to be applied for both IPsec tunnels. 

The solution described below is scalable for one or more IPsec tunnels as needed.

 

Requirements:

1. FG1 LAN (192.168.10.0/24) should have internet access via a SNAT (PAT in this case) to the WAN interface IP address, 1.1.1.254.

2. Traffic initiated from the FG1 LAN towards either of the IPsec tunnels (to FG2 or FG3) should undergo a subnet-to-subnet SNAT (source NAT) from 192.168.10.0/24 to 10.200.200.0/24 such that when traffic reacheds FG2 or FG3, the source network is observed to be 10.200.200.0/24.

3. Traffic initiated from FG2 or FG3 LAN networks (192.168.20.0/24 and 192.168.30.0/24 respectively) towards 10.200.200.0/24 should reach FG1 and undergo DNAT (Destination NAT) to the FG1 LAN network 192.168.10.0/24.

 

Configuration:

IPsec settings, policy and routes for tunneled networks:

  • The IPsec traffic selectors can either be wildcard (0.0.0.0/0.0.0.0 to 0.0.0.0/0.0.0.0) or, should have the source (on FG1) and destination (on FG2/FG3) as 10.200.200.0/24.
  • FG2 and FG3 will have routes pointing to the tunnel towards FG1 for 10.200.200.0/24 and policies referencing this network.

FG1 configuration:

  1. VIP/DNAT configuration:

The most significant part of this scenario is having the 'srcintf-filter' configured on the VIP (CLI only as of FortiOS 7.4.5/7.6.0). This ensures that the internet bound traffic policy (step 2) works fine with standard NAT enabled.

Without this setting, every Firewall policy not destined to the tunnels towards FG-2 and FG-3 that require a NAT for the FG1 LAN network will need an IP Pool for the intended NAT to take place - and if only an interface NAT is turned on, traffic for such policies will also be SNAT as per the subnet-to-subnet VIP created for the tunnel traffic.

This is due to the order of precedence (for interface NAT vs DNAT vs IP Pool) as discussed on this article. 

 

config firewall vip

    edit "sub-to-sub"

        set extip 10.200.200.1-10.200.200.254

        set mappedip "192.168.10.1-192.168.10.254"

        set extintf "any"

        set srcintf-filter "to-FG2" "to-FG3" "1to6" 

    next

end

 

  1. Firewall policy for Internet access:

config firewall policy

    edit 28

        set name "lan to WAN INET"

        set srcintf "port3"

        set dstintf "port4"

        set action accept

        set srcaddr "Obj-192.168.10.0/24"

        set dstaddr "all"

        set schedule "always"

        set service "ALL"

        set utm-status enable

        set ssl-ssh-profile "certificate-inspection"

        set application-list "default"

        set logtraffic all

        set logtraffic-start enable

        set nat enable # <- PAT, to WAN interface IP address.

    next

end

 

 

  1. Firewall policies for outbound traffic to FG2 and FG3 IPsec tunnels:

config firewall policy

    edit 9

        set name "lan to FG2"

        set srcintf "port3"

        set dstintf "to-FG2"

        set action accept

        set srcaddr "Obj-192.168.10.0/24"

        set dstaddr "192.168.20.0/24"

        set schedule "always"

        set service "ALL"

        set logtraffic all

        set nat enable

    next

end

 

config firewall policy

    edit 24

        set name "lan to FG3"

        set srcintf "port3"

        set dstintf "to-FG3"

        set action accept

        set srcaddr "to3_local"

        set dstaddr "to3_remote"

        set schedule "always"

        set service "ALL"

        set nat enable

    next

end

 

Although interface NAT is turned on here, the traffic is SNATed to 10.200.200.0/24 as per the VIP configuration since DNAT takes precedence over interface NAT as described in the article referenced on Step1.

 

  1. Firewall policies for inbound traffic, ingress-ing on to-FG2 and to-FG3 tunnels:

config firewall policy

    edit 20

        set name "from FG2"

        set srcintf "to-FG2"

        set dstintf "port3"

        set action accept

        set srcaddr "all"

        set dstaddr "sub-to-sub"

        set schedule "always"

        set service "ALL"

    next

end

 

config firewall policy

    edit 26

        set name "from FG3"

        set srcintf "to-FG3"

        set dstintf "port3"

        set action accept

        set srcaddr "to3_remote"

        set dstaddr "sub-to-sub"

        set schedule "always"

        set service "ALL"

    next

end

 

Verification:

  1. Outbound traffic verification:

Initiate traffic towards the internet (8.8.8.8, example), FG2 LAN and FG3 LAN and observe the NAT translations:

Ping:

 

ping from pc.png

 

NAT Translations:

 

FG1 # get sys session li | grep 'PROTO\|8.8.8.8\|192.168.20\|192.168.30'

PROTO   EXPIRE SOURCE           SOURCE-NAT       DESTINATION      DESTINATION-NAT

icmp    43     192.168.10.2:1   1.1.1.254:60418  8.8.8.8:8        -              

icmp    55     192.168.10.2:1   10.200.200.2:1   192.168.20.254:8 -              

icmp    57     192.168.10.2:1   10.200.200.2:1   192.168.30.30:8  -    

 

  1. Inbound traffic verification:

When traffic is initiated from FG2 and FG3 LAN towards FG1 LAN PC:

 

FG1 # get sys session li | grep 'PROTO\|8.8.8.8\|192.168.20\|192.168.30'

PROTO   EXPIRE SOURCE            SOURCE-NAT       DESTINATION      DESTINATION-NAT

icmp    42     192.168.20.254:3108 -             10.200.200.2:8   192.168.10.2:3108

icmp    59     192.168.30.30:3339 -              10.200.200.2:8   192.168.10.2:3339

 
Labels:
6422
0 Kudos
Suggest New Article
Article Feedback
Broad. Integrated. Automated.

The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.

Social Media
Security Research
Company
News & Articles
Contact Us

Copyright 2024 Fortinet, Inc. All Rights Reserved.