Troubleshooting Access when Locked Out of the Firewall¶
Under certain circumstances an administrator can be locked out of the GUI. 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.
Before taking any of these steps, try the Default Username and Password.
The firewall administrator password can easily be reset using the firewall
console if it has been lost. Access the physical console
(Connect to the Console) and use option
3 to reset the
password. This option can also reset the admin account if it is disabled or
After resetting the password, login with the Default Username and Password.
Forgotten Password with a Locked Console¶
If the console is password protected, all is not lost. It takes two reboots to accomplish, but the password can be reset with physical access to the console:
Connect to the console
Reboot the firewall
Choose the Boot Single User option (
2) from the loader menu with the ASCII logo
Enterwhen prompted to start
Remount all partitions as rewritable:
For systems installed using UFS:
# /sbin/mount -a -t ufs
For systems installed using ZFS:
# /sbin/mount -u / # /sbin/zfs mount -a # /sbin/nextboot -D
Run the built-in password reset command:
Follow the prompts to reset the password
When the firewall reboots, login with the Default Username and Password.
HTTP vs HTTPS Confusion¶
Ensure the client is connecting with the proper protocol, either HTTP or HTTPS. If one doesn’t work, try the other. If the GUI has not been configured correctly, the firewall may be running the GUI on an unexpected port and protocol combination, such as:
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 GUI back to HTTP.
Blocked Access with Firewall Rules¶
If a remote administrator loses access to the GUI 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 GUI 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!
Locked Out by Too Many Failed Login Attempts¶
Attempting to login to the GUI or SSH and failing many times will cause the connecting IP address to be added to the lockout table.
To regain access, login successfully from another IP address and then manually remove the entry as follows:
Navigate to Diagnostics > Tables
Click by the entry or entries for workstations to allow again.
The lockout table may also be cleared by the console or ssh in the shell:
pfctl -T flush -t sshguard
Remotely Circumvent Firewall Lockout with Rules¶
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.
Add a rule with EasyRule¶
The easiest way, assuming the administrator knows the IP address of a remote
client PC that needs access, is to use the
easyrule shell script to add a
new firewall rule. In the following example, the
easyrule script will allow
access on the WAN interface, from
x.x.x.x (the client IP address) to
y.y.y.y (presumably the WAN IP address) on TCP port
# easyrule pass wan tcp x.x.x.x y.y.y.y 443
easyrule script adds the rule, the client will be able to access
the GUI from the specified source address.
Add an allow all WAN rule from the shell¶
Another tactic is to temporarily activate an “allow all” rule on the WAN to let a client in.
An “allow all” style rule is dangerous to have on an interface connected to a public or untrusted network, such as a WAN interface connected to the Internet. Do not forget to remove the rule added by this script
To add an “allow all” rule to the WAN interface, run the following command at a shell prompt:
# pfSsh.php playback enableallowallwan
Once the administrator regains access and fixes the original issue preventing them from reaching the GUI, remove the “allow all” rule from the WAN.
Disable the Firewall¶
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
To disable the firewall, connect to the physical console or ssh and use option
8 to start a shell, and then type:
# pfctl -d
That command will disable the firewall, including all NAT functions. Access to the GUI is now possible from anywhere, at least for a few minutes or until a process on the firewall causes the ruleset to be reloaded (which is almost every page save or Apply Changes action). Once the administrator has adjusted the rules and regained the necessary access, turn the firewall back on by typing:
# pfctl -e
Manual Ruleset Editing¶
The loaded ruleset is retained in
/tmp/rules.debug. If the administrator is
familiar with PF ruleset syntax, they can edit that file to fix the connectivity
issue and reload those rules:
# pfctl -f /tmp/rules.debug
After getting back into the GUI with that temporary fix, the administrator must
perform whatever work is required in the GUI to make the fix permanent. When the
rules are saved in the GUI, the temporary edit to
/tmp/rules.debug will be
Remotely Circumvent Firewall Lockout with SSH Tunneling¶
If remote access to the GUI is blocked by the firewall, but SSH access is allowed, then there is a relatively easy way to get in: SSH Tunneling.
If the GUI is on port
443, set the SSH client to forward local port
4443, or another port) to remote port
localhost:443. If the firewall
GUI is on another port, use that as the target instead. Then point the
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
Fill out the options as shown in Figure Setting Up a Port 443 SSH Tunnel in PuTTY, then click Add.
Once the client connects and authenticates, the GUI is accessible from the redirected local port.
Locked Out Due to Squid Configuration Error¶
If a firewall administrator accidentally configures Squid to use the same port as the GUI, 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 GUI wants, then the GUI will not be accessible to fix the configuration.
The following procedure may help to regain control.
Connect to the firewall console with SSH or physical access
Start a shell, option
8from the console.
Terminate the squid process:
# /usr/local/etc/rc.d/squid.sh stop
If that doesn’t work, try this command instead:
# killall -9 squid
# squid -k shutdown
Once the squid process is fully terminated, use console menu option
restart the GUI process, and then attempt to access the GUI 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.
Authentication Server Failure¶
LDAP and RADIUS authentication for the GUI automatically fall back to the local
database if they fail. If the authentication server fails and all local accounts
are disabled, locked out, passwords are not known, etc., then to get back in,
regain access to the local