Networking

DHCP Options

Server Backend

Selects the DHCP backend to use for allocating DHCP and DHCPv6 addresses to clients.

Kea DHCP:

Activates the Kea DHCP backend. This is a modern and well-supported DHCP server but the implementation is still under development.

Note

The most notable missing feature is integration with the DNS Resolver to resolve DHCP hostnames in DNS.

ISC DHCP (Deprecated):

This is the legacy DHCP server which has been the default in the past. It is no longer supported by ISC and they will no longer release updates for security issues or bug fixes.

While it is deprecated, it contains functionality not yet implemented in the Kea backend, so for the time being it is still offered as a choice. It will eventually be removed from pfSense software once the Kea backend is feature complete.

Ignore Deprecation Warning:

As ISC DHCP software is deprecated and potentially insecure, the GUI displays a warning when this backend is active. Checking this box suppresses that warning message.

RADVD Debug

When checked, all log levels for RADVD will be logged to System > Routing logs. Otherwise, only log levels of LOG_ERR and higher will be logged.

DHCP6 Debug

When checked, the DHCPv6 client is started in debug mode to aid in troubleshooting.

Do not Allow PD/Address Release

By default dhcp6c sends a RELEASE message to the ISP when it exits. Some ISPs then release the allocated address and/or prefix. This option prevents dhcp6c from sending that signal.

DHCP6 DUID

This option controls the DHCPv6 Unique Identifier (DUID) used by the firewall when requesting an IPv6 address. The firewall generates a DUID automatically, but in some cases, an administrator may want to use a different DUID. For example, if the operating system was reinstalled and the firewall should use the same DUID it had in the past, or if an upstream network administrator requires a specific DUID.

Note

Most users do not need to change this to any specific value, the default behavior is fine for nearly all environments. When in doubt, leave it alone unless directed to change it by an upstream network provider.

There are several possible DUID formats that this option can accept, chosen by the drop-down menu. When a format is chosen, the GUI displays a different set of input boxes specific to the selected format. The exact format depends upon the needs of the network administrator (e.g. ISP, datacenter, etc) and they would provide the format and values.

The available DUID formats are:

Raw DUID:

DUID represented exactly as observed in a DUID file or in logs. Entered as:

Raw DUID:

A single text area in which the DUID can be entered.

This option also includes a Copy DUID button which copies the DUID from the placeholder (automatically generated by the firewall) into the text box so that the existing DUID can easily be placed into the configuration.

DUID-LLT:

DUID format with Link-Layer Address Plus Time. Entered as:

Time:

Time (in seconds) since January 1st, 2000 UTC

Link-Layer Address:

The link-layer address (MAC) of an interface on the firewall in the format xx:xx:xx:xx:xx:xx.

DUID-EN:

DUID assigned by a vendor based on Enterprise Number. Entered as:

Enterprise Number:

IANA Private Enterprise Number of the vendor.

Identifier:

Variable length identifier in the format xx:xx:xx:xx. The length depends upon the vendor.

DUID-LL:

DUID based on only Link-Layer Address. Entered as:

Link-Layer Address:

The link-layer address (MAC) of an interface on the firewall in the format xx:xx:xx:xx:xx:xx.

DUID-UUID:

DUID based on the host Universally Unique Identifier (UUID). Entered as:

DUID-UUID:

The UUID for this host in nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn format

IPv6 Options

Allow IPv6

The Allow IPv6 option controls a set of block rules which prevent IPv6 traffic from being handled by the firewall.

Note

This option does not disable IPv6 functions or prevent it from being configured, it only controls traffic flow via firewall rules.

When the option is enabled, IPv6 traffic will be allowed when permitted by firewall rules and/or automatic rules, depending on the firewall configuration. This option is enabled by default on new configurations.

When the option is unchecked, all IPv6 traffic will be blocked. This behavior is similar to how IPv6 was treated before it was supported by pfSense® software. Configurations imported from or upgraded from versions older than 2.1 will have this option unchecked, so they behave consistently after upgrade.

IPv6 over IPv4 Tunneling

The Enable IPv6 over IPv4 Tunneling option enables forwarding for IP protocol 41/RFC 2893 to an IPv4 address specified in the IPv4 address of Tunnel Peer field.

When configured, this forwards all incoming protocol 41/IPv6 traffic to a host behind this firewall instead of handling it locally.

Tip

Enabling this option does not add firewall rules to allow the protocol 41 traffic. A rule must exist on the WAN interface to allow the traffic to pass through to the local receiving host.

Prefer IPv4 over IPv6

When set, this option causes the firewall itself to prefer sending traffic to IPv4 hosts instead of IPv6 hosts when a DNS query returns results for both.

In rare cases when the firewall has partially configured, but not fully routed, IPv6 this can allow the firewall to continue reaching Internet hosts over IPv4.

Note

This option controls the behavior of the firewall itself, such as when polling for updates, package installations, downloading rules, and fetching other data. It cannot influence the behavior of clients behind the firewall.

IPv6 DNS Entry

This option controls whether or not the firewall creates local DNS entries for the firewall itself with IPv6 addresses, when available.

By default (unchecked), the firewall automatically adds DNS entries for itself using its local IPv4 and IPv6 interface addresses. In some cases, such as with dynamic IPv6 addresses like tracked interfaces, the IPv6 address may disappear or change and clients may attempt to use an outdated address until their cached DNS response expires.

When the option is checked, the firewall only adds DNS entries for its IPv4 addresses.

Network Interfaces

Hardware Checksum Offloading

When checked, this option disables hardware checksum offloading on the network cards. Checksum offloading is usually beneficial as it allows the checksum to be calculated (outgoing) or verified (incoming) in hardware at a much faster rate than it could be handled in software.

Note

When checksum offloading is enabled, a packet capture will see empty (all zero) or flag incorrect packet checksums. These are normal when checksum handling is happening in hardware.

Checksum offloading is broken in some hardware, particularly Realtek cards and virtualized/emulated cards such as those on Xen/KVM. Typical symptoms of broken checksum offloading include corrupted packets and poor throughput performance.

Tip

In virtualization cases such as Xen/KVM it may be necessary to disable checksum offloading on the host as well as the VM. If performance is still poor or has errors on these types of VMs, switch the type of NIC if possible.

Hardware TCP Segmentation Offloading

Checking this option will disable hardware TCP segmentation offloading (TSO, TSO4, TSO6). TSO causes the NIC to handle splitting up packets into MTU-sized chunks rather than handling that at the OS level. This can be faster for servers and appliances as it allows the OS to offload that task to dedicated hardware, but when acting as a firewall or router this behavior is highly undesirable as it actually increases the load as this task has already been performed elsewhere on the network, thus breaking the end-to-end principle by modifying packets that did not originate on this host.

Warning

This option is not desirable for routers and firewalls, but can benefit workstations and appliances. It is disabled by default, and should remain disabled unless the firewall is acting primarily or solely in an appliance/endpoint role.

Do not uncheck this option unless directed to do so by a support representative. This offloading is broken in some hardware drivers, and can negatively impact performance on affected network cards and roles.

Hardware Large Receive Offloading

Checking this option will disable hardware large receive offloading (LRO). LRO is similar to TSO, but for the incoming path rather than outgoing. It allows the NIC to receive a large number of smaller packets before passing them up to the operating system as a larger chunk. This can be faster for servers and appliances as it offloads what would normally be a processing-heavy task to the network card. When acting as a firewall or router this is highly undesirable as it delays the reception and forwarding of packets that are not destined for this host, and they will have to be split back up again on the outbound path, increasing the workload significantly and breaking the end-to-end principle.

Warning

This option is not desirable for routers and firewalls, but can benefit workstations and appliances. It is disabled by default, and should remain disabled unless the firewall is acting primarily or solely in an appliance/endpoint role.

Do not uncheck this option unless directed to do so by a support representative. This offloading is broken in some hardware drivers, and can negatively impact performance on affected network cards and roles.

hn ALTQ Support

Checking this option will enable support for ALTQ traffic shaping on hn(4) network interfaces in Hyper-V.

For ALTQ to work on hn(4) interfaces, the operating system must disable the multi-queue API which may reduce the system capability to handle traffic. The administrator must decide if this reduction in performance is worth the benefit of traffic shaping.

The firewall must be rebooted for this setting to take effect.

Suppress ARP messages

The firewall makes a log entry in the main system log when an IP address appears to switch to a different MAC address. This log entry notes that the device has moved addresses, and records the IP address and the old and new MAC addresses.

This event can be completely benign behavior (e.g. NIC teaming on a Microsoft server, a device being replaced) or a legitimate client problem (e.g. IP conflict), and it could show up constantly or rarely if ever. It all depends on the network environment.

The best practice is to allow these ARP messages to be printed to log since there is a chance it will report a problem worth the attention of a network administrator. However, if the network environment contains systems which generate these messages while operating normally, suppressing the errors can make the system log more useful as it will not be cluttered with unneeded log messages.

Reset All States

When set, if an interface IP address changes, the firewall will reset the entire state table instead of only clearing states for the old interface IP address.

This behavior is potentially disruptive, and is off by default. In single WAN environments, this is not typically any more disruptive than the WAN address changing, since clients already have to reestablish all connections.

In most cases, this behavior is not necessary, but it can help in certain situations where WAN addresses change rapidly and the normal behavior misses states for former IP addresses.