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.
This option specifies the location of the proxy for making outside connections. It must be an IP address or a fully qualified domain name.
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.
Check with the proxy administrator to find the proper port value.
If required, this is the username that is sent for proxy authentication.
If required, this is the password associated with the username set in the previous option.
When pfSense® is directed to perform load balancing, successive connections will be redirected in a round-robin manner to a web server or gateway, balancing the load across all available servers or paths. When Sticky Connections is active this behavior is changed so that connections from the same source are sent to the same web server or through the same gateway, rather than being sent in a purely round-robin manner.
Sticky Connections affects both outbound load balancing (Multi-WAN) as well as server load balancing when enabled. This “sticky” association will exist as long as states are in the table for connections from a given source address. Once the states for that source expire, so will the sticky association. Further connections from that source host will be redirected to the next web server in the pool or the next available gateway in the group.
For outgoing traffic using a load balancing gateway group, the sticky association is between the user and a gateway. As long as the local address has states in the state table, all of its connections will flow out of a single gateway. This can help with protocols such as HTTPS and FTP, where the server may be strict about all connections coming from the same source, or where an additional inbound connection must be received 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.
For server load balancing, described further in Server Load Balancing, sticky connections are desirable for applications which rely on the same server IP addresses being maintained throughout a given session for a user. Web applications on servers may not be intelligent enough to allow a user session to exist on multiple backend servers at the same time, so this allows a user to always reach the same server so long as they are browsing a site. This behavior may not be required depending on the content of the server.
For more control over how user connections are associated with servers
in a load balancing scenario, consider using the HAProxy package instead of
relayd load balancer. HAProxy supports several methods of
ensuring users are properly directed to a backend server.
The Source Tracking Timeout for sticky connections 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.
Default Gateway Switching¶
Enable Default Gateway Switching allows additional non-default gateways to take over if the default gateway becomes unreachable. This behavior is disabled by default. With multiple WANs, switching the default gateway automatically will ensure that the firewall always has a default gateway so that traffic from the firewall itself can get out to the Internet for DNS, updates, packages, and add-on services such as squid.
When using the DNS Resolver in the default non-forwarding mode, default gateway switching is required for Multi-WAN to function properly. If default gateway switching cannot be used, then consider using forwarding mode instead.
There are cases where switching the default gateway is not desirable, however, such as when the firewall has additional gateways that are not connected to the Internet. In the future this option will be expanded so it can be controlled on a per-gateway basis.
This option is known to not work properly with a PPP-type WAN (PPPoE, L2TP, etc) as a default gateway.
When Enable PowerD is checked, the
powerd daemon is started. This daemon
monitors the system and can lower or raise the CPU frequency based on system
activity. If processes need the power, the CPU speed will be increased as
needed. This option will lower the amount of heat a CPU generates, and may also
lower power consumption.
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 less power considerably. It is considered safe to run, but is left off by default unless supported hardware is detected.
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
powerdcannot determine the power source.
Four modes choices exist for each of these states:
Keeps the performance as high as possible at all times.
Keeps performance at its lowest, to reduce power consumption.
Tries to balance savings by decreasing performance when the system is idle and increasing when busy.
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.
Some hardware requires
powerd running to operate at its maximum
attainable CPU frequency. If the firewall device does not have
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.
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
watchdogddaemon 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¶
There are a few options available for accelerating cryptographic operations via hardware. Some are built into the kernel, and others are loadable modules. One optional module is selectable here: AES-NI (Advanced Encryption Standard, New Instructions). If AES-NI CPU-based Acceleration (aesni) is chosen, then its kernel module will be loaded when saved, and at bootup. The aesni module will accelerate operations for AES-GCM, available in IPsec.
Support for AES-NI is built into many recent Intel and some AMD CPUs. Check with the OEM for specific CPU or SoC support.
Speeds with AES-NI vary by support of the underlying software. Some OpenSSL-based software like OpenVPN can perform differently with AES-NI unloaded since OpenSSL has built-in support for AES-NI. IPsec support will be greatly increased with AES-NI loaded provided that AES-GCM is used and properly configured.
These drivers hook into the
crypto(9) framework in FreeBSD, so many aspects
of the system will automatically use acceleration for supported ciphers.
There are other supported cryptographic devices, such as hifn(4) and ubsec(4). In most cases, if a supported accelerator chip is detected, it will be shown in the System Information widget on the dashboard.
pfSense 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.
The following sensor types are supported:
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
coretempmodule 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
amdtempmodule 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.
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.
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.
Clear States When a Gateway is Down¶
When using Multi-WAN, by default the monitoring process will not flush states when a gateway goes into a down state. Flushing states for each gateway event can be disruptive in situations where a gateway is unstable.
The Flush all states when a gateway goes down option overrides the default behavior, clearing states for all existing connections when any gateway fails. Clearing states can help redirect traffic for long-lived connections such as VoIP phone/trunk registrations to another WAN, but it can also disrupt ongoing connections if a lesser-used gateway is flapping which would still kill all states when it fails.
More information on how this impacts Multi-WAN can be found in State Killing/Forced Switch.
When this is triggered, the entire state table is cleared. This is necessary because it is not possible to kill all states for the failing WAN and the LAN-side states associated with the failing WAN. Removing states on the WAN side alone is ineffective, the LAN-side states must be cleared as well.
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.
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.
RAM Disk Settings¶
/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 the firewall’s disks. 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 hard 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
/var/and the associated structure is initialized. When this setting is toggled, a reboot is required and forced on save.
- /tmp RAM Disk Size
The size of the
/tmpRAM disk, in MiB. The default value is
40, but should be set higher if there is available RAM.
- /var RAM Disk Size
The size of the
/varRAM 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.
- Periodic RRD Backup
The time, in hours, between periodic backups of RRD files. If the firewall is rebooted unexpectedly, the last backup is restored when the firewall boots back up. The lower the value, the less data that will be lost in such an event, but more frequent backups write more to the disk.
- Periodic DHCP Leases Backup
The time, in hours, between periodic backups of the DHCP lease databases. If the firewall is rebooted unexpectedly, the last backup is restored when the firewall boots back up. The lower the value, the less data that will be lost in such an event, but more frequent backups write more to the disk.
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.
The system logs are held in
/var but they are not backed up like the
RRD and DHCP databases. The logs will reset fresh on each reboot. For
persistent logs, utilize remote syslog to send the logs to another device on
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
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
/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
/var and it can ultimately fill up the RAM disk and cause other
data to be lost. Another common failure is setting
/var as a RAM disk and
then forgetting to move a squid cache to a location outside of
/var - if
left unchecked, it will fill up the RAM disk.
/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
/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.