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.

Warning

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.

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

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 (the one with the ASCII logo)

  • Press Enter when prompted to start /bin/sh

  • Remount all partitions as rewritable:

    # /sbin/mount -a -t ufs
    
  • Run the built-in password reset command:

    # /etc/rc.initial.password
    
  • Follow the prompts to reset the password

  • Run /sbin/reboot to reboot.

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:

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

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 fa-trash 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.

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 8 from 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
    

    or:

    # squid -k shutdown
    

Once the squid process is fully terminated, use console menu option 11 to restart the GUI process, and then attempt to access the GUI again.

Note

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