Troubleshooting Routes¶

When diagnosing traffic flow issues, one of the first things to check is the routes known to the firewall.

Viewing Routes¶

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 8.8.8.8:

$ route -n get 8.8.8.8
   route to: 8.8.8.8
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 8.8.4.4 using an alternate gateway:

: route -n get 8.8.4.4
   route to: 8.8.4.4
destination: 8.8.4.4
    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.

Using traceroute¶

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 tracert.

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 10.6.203.1 and the interface is ovpnc2. The network reachable using OpenVPN in this example is 10.6.0.0/16.

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.