Miscellaneous¶

Proxy Support¶

If this firewall resides in a network which requires a proxy for outbound Internet access, enter the proxy options in this section so that requests from the firewall for items such as packages and updates will be sent through the proxy.

Proxy URL:: This option specifies the location of the proxy for making outside connections. It must be an IP address or a fully qualified domain name.
Proxy Port:: The port to use when connecting to the proxy URL. By default the port is 8080 for HTTP proxy URLs, and 443 for SSL proxy URLs. The port is determined by the proxy, and may be a different value entirely (e.g. 3128). Check with the proxy administrator to find the proper port value.
Proxy Username:: If required, this is the username that is sent for proxy authentication.
Proxy Password:: If required, this is the password associated with the username set in the previous option.

Load Balancing¶

When pfSense® software is directed to perform load balancing, successive connections will be redirected in a round-robin manner to a gateway, balancing the load across all available paths. The options in this section alter or fine-tune that behavior.

Sticky Connections:

When active, connections from the same source are sent through the same gateway, rather than being sent in a purely round-robin manner.

This “sticky” association will exist as long as states are in the table for connections from a given source address (e.g. the IP address of a user). Once the states for that source expire, so will the sticky association. Further connections from that source host will be redirected to the next available gateway in the group.

This behavior can help with protocols such as HTTPS and FTP, where the server may be strict about all connections coming from the same source. The downside of this behavior is that balancing is not as efficient, a heavy user could dominate a single WAN rather than having their connections spread out.

Source Tracking Timeout:

Controls how long the sticky association will be maintained for a host after the all of the states from that host expire. The value is specified in seconds.

By default, this value is not set, so the association is removed as soon as the states expire. If sticky connections appear to work initially but seem to stop partway through sessions, increase this value to hold an association longer. Web browsers often hold open connections for a while as users are on a site, but if there is a lot of idle time, connections may be closed and states may expire.

Power Savings¶

There are currently two different types of power configuration available, Speed Shift and SpeedStep (PowerD). Using Speed Shift is the best practice, but it is only supported on certain models of recent hardware.

Tip

The GUI displays options for Speed Shift only when the proper hardware is present. SpeedStep/PowerD settings are always available.

With either method of power management, if processes need the power, the CPU speed will be increased as needed and lowered when demand decreases. This lowers the amount of heat a CPU generates, and can also lower power consumption.

Warning

Speed Shift takes precedence over SpeedStep. If Speed Shift is enabled, SpeedStep support is disabled. Only one of the two should be enabled at a time.

Speed Shift¶

Speed Shift configures hardware-controlled performance states which enable the CPU itself to control changes in clock speed. This allows the system to respond much faster to changes in load. This method also does not rely on the BIOS passing useful values for power management since it is handled entirely at the CPU level.

Note

Speed Shift responds so fast to load that even the act of checking the current CPU frequency status raises the clock speed temporarily, making the results appear higher!

Enable Speed Shift:

This checkbox enables or disables Speed Shift support.

The current status of Speed Shift is printed below the help text for this option.

Warning

Changing this setting requires a reboot.

Control Level:

Chooses between per-core or per-package frequency control. Core-level control is the best practice in most cases, especially for hardware with only a single physical CPU.

The active control level is printed below the help text for this option.

Core Level Control:: Each CPU core can run at a different frequency.
Package Level Control:: All cores on the same physical CPU package are locked to the same speed, but each package may run at a different speed.

Warning

Changing this setting requires a reboot.

Power Preference:

This option slider influences the bias of the hardware performance state toward performance (left, lower values) or energy efficiency (right, higher values).

A numerical representation of the preference level (from 0-100) is printed below the slider.

The default value is 80 to help keep heat and power usage down. For increased responsiveness to performance demands, move the slider farther to the left as needed.

PowerD¶

PowerD manages CPU frequency changes via SpeedStep. This daemon monitors the system and it lowers and raises the CPU frequency based on activity levels.

Note

The behavior of this option depends greatly on the hardware in use. In some cases, the CPU frequency may lower but have no measurable effect on power consumption and/or heat, where others will cool down and use considerably less power. It is considered safe to run, but is left off by default unless supported hardware is detected.

Enable PowerD:

Checking this option enables the powerd daemon.

Modes:

The mode for powerd may also be selected for three system states:

AC Power:: Normal operation connected to AC power.
Battery Power:: Mode to use when the firewall is running on battery. Support for battery power detection varies by hardware.
Unknown Power:: Mode used when powerd cannot determine the power source.

Four modes choices exist for each of these states:

Maximum:: Keeps the performance as high as possible at all times.
Minimum:: Keeps performance at its lowest, to reduce power consumption.
Adaptive:: Tries to balance savings by decreasing performance when the system is idle and increasing when busy.
Hiadaptive:: Similar to adaptive but tuned to keep performance high at the cost of increased power consumption. It raises the CPU frequency faster and drops it slower. This is the default mode.

Note

Some hardware requires powerd running to operate at its maximum attainable CPU frequency. If the firewall device does not have powerd enabled but always runs at what appears to be a low CPU frequency, enable powerd and set it to Maximum for at least the AC Power state.

Watchdog¶

Certain firewall hardware includes a Watchdog feature which can reset the hardware when the watchdog daemon can no longer interface with the hardware after a specified timeout. This can increase reliability by resetting a unit when a hard lock is encountered that might otherwise require manual intervention.

The downside to any hardware watchdog is that any sufficiently busy system may be indistinguishable from one that has suffered a hard lock.

Enable Watchdog:: When checked, the watchdogd daemon is run which attempts to latch onto a supported hardware watchdog device.
Watchdog Timeout:: The time, in seconds, after which the device will be reset if it fails to respond to a watchdog request. If a firewall regularly has a high load and triggers the watchdog accidentally, increase the timeout.

Cryptographic & Thermal Hardware¶

On systems with configurable cryptographic and/or thermal hardware, this section provides options to control the hardware. On systems without configurable cryptographic modules, this section only displays options for thermal hardware.

IPsec-MB¶

The checkbox for IPsec-MB enables IPsec Multi-Buffer (IPsec-MB, IIMB) Cryptographic Acceleration.

IPsec-MB assists VPN performance by replacing the cryptographic functions provided by the kernel for AES-CBC, AES-GCM, and ChaCha20-Poly1305 with accelerated functions that utilize the optimal CPU SIMD instruction set.

This benefits any VPN utilizing the accelerated algorithms in the kernel which includes IPsec, OpenVPN DCO, and WireGuard.

IPsec-MB is faster than AES-NI and can even meet or exceed the performance of dedicated acceleration hardware such as QAT on current versions of pfSense software.

Note

If IPsec-MB and QAT are both enabled, IPsec-MB will take over handling of AES-GCM acceleration. Depending on the hardware, QAT may accelerate AES-GCM faster than IPsec-MB, but IPsec-MB can accelerate ChaCha20-Poly1305 which is not supported by QAT. Depending on the required performance of each algorithm it may be better to only enable QAT, or to enable both, but it depends on the environment and workload.

Cryptographic Hardware¶

There are a few options available for accelerating cryptographic operations via hardware. Some are built into the kernel, and others are loadable modules.

Note

Some modules and hardware are only supported by pfSense® Plus software.

Thermal Sensors¶

The firewall can read temperature data from a few sources to display on the dashboard. If the firewall has a supported CPU, selecting a thermal sensor will load the appropriate driver to read its temperature.

Note

Temperature data can be displayed by the Thermal Sensors dashboard widget or via sysctl.

The following sensor types are supported:

None/ACPI:: The firewall will attempt to read the temperature from an ACPI-compliant motherboard sensor if one is present, otherwise no sensor readings are available.
Intel Core:: Loads the coretemp module which supports reading thermal data from Intel core-series CPUs and other modern Intel CPUs using their on-die sensors, including Atom-based processors.
AMD K8, K10, and K11:: Loads the amdtemp module which supports reading thermal data from modern AMD CPUs using their on-die sensors.

If the firewall does not have a supported thermal sensor chip, this option will have no effect. To unload the selected module, set this option to None/ACPI and then reboot.

Note

The coretemp and amdtemp modules report thermal data directly from the CPU core. This may or may not be indicative of the temperature elsewhere in the system. Case temperatures can vary greatly from temperatures on the CPU die.

Kernel Page Table Isolation (PTI)¶

Kernel PTI is a method for working around CPU vulnerabilities such as Meltdown. By exploiting that vulnerability without Kernel PTI, kernel memory could be accessed by unprivileged users on affected CPUs.

Note

While more secure, this protection can incur a performance penalty. If untrusted users do not have access to run arbitrary code on the firewall, it can be disabled without significant security risk.

Kernel PTI is active by default only on CPUs affected by the vulnerability.

This option forces the workaround off, and requires a reboot to change.

If a vulnerable CPU is not detected, PTI is disabled by default and this option will have no effect.

The current state of Kernel PTI is printed below the option.

Microarchitectural Data Sampling (MDS) Mitigation¶

Microarchitectural Data Sampling (MDS) mitigation is a method for working around weaknesses in Intel CPUs which support hyperthreading. By exploiting MDS without mitigation in place, kernel memory could be accessed by unprivileged users on affected CPUs.

Note

While more secure, this protection can incur a performance penalty. If untrusted users do not have access to run arbitrary code on the firewall, it can be disabled without significant security risk.

This option controls which method of MDS mitigation is used, if any. Changing the option requires a reboot to activate. The following modes are available:

Default:: The default operating system behavior. As of this writing, the default behavior is to disable MDS mitigation.
Mitigation Disabled:: Forcefully disable MDS mitigation.
VERW instruction (microcode) mitigation enabled:: Use VERW instruction mitigation, implemented in CPU microcode, to mitigate MDS. This is the fastest and most optimal way to mitigate MDS, but it requires support in the CPU microcode for this instruction.
Software sequence mitigation enabled:: Mitigates MDS by using software sequences, which is much slower, but safer.
Automatic VERW or Software selection:: When set to Automatic, the operating system will attempt to use VERW instructions if they are available and software in all other cases.

The current state of MDS mitigation is printed below the option.

Schedules¶

The Do not kill connections when schedule expires option controls whether or not states are cleared when a scheduled rule transitions into a state that would block traffic. If unchecked, connections are terminated when the schedule time has expired. If checked, connections are left alone and will not be automatically closed by the firewall.

Gateway Monitoring¶

State Killing on Gateway Recovery¶

States from the firewall itself¶

Connections from the firewall itself can fail over to other gateways by setting a failover gateway group as the system’s default gateway. By killing states on lower-priority gateways after a higher-priority gateway recovers, these connections can re-establish on the preferred gateway. This option overrides the failover gateway group’s state-killing behavior by affecting all states, not only those created by policy routing rules.

Don’t kill states from the firewall itself (default):: States from the firewall itself are unaffected. The configured failover gateway group determines the state-killing behavior for states created by policy routing rules.
Kill all states for lower-priority gateways:: All states on lower-priority gateways are killed when a higher-priority gateway returns to an online state.
Only kill states with the same Address Family as the gateway group:: States of the same Address Family as the gateway group are killed for lower-priority gateways.

States from policy routing rules¶

The state-killing behavior on gateway recovery handles policy routing states separately. This allows for applying different behaviors to different types of traffic. For example, one gateway group can handle general internet traffic by killing states on both gateway failure and recovery. Separately, another group handling VOIP traffic would only kill states on gateway failure to avoid interrupting active calls.

Don’t kill policy routing states for lower-priority gateways:: Controls the default state-killing behavior for states created by policy routing rules using a failover gateway group. This behavior may also be controlled per gateway group. If unchecked (default), policy routing states on lower-priority gateways are killed when a higher-priority gateway recovers.

State Killing on Gateway Failure¶

When using Multi-WAN, clearing states on failed WANs can help redirect traffic for long-lived connections such as VoIP phone/trunk registrations to another WAN. However, clearing states can also disrupt ongoing connections if a lesser-used gateway is unstable or there is a gateway which is down long term but is not disabled, which would still states when it fails or is down during a filter reload.

There are several choices for this behavior, including:

Do not kill states on gateway failure (Default):

The monitoring process will not flush states when a gateway is in a down state during a filter reload. This is the default behavior and is the least disruptive, though clients may have to wait for connections to timeout after a WAN failure.

Kill states for all gateways which are down:

Selectively kill states using gateways that fail or are down during a filter reload, so long as those states were created by policy routing rules.

This function can only kill states which contain gateway information populated by policy routing rules (e.g. gateways or gateway groups on firewall rules, or even reply-to.). It cannot kill states created by default gateway switching as in that case the gateway in the state is 0.0.0.0/:: and not a specific gateway.

Flush all states on gateway failure:

Clears all states for existing connections when any gateway fails or is in a down state during a filter reload.

Warning

When this is triggered the firewall clears the entire state table if any gateway is down, which can be highly disruptive.

More information on how this impacts Multi-WAN can be found in State Killing/Forced Switch.

Skip Rules When Gateway is Down¶

By default, when a rule has a specific gateway set and this gateway is down, the gateway is omitted from the rule and traffic is sent via the default gateway.

The Do not create rules when gateway is down option overrides that behavior and the entire rule is omitted from the ruleset when the gateway is down. Instead of flowing via the default gateway, the traffic will match a different rule instead. This is useful if traffic must only ever use one specific WAN and never flow over any other WAN.

Tip

When utilizing this option, create a reject or block rule underneath the policy routing rule with the same matching criteria. This will prevent the traffic from potentially matching other rules below it in the ruleset and taking an unintended path.

Static Routes¶

By default the firewall adds static routes for gateway monitor IP addresses to ensure traffic to the monitor IP address leaves via the correct interface. Enabling this checkbox overrides that behavior. When this option is set, the user will have to ensure the traffic exits the correct interface in some other way.

RAM Disk Settings¶

The /tmp and /var directories are used for writing files and holding data that is temporary and/or volatile. Using a RAM disk can reduce the amount of writing that happens on disks in the firewall. Modern SSDs do not have disk write concerns as older drives once did, but it can still be a concern when running from lower quality flash storage such as USB thumb drives.

This behavior has the benefit of keeping most of the writes off of the disk in the base system, but packages may yet write frequently to the drive. It also requires additional handling to ensure data such as RRD graphs and DHCP leases are retained across reboots. Data for both is saved during a proper shutdown or reboot, and also periodically if configured.

Use RAM Disks:

When checked, a memory disk is created at boot time for /tmp and /var/ and the associated structure is initialized. When this setting is toggled, a reboot is required and forced on save.

Warning

The size of RAM disks is limited by the amount of available kernel memory. The actual limit is calculated and printed in the GUI underneath the size options.

/tmp RAM Disk Size:

The size of the /tmp RAM disk, in MiB. The default value is 40, but should be set higher if there is available RAM and kernel memory.

/var RAM Disk Size:

The size of the /var RAM disk, in MiB. The default value is 60, but should be set much higher, especially if packages will be used. 512-1024 is a better starting point, depending on the available firewall RAM and kernel memory.

Periodic RAM Disk Data Backups:

These options control how frequently data in RAM disks is backed up. If the firewall is rebooted unexpectedly, the last backup is restored when the firewall boots. The lower the value, the less data that will be lost in such an event, but more frequent backups write more to the disk.

RRD Data:: The time, in hours, between periodic backups of RRD files containing graph data.
DHCP Leases:: The time, in hours, between periodic backups of the DHCP lease databases.
Log Directory:: The time, in hours, between periodic backups of the system log directory.

Warning

Aside from the points mentioned above, there are several items to be cautious about when choosing whether or not to use the RAM disk option. Used improperly, this option can lead to data loss or other unexpected failures.

Utilize remote syslog to send the logs to another device on the network rather than risking losing data from unexpected outages.

Packages may not properly account for the use of RAM disks, and may not function properly at boot time or in other ways. Test each package, including whether or not it works immediately after a reboot.

These are RAM disks, so the amount of RAM available to other programs will be reduced by the amount of space used by the RAM disks. For example if the firewall has 2GB of RAM, and has 512MB for /var and 512MB for /tmp, then only 1GB of RAM will be available to the OS for general use.

Special care must be taken when choosing a RAM disk size, which is discussed in the following section.

RAM Disk Sizes¶

Setting a size too small for /tmp and /var can backfire, especially when it comes to packages. The suggested sizes on the page are an absolute minimum and often much larger sizes are required. The most common failure is that when a package is installed, and parts of the package touch places in both /tmp and /var and it can ultimately fill up the RAM disk and cause other data to be lost.

For /tmp, a minimum of 40 MiB is required. For /var a minimum of 60 MiB is required. To determine the proper size, check the current usage of the /tmp and /var directories before making a switch. Check the usage several times over the course of a few days so it is not caught at a low point. Watching the usage during a package installation adds another useful data point.

Hard Disk Standby¶

The Hard disk standby time option activates power management for disk drives in the firewall. The drop-down field sets the number of minutes that the disk can be idle before going into standby mode.

Using standby mode is not necessary for SSD or flash media. For traditional spinning platter hard disks, it may result in power savings and can potentially lengthen the disk lifetime by saving wear, at a cost of slower disk access when resuming from an idle state. Actual results entirely depend on the hardware involved.

The default behavior is Always On which prevents the disk from entering standby mode.

Installation Feedback¶

When this option is set, the firewall will not send its Netgate Device ID when making requests to Netgate servers.