Troubleshooting Network Connectivity

The following list covers most causes of outbound connectivity failure in common usage scenarios.

Each test assumes the items above it have been checked. This document assumes a single WAN but most of the advice is relevant to multiple WANs.

WAN Interface

• Check the WAN IP address (Interfaces > WAN)

  • This is only relevant to static WANs, dynamic WANs handle addresses automatically

  • Using the wrong address could prevent the ISP from delivering traffic to/from the firewall, among other issues

• Check that the WAN IP address has the correct subnet mask (Interfaces > WAN)

  • This is only relevant to static WANs, dynamic WANs handle subnet masks automatically

  • An improper subnet mask such as /1 could cause connectivity issues to large portions of the Internet, using /32 for a mask could prevent the firewall from contacting its gateway

• Check that WAN has a gateway and that the gateway IP address is correct (Interfaces > WAN)

  • This is only relevant to static WANs, dynamic WANs handle gateways automatically

  • This interferes with automatic outbound NAT and route-to/reply-to

• Check the default gateway configuration (System > Routing)

  • Without a default gateway traffic has no exit path

  • If it is set to Automatic, the automatic selection process may have chosen a non-viable gateway

• Check that the default gateway shows Online (Status > Gateways)

  • If it is not, verify the WAN settings and gateway settings, or use an alternate monitor IP address

• Check the default gateway in the routing table (Diagnostics > Routes)

  • Another source such as a VPN may have changed the default gateway

LAN Interface

• Check the LAN IP address (Interfaces > LAN)

  • Using an invalid IP address (e.g. .0 or .255 in a /24) will cause problems reaching addresses locally.

• Check the LAN subnet mask (Interfaces > LAN)

  • Using an incorrect subnet mask, such as /32, will prevent other hosts in the LAN subnet from finding the firewall LAN address to use as a gateway and vice versa

• Check that LAN does NOT have a gateway set (Interfaces > LAN)

  • This will interfere with automatic outbound NAT

• Check that LAN does NOT have Block Private Networks set (Interfaces > LAN)

  • If the LAN subnet is using a private network, this will block local traffic.

• Check that LAN does NOT have Block Bogon Networks set (Interfaces > LAN)

  • If the LAN subnet is using a private network, this will block local traffic.

Firewall/Rules

• Check the firewall log for blocked connections from hosts on LAN (Status > System Logs, Firewall tab)

  • If the log contains entries showing blocked connections, check the rule that triggered the block and adjust rules accordingly (Firewall > Rules, LAN tab)

• Check that the LAN rule allows all protocols, or at least TCP and UDP ports for reaching DNS and HTTP/HTTPS, and allows ICMP for testing. (Firewall > Rules, LAN tab)

  • Not allowing UDP would make DNS fail, among other things.

  • Similarly, on a DNS rule, using UDP only and not TCP/UDP will cause larger queries to fail.

  • Not allowing ICMP would cause ping to fail, but other protocols may work

  • Not allowing TCP would cause HTTP, HTTPS, and other protocols to fail.

• Check that the LAN rules allow to a destination of any (Firewall > Rules, LAN tab)

  • Using the wrong destination would not allow traffic to reach the Internet. For example, WAN net is only the subnet of the WAN interface, NOT the Internet, so typically the correct setting is any.

• Check that the LAN rule does not have an improper gateway set (Firewall > Rules, LAN tab)

  • If it is set to leave by another (possibly broken) non-WAN gateway it would cause the connections to fail

Outbound NAT

• Check Outbound NAT, ensure it is set for Automatic or Hybrid outbound NAT (Firewall > NAT, Outbound tab)

  • If the firewall requires manual outbound NAT, skip to the next test

  • Incorrect NAT settings will prevent traffic from reaching WAN

• Check manual outbound NAT rules, if in use, to ensure that they match local traffic sources

  • Incorrect NAT settings will prevent traffic from reaching WAN

Diagnostic Tests

• Check connectivity from the firewall itself: Try to ping 8.8.8.8 (Diagnostics > Ping)

  • If this does not work, ensure proper WAN settings, gateway, etc.

• Check DNS: Try to lookup pfsense.org (Diagnostics > DNS Lookup)

  • If this does not work, fix/change the DNS configuration (Troubleshooting DNS Resolution Issues)

• Test NAT: Try to ping 8.8.8.8 using LAN as the Source Address (Diagnostics > Ping)

  • If this fails but the other tests work, then the problem is likely outbound NAT (See the WAN/LAN gateway checks above)

Client Tests

• Test if the client can ping the LAN IP address of the firewall

  • If this fails, check the LAN rules, client IP address/subnet mask, LAN IP address/subnet mask, etc.

• Test if the client can ping the WAN IP address of the firewall

  • If this fails, check the client subnet mask and gateway

• Test if the client can ping the WAN Gateway IP address of the firewall

  • If this fails, check the client subnet mask and gateway, and double check outbound NAT on the firewall

• Test if the client can ping an Internet host by IP address (e.g. 8.8.8.8)

  • If this fails, check the client subnet mask and gateway, and triple check outbound NAT on the firewall

• Test if the client can ping an Internet host by Host name (e.g. www.google.com)

  • If this fails, check the client DNS settings, and/or the DNS Resolver or Forwarder on the firewall (Services > DNS Resolver, Services > DNS Forwarder, Diagnostics > DNS Lookup)

Miscellaneous Additional Areas

• If Captive Portal is enabled, disable it temporarily (Services > Captive Portal).

  • See Captive Portal Troubleshooting.

• Check for packages such as pfBlockerNG, Snort, or Suricata, that might interfere with connectivity and disable them if necessary

  • Improperly configured packages could allow certain traffic such as ICMP ping to work but might prevent access to HTTP and/or HTTPS sites.