Description
This article describes the reasoning and process for configuring an IP address for an IPsec tunnel interface.
Scope
FortiGate, IPsec.
Solution
As a primer, traffic self-originated by the FortiGate (such as ICMP pings, SNMP traps, logs sent to syslog/FortiAnalyzer, etc.) will generally use the IP address of the outgoing interface used to reach the remote destination. It is possible to override this behavior and specify a particular Source IP for certain services on the FortiGate (see also: Technical Tip: How to control/change the FortiGate source IP for self-generated traffic).
Notably, IPsec tunnel interfaces are one of the few interface types that can be configured without needing an IP address to be applied. If the FortiGate needs to self-originate traffic using an IPsec tunnel that lacks an IP address, then it will fall back to using the first available address from the interface list (i.e. the lowest indexed interface shown in diagnose ip address list). Refer to the following KB article for more information on the subject: Technical Tip: Self-originating traffic over IPSec VPN (For example ping).
If it is not possible to set a specific Source-IP for the self-originated traffic then it is likely that the traffic will fail to reach its intended destination due to routing issues. For example, CLI backups using SFTP will fail if the outgoing interface is an IPsec tunnel interface lacking an address (see also: Technical Tip: How to take backup from CLI using secure FTP (SFTP) protocol).
With that in mind, the general recommendation is to set IP addresses on IPsec Tunnel interfaces to ensure that self-originated traffic uses a source address that can be routed through the network successfully. Here are some additional suggestions to consider when setting the address:
- Ideally, both ends of the VPN tunnel (the FortiGate and the remote peer) should support interface-based IPsec tunnels (i.e. where a virtual tunnel interface is created).
- Both sides should set an appropriate IP address in a shared subnet. For example, a /30 subnet may be appropriate for a site-to-site VPN tunnel (allows for 2 usable host addresses), or a /24 might be more appropriate for a dialup hub-and-spoke arrangement.
- In addition to the IP field (which specifies the local interface address), the Remote IP/Netmask field is useful for defining the remote VPN tunnel address.
- The Remote IP/Netmask field requires a host address and a subnet mask to be specified, and it will notably add a static route to the routing table that covers the specified subnet.
- The Remote IP address does not generally matter as long as it is a viable address within the same subnet as the remote VPN peer.
In the following example, the IPsec tunnel interface has a local IP address of 172.16.1.101 and a Remote IP/Netmask of 172.16.1.1/24 (255.255.255.0). To set the interface address, go to Network -> Interfaces and edit the IPsec tunnel interface:
The equivalent CLI configuration would be as follows:
config system interface
edit "advpn1"
set vdom "root"
set ip 172.16.1.101 255.255.255.255
set allowaccess ping
set type tunnel
set remote-ip 172.16.1.1 255.255.255.0
set snmp-index 9
set interface "VLAN201"
end
Related article:
