|
The user may complain about increasing errors appearing on the IPsec VPN interface.
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
Counters that are marked as red need to be observed.
Txe error count can be caused by the following reasons:
- Attempting to send traffic when no IPsec SA has not been negotiated.
- Attempting to send traffic when there is no route to the gateway IP.
- Attempting to send traffic on an IPsec SA that is dead/expired.
- No memory was available to add the IPsec header onto the egress packet.
The txe error can also count up if there are phase 2 selectors, and then try to ping a destination not allowed by the selector.
The txe error count will then increment by one for every ping.
Confirm if errors are incrementing due to traffic directed towards the tunnel interface while it is not included under phase2 selectors.
- Run diag debug flow with respective filters.
- Generate traffic.
- Filter for interesting traffic.
- Search the output for the below message.
msg="No matching IPsec selector, drop".
The following shows the packet debug flow for the traffic trying to pass through the VPN tunnel-HKBNSOC. However, it is possible to see the traffic failing.
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 HKBNSOC 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-HKBNSOC"
2021-11-03 11:22:42 id=20085 trace_id=2502 func=_ipsecdev_hard_start_xmit line=666 msg="IPsec tunnel-HKBNSOC"
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, however, the destination IP is included in selectors, the traffic going out is using source IP 103.228.181.139 (WAN interface IP) which is not included under phase 2 selectors.
show vpn ipsec phase2-interface HKBNSOC
edit "HKBNSOC"
set phase1name "HKBNSOC"
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
After checking the destination IP and destination port, it seems that the traffic for the Syslog is trying to leave the tunnel but is not able to pass through the tunnel as the IP should be part of the phase 2 selector to pass through the tunnel.
Therefore for this example change the source-ip to be 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
|
