|
The customer 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 which 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 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.
First, confirm if errors are incrementing due to traffic directed towards tunnel interface while it's 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 to be the traffic for the Syslog is trying to leave the tunnel but not able to pass through the tunnel as the IP should be the 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 our case).
# config log syslogd setting
set status enable
set server "10.28.10.81"
set source-ip 192.168.0.1
end
For reference changing source IP of Syslog please check this link: select this link.
Else, drops could be due to large size packets.
https://community.fortinet.com/t5/FortiGate/Technical-Tip-Troubleshooting-IPsec-VPN-tunnel-errors-wi...
|
