Netgate is offering COVID-19 aid for pfSense software users, learn more.
Admin Access Tab¶
The options on the Admin Access tab govern various methods for administering the firewall, including via the web interface, SSH, serial, and physical console.
The protocol used by the GUI to accept web browser connections. May be either HTTP or HTTPS.
The best practice is to use HTTPS so only encrypted traffic is exchanged between the GUI and web browsers.
Using HTTPS also requires a certificate, set by the SSL/TLS Certificate drop-down list. The default certificate is a self-signed certificate automatically generated by the firewall. That is not an ideal situation, but is better than no encryption at all.
The primary disadvantage of a self-signed certificate is the lack of assurance of the identity of the host, since the certificate is not signed by a Certificate Authority trusted by the browser. Additionally, because for the bulk of Internet users such an invalid certificate should be considered a risk, modern browsers have been cracking down on how they are handled. Firefox, for example, gives a warning screen and forces the user to import the certificate and allow a permanent exception. Chrome shows a warning screen with a link to continue.
To use an externally signed SSL certificate and key, import them using the Certificate Manager, then select the certificate here.
Another alternate technique is to generate a self-signed CA and then generate a GUI certificate from that CA. Export the CA from pfSense and then import that CA into client browsers manually. Using this method, all certificates signed by that CA will be trusted by browsers. Specifics vary by client platform.
To generate a new self-signed certificate for the GUI, connect using the console or ssh and from a shell prompt, run the following command:
pfSsh.php playback generateguicert
The port used by the GUI for accepting connections from browsers. By default the
WebGUI uses HTTPS on port
443 with a redirect from port
80 for the best
compatibility and ease of initial configuration. To change the port, enter a new
port number into the TCP Port field.
Moving the WebGUI to an alternate port is preferred by some administrators for security by obscurity reasons, though such practices should not be considered as offering any security benefit. Do not expose the GUI to untrusted networks such as the Internet.
Moving the GUI to another port will free up the standard web ports for use with port forwards or other services such as HAproxy.
The number of web server worker proceses used by the GUI when listening for
client browser connections. The default value is
If multiple administrators view the GUI at the same time and pages are taking too long to load, or are failing to load, then increase the Max Processes value.
Controls whether or not the firewall runs a redirect on port
80 so that if a
browser attempts to access the firewall with HTTP, the firewall will accept the
request and then redirect the browser to HTTPS on the port used by the GUI (e.g.
The redirect is enabled by default for ease of access and compatibility.
Disabling the redirect also allows another daemon to bind to port
Controls whether the GUI web server sends the
HTTPS response header (HSTS) to the browser. Check this box to disable the
HSTS forces the browser to use only HTTPS for future requests to the firewall FQDN to ensure it does not accidentally downgrade to an unencrypted connection.
When disabling HSTS, clients which visited the GUI when HSTS was enabled must perform browser-specific steps for the change to take effect. Consult browser documentation for information on clearing cached HSTS behavior.
Controls whether or not the GUI web server forcefully enables OCSP Stapling.
If the GUI SSL/TLS Certificate requires OCSP Stapling, this behavior is automatically enabled by the GUI web server. If the certificate property cannot be automatically determined by the firewall, this option can force the behavior.
Import the full CA and certificate chain or this option will be ignored by the GUI web server.
WebGUI Login Autocomplete¶
Controls whether or not the login form allows autocomplete so browsers can save the login credentials, for convenience.
In high-security environments, such as those that must adhere to specific security compliance standards, this behavior is not acceptable.
This only controls autocomplete on the login form.
Few modern browsers respect this option. Many still offer to save passwords even when the form specifies that the browser must not allow the behavior. This behavior must be controlled or changed using browser options.
WebGUI login messages¶
Controls whether or not the firewall prints successful login messages to the console and system log.
On hardware with a PC speaker, these console messages generate a beep from the speaker, which some users find undesirable.
Checking this option stops the log message and the resulting beep.
Controls whether or not the firewall adds special rules to permit access to the WebGUI port and SSH port on the LAN interface by default.
These special rules override user-defined filter rules and prevent the user from accidentally locking themselves out of the firewall GUI or SSH. To control which LAN IP addresses may access the GUI and SSH using firewall rules, disable the anti-lockout rules.
When two or more interfaces are present, the firewall puts anti-lockout rules on the LAN interface; If only one interface is configured, the firewall places rules on that interface instead.
Filter rules must be in place to allow GUI access before enabling this option! If the LAN rules do not allow access to the GUI, removing the anti-lockout rule will block access to the GUI, potentially leaving the administrator without a means to reach the firewall.
Resetting the LAN IP address from the console also resets the
anti-lockout rule. If administrative access is unavailable after enabling
this option, choose the console menu option
2, then choose to set the
LAN IP address, and enter in the exact same IP address and accompanying
DNS Rebind Check¶
Controls whether or not the DNS resolver or forwarder performs DNS rebinding checks. These checks prevent the firewall from receiving DNS responses containing private IP addresses from DNS servers to prevent DNS rebinding attacks.
When accessing the firewall by IP address, these checks are not enforced because the attack is only relevant when using a hostname.
Check this box to disable DNS rebinding protection if it interferes with GUI access or name resolution.
More detail on DNS rebinding attacks may be found on Wikipedia.
The most common case for disabling DNS rebinding checks is when the firewall is set to use an internal DNS server which will return private (RFC1918) answers for hostnames.
Browser HTTP_REFERER enforcement¶
Controls whether or not the GUI checks and enforces HTTP_REFERER contents.
The GUI checks the referring URL sent by a client browser to ensure that the form was submitted from this firewall. This check prevents a form on another site from submitting a request to the firewall, changing an option when the administrator did not intend for that to happen.
This also breaks some convenience behaviors, such as having a page that links to various firewall devices, though the benefits of the check typically outweigh the advantage of those behaviors.
A list of Alternate Hostnames for the firewall allowed by DNS Rebind Checks and HTTP_REFERER Enforcement. To keep these features active, but alter their behavior slightly, add Alternate Hostnames.
By default the GUI allows access to the hostname configured on the firewall and all IP addresses configured on the firewall. Hostnames in this field are allowed by the firewall for GUI access and for referring URL purposes.
If a browser attempts to access the GUI using an IP address that is not configured on the firewall, such as a port forward from another firewall, the GUI prints a message indicating that access to the firewall may be compromised due to a Man-In-The-Middle (MITM) attack.
If such a forwarding was deliberatey configured on this firewall or on a firewall upstream, the message may be safely ignored. If access to the firewall should have been direct, then take great care before logging in to ensure the login credentials are not being routed through an untrusted system.
Access is not disabled by the firewall in this case, it only prints a warning, so there is no option to disable this behavior.
Browser Tab Text¶
By default, the GUI prints the firewall hostname first in the page/tab title, followed by the page name. To reverse this behavior and show the page name first and hostname second, check Display page name first in browser tab.
Administrators who access many firewalls at the same time in separate tabs tend to prefer having the hostname first (default). Administrators who access one firewall with many pages in separate tabs tend to prefer having the page name first.
Secure Shell (SSH)¶
The Secure Shell (SSH) server provides remote console access and file management. A user can connect with any standard SSH client, such as the OpenSSH command line ssh client, PuTTY, SecureCRT, or iTerm.
When using SSH, both the
admin username and
root username are accessible
using the admin account credentials.
Users in the User Manager that have the
User - System - Shell account access
privilege are also allowed to login over ssh. These users do not have root
access privileges, and do not print the menu when they login because many of the
options require root privileges.
To grant users additional shell privileges, use the sudo package.
File transfers to and from the firewall are also possible by using a Secure Copy
(SCP) client such as OpenSSH’s command line
scp, FileZilla, WinSCP or Fugu.
To use SCP, connect as the
root user, not
admin. If a custom user has
User - System - Copy files permission, or all access, then they may also
SSH clients must be kept up-to-date. As time goes on, security
standards evolve and the SSH server settings utilized by pfSense software
will change. Outdated clients may not be able to connect using the strong
security keys and algorithms required by
sshd. If a client will not
connect, check for an update from the vendor.
Enable Secure Shell¶
To enable the SSH daemon, check Enable Secure Shell. After saving with this option enabled, the firewall will generate SSH keys if they are not already present and then start the SSH daemon.
SSHd Key Only¶
This option controls which authentication methods the SSH daemon allows for clients. It can be set to one of the following values:
- Password or Public Key
Allows a user to authenticate with either a valid password or valid key. This is the default behavior.
- Public Key Only
Restricts authentication to only valid keys, passwords are not allowed.
- Require Both Password and Public Key
Requires a valid password and a valid key.
Key-based logins are a much more secure practice, though it does take more preparation to configure.
Add user keys for key-based login by editing users in the User Manager (User Management and Authentication). When editing a user, paste the allowed public keys into the Authorized Keys text field for the account.
Allow Agent Forwarding¶
Controls whether or not the SSH daemon allows agent forwarding for clients.
Agent forwarding allows a user to run an SSH agent on their client system and connect to the firewall, and then to other remote SSH servers using the key from their agent. In this case, the user does not need to have their private keys on the firewall but can still use key-based authentication to remote servers.
Use of an SSH agent can be considered a security issue in certain cases. Additionally, the firewall is not intended to be a general purpose SSH client or intermediate system, thus this feature is disabled by default.
Controls the port used by the SSH daemon to accept client connections. To change the port, type the new port into the SSH Port box.
Moving the SSH server to an alternate port provides a negligible security improvement, and frees up the port for other uses.
Brute force SSH scanners focus on hitting TCP port
22 but if the
daemon is open to the Internet on another port, it will eventually be found
and hit by scanners.
Best Practices for SSH¶
If this firewall is installed in an environment that requires leaving SSH access unrestricted by firewall rules, which is dangerous, we strongly recommended the following actions:
- Change the SSH Port
Moving to a random alternate port prevents log noise from many, but not all, brute-force SSH login attempts and casual scans. It can still be found with a port scan, however.
- Force Key-Based Authentication
Key-based authentication must always be used by publicly accessible SSH servers to eliminate the possibility of successful brute force attacks. Set SSHd Key Only to either Public Key Only or Require Both Password and Public Key.
Multiple unsuccessful logins from the same IP address will result in locking out the IP address trying to authenticate, but that alone is not considered sufficient protection.
sshguard daemon is used by the firewall to protect against brute force
logins for both the GUI and SSH connections. The options in this section
fine-tune the behavior of this protection.
The total score value above which
sshguardwill block clients. Most attacks have a score of
10, the default threshold value is
The initial minimum number of seconds to block attackers who have exceeded the Threshold value. The default value is
120seconds. Repeat offenders are blocked for increasingly longer amounts of time (1.5x for each repetition).
Attackers are unblocked at random intervals so actual block time will be longer than stated. This prevents clients from predicting the timing to optimize targeted attacks.
- Detection Time
The amount of time, in seconds, attackers are remembered by
sshguardsince their last offense before it resets their score. Default is
A list of subnets which are excluded from login protection. This lowers security but is generally acceptable from specific secure management networks.
For example, it may be necessary to add entries for network monitoring systems which probe the SSH port but do not login. Otherwise such systems may be flagged as attackers.
If pfSense is running on hardware without a monitor or if it will be running “headless” (without keyboard and video attached), then the serial console can be enabled to maintain physical control, so long as the hardware has a serial port (not USB).
If hardware is detected which has no VGA port, the serial console is forced on and cannot be disabled, and the serial options are all hidden except for the speed.
When Serial Terminal is set, the operating system enables the console on the first serial port. This console will receive kernel boot messages and a menu after the firewall has finished booting. This will not disable the onboard keyboard and video console.
To connect to the serial console, use a null modem cable connected to a serial port or adapter on another PC or serial device.
When making any changes to the serial console, the firewall must be rebooted before they take effect.
Serial Console Speed¶
The default serial console speed is 115200 bps and almost all hardware works well at that speed. In rare cases, a slower speed may be required which can be set here by picking the desired speed from the Serial Speed drop-down.
When upgrading from an older version, this may remain at an older value such as 9600 or 38400 to match the BIOS on older hardware. Increasing the speed to 115200 is almost always safe and more useful than slower speeds.
On hardware with both the serial console enabled and a VGA port available, the Primary Console selector chooses which is the preferred console, so it will receive the boot log messages from pfSense. Other OS kernel messages will show up on all console connections, and both consoles will have a usable menu.
In cases where the boot cannot complete, the preferred console must be used to resolve the problem, such as reassigning interfaces.