Description
This article aids in troubleshooting network connectivity via IPSEC VPN. In this scenario the site to site VPN between two FortiGates and the tunnel status is up however, both local and remote subnets are not able to reach each other or only one way communication is working.
Scope
FortiGate.
Solution
Network scenario used for this example :
172.16.0.0/24 local LAN -----FGT A------IPSEC VPN----- FGT B --- Remote lan 192.168.1.0/24
Below is a list of steps to aid in troubleshooting the issue:
Phase2 selector: Make sure the respective source and destination IP are present inthe phase2 selector configured on the FortiGate units and the phase2 selector is up.
FortigateA# diagnose vpn tunnel list
list all ipsec tunnel in vd 0
------------------------------------------------------
name=vpn ver=1 serial=2 10.40.19.195:0->10.5.25.62:0
bound_if=3 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/0
proxyid_num=2 child_num=0 refcnt=12 ilast=7 olast=568 ad=/0
stat: rxp=0 txp=0 rxb=0 txb=0
dpd: mode=on-demand on=1 idle=20000ms retry=3 count=0 seqno=0
natt: mode=none draft=0 interval=0 remote_port=0
proxyid=vpna proto=0 sa=1 ref=2 serial=3 <-- SA=1 means phase2 selectors(proxyid) "vpna" is up
src: 0:172.16.0.0/255.255.255.0:0
dst: 0:192.168.1.0/255.255.255.0:0
SA: ref=3 options=10226 type=00 soft=0 mtu=1280 expire=42402/0B replaywin=2048
seqno=1 esn=0 replaywin_lastseq=00000000 itn=0
life: type=01 bytes=0/0 timeout=42930/43200
dec: spi=a9a85865 esp=aes key=16 e25c71269c3f44205d1074d3ee5e6b36
ah=sha1 key=20 f5cf85d6c2b2a20918f83e92e1c18d9450ab4415
enc: spi=687f405e esp=aes key=16 3a0730ac611aaf84eea0438d127ec652
ah=sha1 key=20 4f6f509be0cd6a27588b4c4b1b0dec086a638913
dec:pkts/bytes=0/0, enc:pkts/bytes=0/0
If there are multiple phase2 selectors configured use the following command:
diagnose vpn tunnel list | grep -f "proxyid=<phase2 selectors name>"
Example:
diagnose vpn tunnel list | grep -f "proxyid=vpna"
proxyid=vpna proto=0 sa=1 ref=2 serial=3 <---
Route: On both FortiGates should have an active route to the remote subnets
FortigateA:
FortigateA# get router info routing-table details 192.168.1.0
Routing table for VRF=0
Routing entry for 192.168.1.0/24
Known via "static", distance 10, metric 0, best
* directly connected, vpna <<<<<<
FortiGateB:
FortigateB# get router info routing-table details 172.16.0.0
Routing table for VRF=0
Routing entry for 172.16.0.0/24
Known via "static", distance 10, metric 0, best * directly connected, vpnb <--
Policy Routing: If there policy routing applied to a specific respective source or destination create a policy route to the respective source and destination subnets with interface as vpn tunnel and keep the policy route on top.
Firewall Policies: Make sure there is LAN to VPN and VPN to LAN allow policies configured on both the FortiGate with respective source / destination addresses and services.
Note:
For the LAN to VPN policy, keep NAT disabled and VPN to LAN keep PAT enabled
Use the below command to do a policy lookup
diagnose firewall iprope lookup <source ip> <source port number> <destination ip> <destination portnumber> <protocol> <incoming interface>
Example:
To analyze a ping from 172.16.0.1 to 192.168.1.1 use the following command:
diagnose firewall iprope lookup 172.16.0.1 5178 192.168.1.1 443 0 lan
<src [172.16.0.1 -5178] dst [192.168.1.1-443] proto 0 dev lan <-- matches policy id: 1
Protocol id for UDP = 17, TCP = 6, other = 0
If the above fails, please raise a technical assistance ticket and attach the configuration of the FortiGate devices, network diagram and debug outputs of below commands.
Run the below commands on both FortiGates and initiate the communications to capture traffic flow :
SSH 1:
diag deb disable
diag deb reset
diagnose debug flow filter <protocol id> <-- ping = 1, UDP = 17, TCP = 6.
diagnose debug flow filter addr y.y.y.y <-- destination ip
diag debug flow show function-name enable
diagnose debug flow show console enable
diagnose debug flow trace start 2000
diagnose debug enable
SSH 2:
diag sniffer packet any "host y.y.y.y" 6 0 l
In certain instances, the root cause of the problem may be with the Windows PC at the receiving end. As an initial troubleshooting step, it is advisable to disable Windows Defender on the destination PC temporarily.
Furthermore, the destination PC often responds to ping requests originating from the same Internet network, while failing to respond to machines located on the opposite end of the tunnel. A potential reason could be the presence of antivirus software installed on the destination PC. To resolve this, it is recommended that Network Address Translation (NAT) be enabled in the firewall policy from the tunnel to the internal network.
Related article:
Troubleshooting Tool: Using the FortiOS built-in packet sniffer
