The Setup Wizard and related configuration tasks will work for most situations, but there may be issues getting connections to flow normally in their intended directions. Some of these issues may be unique to a particular environment or configuration, but can be worked through with basic troubleshooting.
Cannot access WebGUI from LAN¶
If the WebGUI is not accessible from the LAN, the first thing to check is cabling. If the cable is a hand-made cable or _shorter_ than 3 feet (One meter), try a different cable. If the client PC is directly connected to a network interface on the firewall, a crossover cable may be needed on older hardware that does not have Auto-MDIX support on its network cards. This is not a concern on gigabit or faster hardware.
Once there is a link light on both the client network card and the firewall LAN interface, check the TCP/IP configuration on the client PC. If the DHCP server is enabled on the firewall, as it is by default, ensure that the client is also set for DHCP. If DHCP is disabled on the firewall, hard code an IP address on the client residing in the same subnet as the firewall LAN IP address, with the same subnet mask, and use the firewall LAN IP address as the gateway and DNS server.
If the cabling and network settings are correct, the client will be able to ping the LAN IP address of the firewall. If the client PC can ping, but not access the WebGUI, there are still a few more things to try. First, if the error on the client PC is a connection reset or failure, then either the server daemon that runs the WebGUI is not running or the client is attempting to use the wrong port. If the error is instead a connection timeout, that points more toward a firewall rule.
If the client receives a connection timeout, refer to What to do when locked out of the WebGUI. With a properly configured network connection, this shouldn’t happen, and that section offers ways to work around firewall rule issues.
Double check that WAN and LAN are not on the same subnet. If WAN is set for DHCP
and is plugged in behind another NAT router, it may also be using
192.168.1.1. If the same subnet is present on WAN and LAN, unpredictable
results may happen, including not being able to route traffic or access the
WebGUI. When in doubt, unplug the WAN cable, reboot the pfSense firewall, and
If the client receives a connection reset, first try to restart the WebGUI server process from the system console, typically option 11, followed by option 16 to restart PHP-FPM. If that does not help, start a shell from the console (option 8), and type:
# sockstat | grep nginx
The firewall will return a list of all running
nginx processes, and the
port upon which they are listening, like this:
root nginx 41948 5 tcp4 *:443 *:* root nginx 41948 6 tcp6 *:443 *:* root nginx 41948 7 tcp4 *:80 *:* root nginx 41948 8 tcp6 *:80 *:*
In that output, it shows that the process is listening on port 443 of each interface on both IPv4 and IPv6, as well as port 80 for the redirect, but that may vary based on the firewall configuration.
Try connecting to the firewall LAN IP address by using that port directly, and
with both HTTP and HTTPS. For example, if the LAN IP address was
192.168.1.1, and it was listening on port
No Internet from LAN¶
If the client PC is able to reach the WebGUI but not the Internet, there are several things to consider. The WAN interface may not be properly configured, DNS resolution may not be working, there could be a problem with the firewall rules, NAT rules, or even something as simple as a local gateway issue.
WAN Interface Issues¶
First, check the WAN interface to be sure it is operational. Browse to Status > Interfaces and look at the WAN interface status there. If the interface is working properly the status will show as “up”. If it shows “no carrier” or “down”, double check the cabling and WAN settings under Interfaces > WAN.
If the interface is using PPPoE or PPTP for the WAN type, there is an additional status line indicating if the PPP connection is active. If it is down, try pressing the Connect button. If that doesn’t work, double check all of the interface settings on Interfaces > WAN, check or reboot the ISP CPE (cable/DSL modem, etc.), and perhaps consult with the ISP for help regarding the settings and circuit state.
DNS Resolution Issues¶
Inside the WebGUI, navigate to Diagnostics > Ping and enter in the ISP gateway address. The gateway address is listed on Status > Interfaces for the WAN interface and under Status > Gateways.
If the gateway is unknown, try another known-valid address such as
If the firewall is able to ping that address and receive a response, then repeat
that same ping test from the client PC. Open a command prompt or terminal
window, and ping that same IP address.
If the client can ping by IP address, then try to ping a web site by name such
www.google.com. Try it from the firewall GUI and from the client PC. If
the IP ping test works, but the name test fails, then there is a problem with
DNS resolution. See Figure
Testing Connectivity for Bogon Updates for an example.
If DNS resolution does not work on the firewall, first check which DNS service is enabled on the firewall and how it is configured. By default, a pfSense firewall is configured to use the DNS Resolver in a mode that does not require any specific DNS servers. It queries the root servers and other authoritative servers directly. Older installations and upgraded installations default to the DNS Forwarder, which requires DNS Servers to be entered under System > General Setup or to be acquired from a dynamic WAN such as DHCP or PPPoE. The DNS Resolver can also operate in this mode if Enable Forwarding Mode is activated in its settings.
If the DNS Resolver is active but the firewall is unable to resolve hostnames, the problem is usually a lack of working WAN connectivity. Aside from that, one possibility is that the WAN or upstream network gear does not properly pass DNS traffic in a way that is compatible with DNSSEC. Disable DNSSEC in the Resolver options to see if that allows resolution to function. It is also possible that the ISP filters DNS requests and requires the use of specific DNS servers. In that case, configure DNS servers and then activate forwarding mode or switch to the DNS Forwarder.
The firewall DNS server settings are under System > General Setup, and are also visible at Status > Interfaces. Check with ping to be sure these DNS servers are reachable. If the firewall can reach the gateway address at the ISP, but not the DNS servers, contact the ISP and double check those values. If the DNS servers are obtained via DHCP or PPPoE and the firewall cannot reach them, contact the ISP. If all else fails, consider using Google’s public DNS (126.96.36.199, 188.8.131.52) name servers on the firewall instead of those provided by the ISP.
If DNS works from the pfSense firewall but not from a client PC, it could be the
DNS Resolver or Forwarder configuration on the firewall, the client
configuration, or firewall rules. Out of the box, the DNS Resolver handles DNS
queries for clients behind the firewall. If the client PCs are configured with
DHCP, they will receive the IP address of the firewall interface to which they
are connected as a DNS server, unless that is manually changed. For example, if
a PC is on the LAN interface, and the firewall LAN IP address is
192.168.1.1, then the client DNS server should also be
the DNS Resolver and DNS Forwarder are disabled, adjust the DNS servers which
get assigned to DHCP clients under Services > DHCP Server. Normally when the
DNS Resolver and DNS Forwarder are disabled, the system DNS servers are assigned
directly to the clients, but if that is not the case in practice for this setup,
define them in the DHCP settings. If the client PC is not configured for DHCP,
be sure it has the proper DNS servers set: either the LAN IP address of the
pfSense firewall or an alternate set of working internal or external DNS
Another possibility for DNS working from the pfSense firewall but not a local client is an overly strict firewall rule on the LAN. Check Status > System Logs, on the Firewall tab. If blocked connections appear in the log from the local client trying to reach a DNS server, then add a firewall rule at the top of the LAN rules for that interface which will allow connections to the DNS servers on TCP and UDP port 53.
Client Gateway Issue¶
In order for a pfSense firewall to properly route Internet traffic for client
PCs, it must be their gateway. If client PCs are configured using the DHCP
server built into pfSense firewalls, this will be set automatically. However, if
the clients receive DHCP information from an alternate DHCP server, or their IP
addresses have been entered manually, double check that their gateway is set for
the IP address of the interface to which they connect on the pfSense firewall.
For example, if the clients are on the pfSense LAN interface and the IP address
for the LAN interface is
192.168.1.1, then the gateway address on the client
PCs must be set to
Firewall Rule Issues¶
If the default “LAN to Any” rule has been changed or removed from the LAN interface, traffic attempting to reach the Internet from client PCs via the pfSense firewall may be blocked. This is easily confirmed by browsing to Status > System Logs and looking at the Firewall tab. If there are entries there that show blocked connections from LAN PCs trying to reach Internet hosts, revisit the LAN ruleset at Firewall > Rules, on the LAN tab to make the necessary adjustments to allow that traffic. Consult Firewall for more detailed information on editing or creating additional rules.
If it works from the LAN side but not from an OPT interface, be sure the firewall has rules in place to allow the traffic to pass. Rule are not created by default on OPT interfaces.
NAT Rule Issues¶
If the outbound NAT rules have been changed from their defaults, traffic attempting to reach the Internet may not have NAT properly applied. Navigate to Firewall > NAT, Outbound tab. In most cases the setting should be on Automatic outbound NAT rule generation. If it is not, change to that setting, Click Save and Apply Changes, and then try to reach the Internet from a client PC again. If that did not help a PC on the LAN to get out, then the issue is likely elsewhere.
If Outbound NAT is set to Manual Outbound NAT rule generation and Internet access works from LAN but not from an OPT interface, manually add rules that matches traffic coming from the OPT interface. Look at the existing rules for LAN and adjust them accordingly, or refer to Outbound NAT for more information on creating outbound NAT rules.
The same applies for traffic coming from VPN users: OpenVPN, IPsec, etc. If these users need to reach the Internet via this pfSense firewall, they will need outbound NAT rules for their subnets. See Outbound NAT for more information.