Purpose
This article explains how to source NAT traffic using a specific IP address for traffic entering an IPSec tunnel so that the NAT IP is clearly identifiable by the remote site for source traffic coming from the initiator site.
Scope
FortiOS all versions.
Diagram
Scenario:
In this example two FortiGates in a site to site example will be used, where Site A will initiate an IPSec Policy Mode tunnel to Site B, and Site B will receive traffic from Site A with the “natip” address 172.16.1.1.
Expectations, Requirements
- IPSec Policy Mode.
- NAT IP applied from Site A to Site B for traffic orginating from Site A, no outbound traffic initiated from Site B will be sent back across the IPSec tunnel.
- NAT IP applied from Site A to Site B for traffic orginating from Site A, no outbound traffic initiated from Site B will be sent back across the IPSec tunnel.
Configuration
FortiGate 1 (Site A)
To NAT the traffic entering the IPSec tunnel with a specific IP address, a policy-mode IPSec tunnel can be created with the following configuration:
1. Create phase1 using policy-mode IPSec
FGT60C3G10010304 (phase1) # show
config vpn ipsec phase1
edit "FortiGate_1_Phase1"
set interface "wan1"
set proposal 3des-sha1 aes128-sha1
set remote-gw 172.31.16.177
set psksecret ENC SMTlGyc+VvvSeVDqaIr/2rpXnX+angemgv20SvAD8rrPVssyI701/fjQn0TgC+eAvmL4P8KzBIF6zsYDA3mV95JxhPY2cSJP5lLf3oxfMxHo3lor
nextc
end2. Create phase2
In the phase2 configuration the source subnet must refer to the NAT IP address since the traffic will be NATed before entering the tunnel. Quick mode selector must allow the traffic after NAT has been applied.
config vpn ipsec phase2
edit "FortiGate_1_Phase2"
set phase1name "FortiGate_1_Phase1"
set proposal 3des-sha1 aes128-sha1
set src-addr-type ip
set use-natip disable
set dst-subnet 10.147.0.0 255.255.252.0
set src-start-ip 172.16.1.1
next
end3. Create an IPSec <internal-interface> to <external-interface>
Outbound NAT' must be enabled in the IPSec firewall policy.
The "srcaddr" must refer to the subnet before NAT is performed as shown below:
config firewall policy
edit 2
set srcintf "internal"
set dstintf "wan1"
set srcaddr "10.100.0.0/22"
set dstaddr "10.147.0.0/22"
set action ipsec
set schedule "always"
set service "ANY"
set logtraffic enable
set logtraffic-app disable
set natip 172.16.1.1 255.255.255.255
set outbound enable
set natoutbound enable
set vpntunnel "FortiGate_1_Phase1"
nextIf the remote site is a FortiGate then the following configuration can be used on the remote FortiGate:
Remote FortiGate (Site B)
1. Create phase1 using policy-mode IPSec
config vpn ipsec phase1
edit "FortiGate_1_Phase1"
set interface "wan1"
set proposal 3des-sha1 aes128-sha1
set remote-gw 172.31.224.233
set psksecret ENC ce43FslLrlm6cZM1bL92FcXp9rE09wlbDjM/V3W/LMRGIFhkreYpS4IrMuNnCSuekcxNG7Mu0/HngXafSgU+d6S7StPUSJYyF8nR4Zcf0OY8uQwv
next2. Create phase2.
config vpn ipsec phase2
edit "FortiGate_1_Phase2"
set auto-negotiate enable
set dst-addr-type ip
set phase1name "FortiGate_1_Phase1"
set proposal 3des-sha1 aes128-sha1
set dst-start-ip 172.16.1.1
set src-subnet 10.147.0.0 255.255.252.0
next
end3. Create an IPSec <internal-interface> to <external-interface> firewall policy.
config firewall policy
edit 2
set srcintf "internal"
set dstintf "wan1"
set srcaddr "10.147.0.0/22"
set dstaddr "172.16.1.1"
set action ipsec
set schedule "always"
set service "ANY"
set inbound enable
set vpntunnel "FortiGate_1_Phase1"
next
Verification
Refer to the related KB article below to verify the state of the IPSec tunnel.
Troubleshooting
1. On the GUI of the FortiGate check the Firewall Policy monitor to check traffic is hitting the "IPSec" policy:
Initiate a ping from the internal network (Site A) protected by the FortiGate from a command prompt and run a sniffer trace on the FortiGate filtering "icmp" traffic, the sniffer trace should show the "icmp reply" traffic replying to the "natip" address as shown below.
1.111156 10.100.0.111 -> 10.147.0.92: icmp: echo request
1.112911 10.147.0.92 -> 172.16.1.1: icmp: echo reply
1.113081 10.147.0.92 -> 10.100.0.111: icmp: echo reply
2.068540 10.100.0.111 -> 10.147.0.92: icmp: echo request
2.070158 10.147.0.92 -> 172.16.1.1: icmp: echo reply
2.070330 10.147.0.92 -> 10.100.0.111: icmp: echo reply
3.083827 10.100.0.111 -> 10.147.0.92: icmp: echo request
3.085574 10.147.0.92 -> 172.16.1.1: icmp: echo reply
3.085744 10.147.0.92 -> 10.100.0.111: icmp: echo reply
4.093044 10.100.0.111 -> 10.147.0.92: icmp: echo request
4.095150 10.147.0.92 -> 172.16.1.1: icmp: echo reply
4.095316 10.147.0.92 -> 10.100.0.111: icmp: echo reply
5.114558 10.100.0.111 -> 10.147.0.92: icmp: echo request
5.116332 10.147.0.92 -> 172.16.1.1: icmp: echo reply
5.116518 10.147.0.92 -> 10.100.0.111: icmp: echo reply
6.070381 10.100.0.111 -> 10.147.0.92: icmp: echo request
6.072691 10.147.0.92 -> 172.16.1.1: icmp: echo reply
6.072865 10.147.0.92 -> 10.100.0.111: icmp: echo reply
7.085819 10.100.0.111 -> 10.147.0.92: icmp: echo request
7.087557 10.147.0.92 -> 172.16.1.1: icmp: echo reply
7.087724 10.147.0.92 -> 10.100.0.111: icmp: echo reply
8.084896 10.100.0.111 -> 10.147.0.92: icmp: echo request
8.086590 10.147.0.92 -> 172.16.1.1: icmp: echo reply
8.086756 10.147.0.92 -> 10.100.0.111: icmp: echo reply
24 packets received by filter
0 packets dropped by kernel
