| Description |
This article describes how to configure FortiGate with IPSec VPN implanted on or bound to the loopback interface. |
| Scope | FortiGate v6.4, v7.0, v7.2. |
| Solution |
Sample configuration: IPSec VPN phase 1 bounded to the loopback interface.
config vpn ipsec phase1-interface edit "test_VPN" set interface "loopback0" set peertype any set proposal aes128-sha256 set remote-gw 10.200.200.200 set psksecret test123 end
In the above configuration sample, the remote gateway (remote-gw) was stated, but the local gateway (local-gw) was not and it’s usually not mandated/enforced since FortiGate has a way of retrieving it (unlike remote-gw which is impossible for FortiGate to guess). Whenever there is 'inbound' IKE traffic to FortiGate, the destination of such traffic is the local-gw IP.
If this IP is not expressly configured with 'set local-gw x.x.x.x', then the primary IP of the interface stated or referenced under 'IPSec phase-1 interface' configuration is used as local-gw IP.
If this local-gw is to be configured manually, it must be a primary or secondary IP on the referenced interface that was explained earlier.
Now the inbound IKE traffics are destined for the local-gw IP, however, the traffic did not come into the FortiGate through the loopback interface, but through our WAN, e.g. ISP.
The best practice when IPSec is bound to loopback is to configure inbound Firewall policy from the WAN interface to the loopback interface and permit service=IKE.
This also applies when configuring loopback on an IPsec with SAML. The specific SAML IPsec must be indicated as the source.
Note: If the above policy is not configured, the firewall (IKE responder) will block IKE/ESP traffic initiated by the remote gateway (IKE initiator) to the loopback IP. In some cases, the tunnel can bounce during the rekey phase, causing some seconds of disruption. This can be confirmed by filtering the local traffic logs on the firewall with the remote gateway IP address
The outbound IKE traffic does not require a firewall policy. If the FortiGate is configured as the initiator in phase 1, it will ignore the policy with the source address configured because the loopback interface will create a session from the FortiGate, and return traffic will match the session. As a result, no policy is required to pass IKE traffic.
Since traffic initiated from a loopback interface is considered local-out traffic, there is no option to control local-out traffic by creating a policy.
To control traffic ingressing to the FortiGate from allowed source IPs to establish an IPsec tunnel on the loopback interface, phase 1 must be configured to respond only.
config vpn ipsec phase1-interface edit "phase1" set interface "Loopback0" set passive-mode enable end
Starting from v6.2.8, 6.4.9, and v7.0 upward, it is possible to enable asymmetric routing on the loopback interface: Technical Tip: Site-to-Site IPsec VPN cannot establish in asymmetric routing scenario when tunnel in...
It is necessary to know whether the FortiOS version running on the unit supports NPU offload on the loopback interface or not: Technical Tip: Information about IPsec on loopback interface and hardware acceleration
If this is not carefully planned, it can result in poor/suboptimal performance (for traffic over the tunnel).
Related article: Technical Tip: PING Behavior when source IP is a Loopback and destination is Public IP |
