Under certain circumstances an administrator can be locked out of the WebGUI. Don’t be afraid if this happens; there are a number of ways to regain control. Some methods are a little tricky, but it is nearly always possible to recover access. The worst-case scenarios require physical access, as anyone with physical access can bypass security measures.
Let the tactics in this section be a lesson. Physical security of a firewall is critical, especially in environments where the firewall is physically located in a common area accessible to people other than authorized administrators.
The firewall administrator password can easily be reset using the firewall console if it has been lost. Access the physical console (Serial or Keyboard/Monitor) and use option 3 to reset the WebGUI password. This option can also reset the admin account if it has been disabled or expired.
After resetting the password, the admin user can login with the default password pfsense.
When the firewall reboots, the admin user can login with the default password pfsense.
To reset this from the console, reset the LAN interface IP Address, enter the same IP address, and the script will prompt to reset the WebGUI back to HTTP.
If a remote administrator loses access to the WebGUI due to a firewall rule change, then access can still be obtained from the LAN side. The LAN rules cannot prevent access to the GUI unless the anti- lockout rule is disabled. The anti-lockout rule ensures that hosts on the LAN are able to access the WebGUI at all times, no matter what the other rules on the LAN interface block.
Having to walk someone on-site through fixing the rule from the LAN is better than losing everything or having to make a trip to the firewall location!
There are a few ways to manipulate the firewall behavior at the shell to regain access to the firewall GUI. The following tactics are listed in order of how easy they are and how much impact they have on the running system.
Once the easyrule script adds the rule, the client will be able to access the GUI from the specified source address.
Another tactic is to temporarily activate an “allow all” rule on the WAN to let a client in.
Once the administrator regains access and fixes the original issue preventing them from reaching the GUI, remove the “allow all rule” on WAN.
An administrator can (very temporarily) disable firewall rules by using the physical console or SSH.
This completely disables pf which disables firewall rules and NAT. If the network run by this firewall relies on NAT to function, which most do, then running this command will disrupt connectivity from the LAN to the Internet.
After getting back into the WebGUI with that temporary fix, the administrator must perform whatever work is required in the WebGUI to make the fix permanent. When the rules are saved in the WebGUI, the temporary edit to /tmp/rules.debug will be overwritten.
If remote access to the WebGUI is blocked by the firewall, but SSH access is allowed, then there is a relatively easy way to get in: SSH Tunneling.
If the WebGUI is on port 80, set the SSH client to forward local port 443 (or 4443, or another port) to remote port localhost:443. If the firewall WebGUI is on another port, use that as the target instead. Then point the browser to https://localhost. Add the port to the end of the URL if it differs from the default 443, for example https://localhost:4443. If the GUI is using HTTP, change the protocol on the URL to http://.
Fill out the options as shown in Figure Setting Up a Port 80 SSH Tunnel in PuTTY, then click Add.
Once the client connects and authenticates, the WebGUI is accessible from the redirected local port.
If a firewall administrator accidentally configures Squid to use the same port as the WebGUI, it can cause a race condition for control of the port, depending on which service (re)starts at a particular time. If Squid manages to get control of the port that the WebGUI wants, then the WebGUI will not be accessible to fix the configuration.
The following procedure may help to regain control.
Start a shell, option 8 from the console.
Once the squid process is fully terminated, use console menu option 11 to restart the WebGUI process, and then attempt to access the WebGUI again.
Work quickly or repeat the shutdown command, as squid may be automatically restarted by its internal monitoring scripts depending on the method used to stop the process.