Description
This article describes the expected behavior that locally generated traffic egressing over an IPsec VPN which has no IP address assigned will use the IP address of the interface with the lowest index as the source IP address.
Scope
FortiGate.
Solution
As an example, FortiGateA uses the source IP address of 10.60.60.60 (wan1 interface) for ping traffic originating from itself over the VPN tunnel IPSecVPN because it has the lowest index as shown in the output of the command 'diagnose ip address list'.
FortiGateA # diagnose ip address list
IP=10.60.60.60->10.60.60.60/255.255.255.0 index=4 devname=wan1
IP=10.10.10.1->10.10.10.1/255.255.255.0 index=6 devname=dmz
IP=192.168.20.20->192.168.20.20/255.255.255.0 index=8 devname=internal
IP=127.0.0.1->127.0.0.1/255.0.0.0 index=13 devname=root
IP=127.0.0.1->127.0.0.1/255.0.0.0 index=17 devname=vsys_ha
IP=127.0.0.1->127.0.0.1/255.0.0.0 index=19 devname=vsys_fgfm
Debug flow output:
2015-03-11 04:36:51 id=13 trace_id=121 func=print_pkt_detail line=4313 msg="vd-root received a packet(proto=1, 10.60.60.60:2816->172.16.13.13:8) from local. code=8, type=0, id=2816, seq=0."
2015-03-11 04:36:51 id=13 trace_id=121 func=init_ip_session_common line=4469 msg="allocate a new session-00051418"
2015-03-11 04:36:51 id=13 trace_id=121 func=ipsecdev_hard_start_xmit line=121 msg="enter IPsec interface-IPSecVPN"
2015-03-11 04:36:51 id=13 trace_id=121 func=esp_output4 line=885 msg="encrypting, and send to 10.70.70.70 with source 10.60.60.60"
2015-03-11 04:36:51 id=13 trace_id=121 func=ipsec_output_finish line=231 msg="send to 10.70.70.70 via intf-wan1"
This is not ideal when the remote side expects traffic to originate from a particular subnet (For example: 192.168.20.0/24). What can be done therefore, is to use the 'ping-options source' command to specify the IP address of the internal interface (192.168.20.20) since the index value is hard-coded.
execute ping-options source 192.168.20.20
Debug flow output:
2015-03-11 04:38:22 id=13 trace_id=121 func=print_pkt_detail line=4313 msg="vd-root received a packet(proto=1, 192.168.20.20:3834->172.16.13.13:8) from local. code=8, type=0, id=2816, seq=0."
2015-03-11 04:38:22 id=13 trace_id=121 func=init_ip_session_common line=4469 msg="allocate a new session-00051418"
2015-03-11 04:38:22 id=13 trace_id=121 func=ipsecdev_hard_start_xmit line=121 msg="enter IPsec interface-IPSecVPN"
2015-03-11 04:38:22 id=13 trace_id=121 func=esp_output4 line=885 msg="encrypting, and send to 10.70.70.70 with source 10.60.60.60"
2015-03-11 04:38:22 id=13 trace_id=121 func=ipsec_output_finish line=231 msg="send to 10.70.70.70 via intf-wan1"
Restore it to the default behavior again by issuing the command:
execute ping-options source Auto
Assigning an intended source IP addresses can be done in one of the following ways:
- Assign an IP to the tunnel interface.
- Specify the intended source IP address in a specific firewall function such as system DNS, RADIUS, etc. See Technical Tip: How to control/change the FortiGate source IP for self-generated traffic. This source IP must match an address configured on a FortiGate interface. If no suitable interface exists, a loopback interface may be created.
- In v7.4 and later, 'preferred-source' in routing configuration can be used to specify a 'default' source IP for all self-generated traffic using that particular route. See the FortiOS v7.4 New Features Guide
If using one of the above methods to specify a source IP, the address must also be included in the local networks of an existing phase 2 selector, or a new phase2 selector must be configured on both sides of the tunnel to carry the traffic.
Related articles:
Troubleshooting Tip: Not able to ping the Ipsec VPN remote peer network
Technical Tip: Unable to ping public servers (for testing) using ping-option source interface
Troubleshooting Tip: Using PING options from the FortiGate CLI