When diagnosing traffic flow issues, one of the first things to check is the routes known to the firewall.
Viewing the routing table is described in detail at Route Table Contents. For routed destinations, check the contents of the table and see if the destination is listed as expected.
It is also possible to check how the operating system will route a specific
destination at the CLI. For example, to see how the firewall will reach
$ route -n get 126.96.36.199 route to: 188.8.131.52 destination: 0.0.0.0 mask: 0.0.0.0 gateway: 198.51.100.1 fib: 0 interface: igb0 flags: <UP,GATEWAY,DONE,STATIC> recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1500 1 0
In that example, there isn’t a specific static route in place for the destination, so it uses the default route.
In the next example, there is a specific route for
184.108.40.206 using an
: route -n get 220.127.116.11 route to: 18.104.22.168 destination: 22.214.171.124 gateway: 10.0.14.1 fib: 0 interface: igb5 flags: <UP,GATEWAY,HOST,DONE,STATIC> recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1500 1 0
While viewing the routing table as a whole is helpful, sometimes querying the OS in this way is faster and easier when a specific destination is known.
Traceroute is a useful tool for testing and verifying routes and multi-WAN
functionality, among other uses. It shows each “hop” along the path a packet
travels from one end to the other, along with the latency encountered in
reaching that intermediate point. On pfSense® software, a traceroute can be
performed by navigating to Diagnostics > Traceroute, or by using
traceroute at the command line. From clients running Windows, the program is
available under the name
For details on how traceroute works and how to perform a traceroute using the GUI, see Traceroute.
Routes and VPNs¶
Depending on the VPN being used, the firewall may not have routes in the table for the remote side. IPsec in tunnel mode does not use the routing table, it is instead handled internally in the kernel using IPsec security policy database (SPD) entries. Static routes will never cause traffic to be directed across a tunnel mode IPsec connection. VTI mode IPsec, OpenVPN, and WireGuard use the system routing table and as such entries are present for networks reachable via those types of VPNs.
For example, the following output includes an OpenVPN tunnel:
#netstat -rWn Routing tables Internet: Destination Gateway Flags Use Mtu Netif Expire default 198.51.100.1 UGS 92421 1500 em0 10.6.0.0/16 10.6.203.1 UGS 0 1500 ovpnc2 10.6.203.0/24 10.6.203.2 UGS 0 1500 ovpnc2 10.6.203.1 link#9 UH 0 1500 ovpnc2 10.6.203.2 link#9 UHS 0 16384 lo0 10.7.0.0/24 link#2 U 1260771 1500 em1 10.7.0.1 link#2 UHS 0 16384 lo0 127.0.0.1 link#7 UH 866 16384 lo0 198.51.100.0/24 link#1 U 1251477 1500 em0 198.51.100.7 link#1 UHS 0 16384 lo0
The OpenVPN interface is
10.6.203.2, with a gateway of
the interface is
ovpnc2. The network reachable using OpenVPN in this example
With tunnel mode IPsec, traceroute is not as useful as with routed setups, because a tunnel mode IPsec connection does not have an interface or IP addresses. When running traceroute to a destination across tunnel mode IPsec, the client will experience a timeout when crossing the IPsec tunnel.