The following list covers most causes of outbound connectivity failure in commonusage scenarios.
Each test assumes the items above it have been checked. This document assumes asingle 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 addressesautomatically
Using the wrong address could prevent the ISP from delivering trafficto/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 masksautomatically
An improper subnet mask such as
/1
could cause connectivity issues tolarge portions of the Internet, using/32
for a mask could prevent thefirewall 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 gatewaysautomatically
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 chosena non-viable gateway
Check that the default gateway shows Online (Status > Gateways)
See AlsoConnecting your new pfSense router to the networkNetgateRouter vs. Firewall - Check Point SoftwarepfSense Wi-Fi routerIf it is not, verify the WAN settings and gateway settings, or use analternate 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
) willcause problems reaching addresses locally.
Check the LAN subnet mask (Interfaces > LAN)
Using an incorrect subnet mask, such as
/32
, will prevent other hosts inthe LAN subnet from finding the firewall LAN address to use as a gateway andvice 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 thattriggered the block and adjust rules accordingly (Firewall > Rules,LAN tab)
Check that the LAN rule allows all protocols, or at least TCP and UDP portsfor 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 largerqueries 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, NOTthe 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 wouldcause the connections to fail
Outbound NAT¶
Check Outbound NAT, ensure it is set for Automatic or Hybrid outboundNAT (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 localtraffic 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 outboundNAT (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 IPaddress/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 checkoutbound 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 checkoutbound 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 orForwarder on the firewall (Services > DNS Resolver, Services > DNSForwarder, Diagnostics > DNS Lookup)
Miscellaneous Additional Areas¶
If Captive Portal is enabled, disable it temporarily (Services > CaptivePortal).
See Captive Portal Troubleshooting.
Check for packages such as pfBlockerNG, Snort, or Suricata, that mightinterfere with connectivity and disable them if necessary
Improperly configured packages could allow certain traffic such as ICMP pingto work but might prevent access to HTTP and/or HTTPS sites.