Virtual IP Addresses¶

Some types of interfaces on pfSense® software can utilize more than one IP address at a time. The primary IP address for an interface comes from the interface settings, while Virtual IP (VIP) addresses facilitate the use of additional IP addresses in conjunction with NAT or local services.

VIP Types¶

There are four types of Virtual IP addresses available in pfSense: IP Alias, CARP, Proxy ARP, and Other. Each is useful in different situations. In most circumstances, pfSense software will need to answer ARP request for a VIP which means that IP Alias, Proxy ARP or CARP must be used. In situations where ARP is not required, such as when additional public IP addresses are routed by a service provider to the WAN IP address on the firewall, Other type VIPs can make it easier to use those addresses in NAT rules.

pfSense software will not respond to ICMP echo requests (pings) destined to Proxy ARP and Other type VIPs regardless of firewall rule configuration. With Proxy ARP and Other VIPs, NAT must be present on the firewall, forwarding traffic to an internal host for ping to function. See Network Address Translation for more information.

IP Alias¶

IP Aliases work like any other IP address on an interface, such as the actual interface IP address. They will respond to layer 2 (ARP) and can used as binding addresses by services on the firewall. They can also be used to handle multiple subnets on the same interface. pfSense software will respond to ping on an IP Alias, and services on the firewall that bind to all interfaces will also respond on IP Alias VIPs unless the VIP is used to forward those ports in to another device (e.g. 1:1 NAT).

IP Alias VIPs can use Localhost as their interface to bind services using IP addresses from a block of routed addresses without specifically assigning the IP addresses to an interface. This is primarily useful in HA with CARP scenarios so that IP addresses do not need to be consumed by a CARP setup (one IP each per node, then the rest as CARP VIPs) when the subnet exists only inside the firewall (e.g. NAT or firewall services such as VPNs).

IP Aliases on their own do not synchronize to XMLRPC Configuration Synchronization peers because that would result in an IP address conflict. One exception to this is IP Alias VIPs using a CARP VIP “interface” for their interface. Those do not result in a conflict so they will synchronize. Another exception is IP Alias VIPs bound to Localhost as their interface. Because these are not active outside of the firewall itself, there is no chance of a conflict so they will also synchronize.

CARP¶

CARP VIPs are primarily used with High Availability redundant deployments utilizing CARP (CARP Overview). CARP VIPs each have their own unique MAC address derived from their VHID, which can be useful even outside of a High Availability deployment.

Proxy ARP¶

Proxy ARP VIPs function strictly at layer 2, providing ARP replies for the specified IP address or CIDR range of IP addresses. This allows pfSense software to accept traffic targeted at those addresses inside a shared subnet. For example, pfSense software can forward traffic sent to an additional address inside its WAN subnet according to its NAT configuration. The address or range of addresses are not assigned to any interface on pfSense, because they don’t need to be. This means no services on pfSense software itself can respond on these IP addresses.

Proxy ARP VIPs do not sync to XML-RPC Configuration Sync peers because doing so would cause an IP address conflict.

Other¶

Other type VIPs define additional IP addresses for use when ARP replies for the IP address are not required. The only function of adding an Other type VIP is making that address available in the NAT configuration drop-down selectors. This is convenient when the firewall has a public IP block routed to its WAN IP address, IP Alias, or a CARP VIP.

VIP Configuration Options¶

The options available for each VIP vary based on the selected type. This list contains all available options for all types, with the restrictions noted as needed.

Type

Sets the type of VIP this will be, and changes the available options on the page. See VIP Types for a description of each type.

Interface

The parent interface upon which this VIP will reside.

For IP Alias type VIPs, this can also be a CARP VIP (Using IP Aliases to Reduce Heartbeat Traffic).

Address Type

For Proxy ARP and Other type VIPs this option declares whether the VIP defines a single IP address or an entire subnet.

Addresses

The IP address and subnet mask for this VIP.

Expansion

For IPv4 Proxy ARP and Other type VIPs, this specifies whether or not a subnet address type VIP will be expanded into its individual IP address components in drop-down menus where VIPs can be selected, such as on NAT rules.

Warning

For large subnets this can cause rendering issues in browsers as they may not properly handle large drop-down lists.

CARP Options

These options are only available for CARP type VIPs:

Virtual IP Password

The secret key with which to protect the CARP heartbeat traffic. If peers do not agree on the key, they cannot coordinate their actions and will all appear as MASTER status.

VHID Group

The group identifier used to indicate between multiple hosts that they are coordinating control of the same address. VHIDs must be unique per layer 2.

For IPv4, this is commonly set to match the last octet of the IPv4 VIP address.

The VHID also influences the resulting MAC address of the VIP, where the last two characters of the MAC are the VHID in hexadecimal.

Advertising Frequency

Controls how often the master node sends out CARP heartbeat advertisements. Hosts transmitting faster than their peers assume control of the VIP.

Base

The base value of whole seconds between advertisements. The default of 1 is typically ideal, but can be raised in special cases.

Skew

1/256th fractions of a second added to the base. Typically the preferred primary node will have a skew of 1 or 0, and secondary nodes will be around 100 or higher.

When XMLRPC is configured to synchronize VIPs, this value is automatically adjusted for the secondary node by adding 100 to this value.

CARP Mode (Plus Only)

pfSense Plus software has an option to choose how CARP operates, either in multicast or unicast mode.

Multicast: CARP heartbeats are advertised to the entire Layer 2 using multicast, and multiple peers can monitor for heartbeats and participate. This requires that all peers be connected to networks that support multicast (e.g. Ethernet switches or equivalent). It also requires that the underlying network does not manipulate or limit multicast.
Unicast: CARP heartbeats are sent directly to the specified Peer Address and do not use multicast. This allows CARP to operate on networks which do not support multicast, such as cloud provider networks and VPNs. However, this limits a cluster to two nodes since both nodes must send heartbeats to each other directly.

Warning

The best practice is to avoid using unicast mode on traditional switched L2 infrastructure when possible. In unicast mode, CARP heartbeats are sourced from the interface MAC address and not the CARP MAC. Since switches do not see packets sourced from the CARP MAC, they may flood packets for unicast CARP VIPs to all ports. This behavior has significant security and performance concerns which are eliminated by using multicast mode instead.
Peer Address: The IP address of the peer node to which the firewall will send its unicast CARP heartbeats for this VIP.

Warning

At this time the Peer Address cannot be an IPv6 link local address. This will be corrected in a future release. See Redmine #14385 for details.

Note

When VIPs are synchronized via XMLRPC, the primary node will adjust the VIP such that its own address on the parent interface is configured on the peer VIP. In scenarios where this is not correct, VIP synchronization may need to be managed manually.

Feature Comparison¶

Virtual IP Address Feature Comparison