From, an OpenBSD-based firewall
Jump to: navigation, search

This page contains a collection of different troubleshooting techniques that can be used in different scenarios.

Routing and firewalling

Troubleshooting routing and firewalling issues are closely related, and therefore covered in the same section.

Tracing packets to debug firewall or routing issues

It could be either a firewall or routing problem. Start out by seeing if the packet is blocked by running

firewall log host some-ip-address

where you filter the log based on the source IP address of the connection you're trying to get through. You can also use filters such as "port XXX" is that's more suitable. If nothing shows up, try showing all traffic (shows everything, either allowed or blocked) on the interface on which the connection is supposed to enter the router

tcpdump -n -i em0 host some-ip-address

where em0 represents the WAN interface, which is logical in case we're debugging a port forwarding where the test connection is coming form the Internet. In case you see the connection, move on to the next interface where you believe the connection should exit the router. In other word, execute the same command again, but replace em0 with for example em1 (might be another interface in your case). If you don't see the connection leaving the firewall, examine the routing table and your firewall rules. If you do in fact see traffic leaving, but not returning from the server (or other device you are trying to connect to), start troubleshooting that device to see why the traffic is not returned.

Firewall rules that doesn't seem to apply

The firewall's state table is evaluated before the rules, and an existing state entry might prevent your rule from "winning". By for example restarting a continuous ping, the old state is no longer matches. The other method is to simply flush the states.


Anything related to the system or device itself.

Logging issues

Normally the logs are stored in RAM memory. However, if a storage device is used for logging, and that device somehow becomes broken or inaccessible, you can still view the kernel's in-memory log by running dmesg. The most common cause of this problem is if unplugging a storage disk while running, perhaps after performing a storage-based software update. Only unplug disks when the system is shut down.

Rebooting issues

In case rebooting doesn't work, the backend process might have crashed. Try running reboot -f instead. If that doesn't work either, enable/use the root access to run reboot -n -q to perform a quick and dirty system reboot.