Troubleshooting GUI Connectivity

If the GUI 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/1 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 GUI, 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 GUI 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 Troubleshooting Access when Locked Out of the Firewall. 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 GUI. When in doubt, unplug the WAN cable, reboot the firewall, and try again.

If the client receives a connection reset, first try to restart the GUI 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 82, try http://192.168.1.1:82 and https://192.168.1.1:82.