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.
In this example, computer 10.10.10.22 want 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 map to 1.1.1.0/24. FortiGate B internal Subnet 10.10.10.0/24 is going to be map 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:
2) Create the new local Subnet for IPsec:
3) Create the new Remote subnet Address:
4) Change the local and remote subnet on the IPsec Phase 2 Selectors for the new subnet.
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.
5) Create the VIP.
Go to Policy & Object -> Virtual Ips and select 'Create New'.
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:
Otherwise, this can cause routing issues from Lan to Wan.
6) Apply the VIP to the Inbound Policy only.
There is now, an Inbound Policy with destination V
IP and an Outbound policy to Destination New remote subnet.
7) Configure the static route:
Go to Network -> Static Route.
This route says that to reach 2.2.2.0/24, send the traffic over the IPSec tunnel.
Configuration on FortiGate B.
Go to Policy & Objects -> Addresses and select 'Create New'.
1) Create the local subnet address:
2) Create the new local Subnet for IPsec:
3) Create the new Remote subnet Address:
4) Change the local and remote subnet on the IPsec Phase 2 Selectors for the new subnet.
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.
5) Create the VIP.
Go to Policy & Object -> Virtual Ips and select 'Create New'.
Make sure to select the IPsec tunnel in the Interface Option.
6) Apply the VIP to the Inbound Policy only.
There is now an Inbound Policy with destination VIP and an Outbound policy to Destination New remote subnet.
7) Configure the static route:
Go to Network -> Static Route.
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.
The same goes for Computer 10.10.10.56 who 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.
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 <----- IP address you are trying to communicate with. # diagnose debug flow filter proto 1 <----- This specify proto 1 which is ICMP. # diagnose debug flow trace start 999 # diagnose debug enable
2) Send continuous ping from one side to the other.
C:\Users\Fortinet>ping 1.1.1.22 -t
3) Read the debug. This will give a good understanding of where the issue resides.
If the issue persists, contact Fortinet Support for more assistance.
|