How to troubleshoot Routes on Netgate router

Authored by: Support.com Tech Pro Team

1. Introduction

How to troubleshoot Routes on Netgate router

2. Resolution

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 in 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.8destination: 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.4destination: 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 -rWnRouting tablesInternet:Destination Gateway Flags Use Mtu Netif Expiredefault 198.51.100.1 UGS 92421 1500 em010.6.0.0/16 10.6.203.1 UGS 0 1500 ovpnc210.6.203.0/24 10.6.203.2 UGS 0 1500 ovpnc210.6.203.1 link#9 UH 0 1500 ovpnc210.6.203.2 link#9 UHS 0 16384 lo010.7.0.0/24 link#2 U 1260771 1500 em110.7.0.1 link#2 UHS 0 16384 lo0127.0.0.1 link#7 UH 866 16384 lo0198.51.100.0/24 link#1 U 1251477 1500 em0198.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.