Troubleshooting Lost Traffic or Disappearing Packets¶

If there are issues with traffic being lost, or packets that seem to disappear or never show up (or leave) an interface, there are a few potential causes to consider.

IPsec (Tunnel Mode)¶

If a packet matches the traffic selectors set in tunnel mode IPsec phase 2 entries exactly (matches both source and destination), then the kernel will attempt to inject that packet into IPsec even if the IPsec tunnel is down.

This is commonly observed by users who setup an alternate VPN (e.g. WireGuard or OpenVPN) for the same networks previously handled by IPsec without fully removing the IPsec configuration.

Check the contents of the Security Policy Database (SPD) at Status > IPsec on the SPDs tab to see if one of the policies there overlaps. If it does, remove or disable the IPsec configuration and stop the IPsec daemon, then start it again. In some rare cases it may require a reboot to fully clear the old policy.

Captive Portal¶

If a host is on a network segment in an active Captive Portal zone, then it must be authenticated to the portal or setup as a bypass (e.g. Allowed IP/Host/MAC address) to pass traffic through the tunnel. This includes traffic from inbound NAT such as port forwards or 1:1 NAT.

Firewall Rules¶

Firewall rules, including floating rules, could be blocking and not logging the block action. Check the floating tab for matching rules (e.g. from packages such as pfBlockerNG) and also look at the content of block tables maintained by packages such as Snort and Suricata.

Routing Problems¶

If the firewall has a packet but nowhere to deliver the packet, then the firewall can drop that packet. The most common way this happens is from a lack of default route on the firewall itself.

If a packet arrives for a network that is not on a directly connected interface and the firewall has no default route, then the firewall has no idea where it should send that packet. This, it has no choice but to drop.

This can be sidestepped in certain cases by policy routing, which can make it tricky to diagnose at first. For example if the pass rules on LAN all have a gateway set then traffic from LAN might work, but traffic from the firewall itself (e.g. DNS resolution) would fail.

Hardware Checksum Offloading¶

It’s possible that a problem in hardware checksum offloading is leading to the packets being rejected by various parts of the network (e.g. OS, NIC, switch, peers, etc.)

Try disabling Checksum Offloading as follows:

Navigate to System > Advanced, Networking tab
Check Disable hardware checksum offload under Network Interfaces
Click Save

Then try to reproduce the problem.

Note

A reboot may be desired after applying this option, but it should not be necessary.

This has historically been an issue with Realtek NICs, some Via Rhine NICs, and some specific Intel fxp chips, as well as virtualized/emulated NICs in some hypervisors, especially those that use VirtIO.

The problem may also manifest as a PPPoE connection that will establish a login and bring up the interface, but will not pass traffic.