Troubleshooting Access when Locked Out of the Firewall¶

Under certain circumstances an administrator can be locked out of the GUI. There are a number of ways to regain control, so it is not necessarily a major cause for concern. 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.

Danger

Let the tactics in this document 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.

Forgotten 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 change the password for the admin account. This option can also reset the admin account if it is disabled or expired.

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
Press Enter when prompted to start /bin/sh
Remount all partitions as rewritable:

The specific commands vary based on the filesystem.
- For devices installed using UFS, see Re-mount UFS Volumes as Read/Write.
- For devices installed using ZFS, see Re-mount ZFS Volumes as Read/Write.
Run the built-in admin account reset command:
```
# /etc/rc.initial.password
```
Follow the prompts to change the password
Run /sbin/reboot to reboot.

HTTPS Certificate Problems¶

If the browser refuses to connect due to the certificate itself, or if the GUI web server refuses to run due to the certificate, then the easiest method to regain access is to generate a new self-signed certificate from the console or SSH:

# pfSsh.php playback generateguicert

That will create a new self-signed GUI certificate, activate it, and restart the GUI web server.

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:

http://<hostname>:443
https://<hostname>:80

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.

Warning

If the browser previously connected to the GUI using HTTPS, it may refuse to connect using HTTP for security reasons (e.g. HSTS).

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
Select sshguard
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 443:

# easyrule pass wan tcp x.x.x.x y.y.y.y 443

Once the 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.

Warning

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.

Warning

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.

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 overwritten.

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 443 (or 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 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://.

../_images/puttysshtunnel.png — Setting Up a Port 443 SSH Tunnel in PuTTY¶

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.

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 admin account.

Connect to the console (Connect to the Console) or ssh and run option 3 to reset the credentials to the Default Username and Password.