Troubleshooting Tip: IPsec VPN Tunnel Errors Due to Traffic Not Matching Selectors

[mkatary]

Description	This article describes how to troubleshoot IPsec VPN tunnel errors due to traffic not matching selectors.
Scope	FortiGate.
Solution	IPsec VPN Tunnel interfaces may report increasing errors in the following command outputs. fnsysctl ifconfig <Phase 1 name> RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:337 errors:1 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 diagnose netlink interface list <Phase 1 name> stat: rxp=15172 txp=26662 rxb=2994702 txb=3515847 rxe=0 txe=1 rxd=0 txd=0 mc=6529 collision=0 Tx error count can occur due to the following reasons: Attempting to send traffic when no IPsec SA has been negotiated. Attempting to send traffic when there is no route to the gateway IP. Attempting to send traffic over a dead or expired IPsec SA. Insufficient memory to append the IPsec header to the outgoing packet. The Tx error count can also increase if there are Phase 2 selectors configured, and an attempt is made to ping a destination not permitted by the selector. In such cases, the Tx error count increments by one for each ping attempt. Confirm if errors are incrementing due to traffic directed towards the tunnel interface while it is not included under phase2 selectors. Run diagnose debug flow commands with respective filters. Refer to step 5 in the article: Troubleshooting Tip: First steps to troubleshoot connectivity problems to or through a FortiGate wit.... Generate traffic. Filter for interesting traffic. Search the output for the message 'No matching IPsec selector, drop'. Sample Config: show vpn ipsec phase2-interface TO-REMOTE     edit "TO-REMOTE"         set phase1name "TO-REMOTE"         set proposal aes256-sha256         set dhgrp 2         set keylifeseconds 28800         set src-subnet 192.168.0.0 255.255.255.0         set dst-subnet 10.28.10.80 255.255.255.240     next end The following packet debug flow demonstrates traffic attempting to pass through the VPN tunnel-TO-REMOTE. However, the debug indicates that the traffic fails to traverse the tunnel. 2021-11-03 11:22:42 id=20085 trace_id=2502 func=print_pkt_detail line=5693 msg="vd-root:0 received a packet(proto=17, 103.228.181.139:19212->10.28.10.81:514) from local. " 2021-11-03 11:22:42 id=20085 trace_id=2502 func=resolve_ip_tuple_fast line=5774 msg="Find an existing session, id-0245544b, original direction" 2021-11-03 11:22:42 id=20085 trace_id=2502 func=ipd_post_route_handler line=490 msg="out TO-REMOTE vwl_zone_id 0, state2 0x0, quality 0. 2021-11-03 11:22:42 id=20085 trace_id=2502 func=ipsecdev_hard_start_xmit line=789 msg="enter IPsec interface-TO-REMOTE" 2021-11-03 11:22:42 id=20085 trace_id=2502 func=_ipsecdev_hard_start_xmit line=666 msg="IPsec tunnel-TO-REMOTE" 2021-11-03 11:22:42 id=20085 trace_id=2502 func=ipsec_common_output4 line=876 msg="No matching IPsec selector, drop" In this case, although the destination IP is included in the Phase 2 selectors, the outgoing traffic uses the source IP 103.228.181.139 (WAN interface IP), which is not covered in the source-subnet of the Phase 2 selectors. The best approach to detect this in a debug flow, is to debug using the destination phase2 subnet range. For example: diag debug enable diag debug flow filter daddr 10.28.10.80 10.28.10.95 diag debug flow filter start 10 After checking the destination IP and destination port, it appears that the Syslog traffic is attempting to exit through the tunnel but cannot pass. This is because the destination IP must be included in the Phase 2 selector to traverse the tunnel successfully. Therefore, for this example, change the source-ip to one included in the src-subnet (LAN interface IP in this case).  config log syslogd setting     set status enable     set server "10.28.10.81"     set source-ip 192.168.0.1 end For reference to changing the source IP of Syslog, check this link: Technical Tip: Syslog server over IPSEC VPN and sending VPN logs. Otherwise, drops could be due to large size packets. Another possible cause of the error 'No matching IPsec selector, drop' is when NAT is enabled in the outgoing firewall policy for IPsec traffic. This is due to the NATted IP that is not part of the negotiated subnets in phase-2. The quick fix for this will be to disable NAT in the said firewall policy or to change the phase-2 selectors to all-all for local and remote addresses. After this, control the IPsec VPN traffic via static routes and firewall policies by specifying specific source and destination addresses. Related article: Technical Tip: Troubleshooting IPsec VPN tunnel errors with large size packets