What are Virtual IP Addresses

(Redirected from What are Virtual IP Addresses?)

Virtual IPs add knowledge of additional IP addresses to the firewall that are different from
the firewall's actual "real" interface addresses. Most often, these are used for NAT, but they
can also be used for other functions such as clustering, binding services such as DNS, load
balancing in packages, and so on.
Below is a table representing the major features of each type of VIP. More detailed
explanations are located in the section after the table.

Contents
[hide]

1VIP Features Table

2Virtual IP Feature Details
o 2.1CARP
o 2.2Proxy ARP
o 2.3Other
o 2.4IP Alias
3Implications

VIP Features Table

VIP Features

In Subne
VIP Versio NA Bindin ARP/L Clusterin ICM Single/Rang
Subne t
Type n T g 2 g P e
t Mask

CAR 2.2+
1.x+ Yes Yes Yes Yes Yes Yes Single
P (3)

Proxy No
1.x+ Yes No Yes No No n/a Either
ARP (1)

No
Other 1.x+ Yes No No Yes (2) No n/a Either
(1)

IP See
2.0+ Yes Yes Yes See Notes No Yes Single
Alias Notes

1: ICMP Column represents responses from the firewall itself without NAT. With 1:1
NAT, any VIP will pass ICMP through to the target device. On 2.1+ ICMP can also
be used as a protocol in port forward entries.
2: "Other" type VIPs are for routed subnets, and CARP is irrelevant, so they work
(See below)
3: CARP type VIPs must be in the same subnet as other interface VIPs on pfSense
<=2.1.x, on >= 2.2 they may be in other subnets, but see below for caveats.

Virtual IP Feature Details

It's difficult to express the actual capabilities in a table format, so here is a
more thorough overview of the various types and what they can/cannot do.
CARP

Can be used for NAT.

Can be used by the firewall itself to bind/run services.
Generates ARP (Layer 2) traffic for the VIP.
Can be used for clustering (master firewall and standby failover firewall.)
Must be in the same subnet as an IP address on the interface (real
interface IP or IP alias.) on pfSense 2.1.x and previous versions.
CARP VIPs may be in other subnets on pfSense 2.2-RELEASE and
later, but we still recommend using the old method where possible for
better connectivity and less potential issues.
Will respond to ICMP ping if allowed by firewall rules.
Must be added individually.
Subnet mask must match the interface IP.
Generates its own MAC address for the VIP. This MAC is different than its
physical parent interface.
Proxy ARP

Can be used for NAT.

Cannot be used by the firewall itself to bind/run services.
Generates ARP (Layer 2) traffic for the VIP.
Can be in a different subnet than the real interface IP.
Will not respond to ICMP ping.
Can be added individually or as a subnet to make a group of VIPs.
Other

Can be used for NAT.

Cannot be used by the firewall itself to bind/run services.
Can be used if routed to the firewall without needing ARP/Layer 2
messages. (e.g. Upstream provider routes a subnet to the WAN IP)
Can be in a different subnet than the real interface IP.
Will not respond to ICMP PING.
Can be added individually or as a subnet to make a group of VIPs. (As of
2.1)
Can be used with CARP, e.g. subnet routed to external CARP VIP.
IP Alias

Available in version 2.0 and later.

Can be used for NAT.
Can be used by the firewall itself to bind/run services.
Adds extra IP addresses to an interface.
Generates ARP (Layer 2) traffic for the VIP.
Can be in a different subnet than the real interface IP when used directly
on an interface.
Will respond to ICMP ping if allowed by firewall rules.
 Must be added individually
Subnet mask should match the interface IP, or be /32. Matching the
interface subnet is advised. For IPs in different subnets at least one IP
alias VIP must have the correct mask for the new subnet.
Can be stacked on top of a CARP VIP to bypass VHID limits and lower the
amount of CARP heartbeat traffic.
Stacked IP Alias VIPs will synchronize via XMLRPC.
Stacked IP Alias VIPs must be inside the same subnet as the CARP
VIP upon which they are placed.
Can be used with CARP to add additional subnets to CARP, e.g. Add one
unique IP Alias from the new subnet to each node, then add CARP VIPs.
Must be added to each node individually as these will not synchronize via
XMLRPC or else an IP conflict would occur.
Can be bound to localhost on version 2.1 or later for binding services in
routed subnets. IP Alias VIPs bound to localhost will synchronize via
XMLRPC

Implications
Some upstream equipment requires each distinct IP address to have a unique
MAC address. In such cases, the use of CARP VIP types may allow the
additional addresses to function where they otherwise would not work with IP
alias or Proxy ARP VIPs. This has been common to see in the past with AT&T
Uverse equipment.
The MAC address of a VIP will change if the VIP entry is changed between a
type that has a unique MAC address, such as CARP, to one that shares a
MAC address with a parent interface, such as IP alias or Proxy ARP. Due to
the MAC address change, other equipment on the segment may need to have
its ARP cache cleared, it may need to be rebooted (cable modems especially),
or there may be some other time period that must expire for the ARP cache to
update. This may be as few as a couple minutes or up to four hours.
If a particular configuration does not work with IP alias or Proxy ARP type
VIPs, try with a CARP VIP instead, or vice versa. Address or wait out the
potential ARP concerns before declaring one particular type a failure, and
always be on the lookout for IP conflicts.