Documente Academic
Documente Profesional
Documente Cultură
Tech Note
PAN-OS 4.0
Hardware requirements
Two identically configured Palo Alto Networks next-generation firewalls per cluster.
Software requirements
PAN-OS 4.0 and later.
Feature description
A PAN-OS HA cluster consists of two identical Palo Alto Networks next-generation firewalls with identical
software that enforce the same overall security policy and share the same configuration settings. With Active-Active
deployment, both the devices are active and processing traffic. Active-Active HA is supported only in the virtual-
wire and Layer 3 modes. Such deployments are most suited for scenarios involving asymmetric routing. In addition
to the HA1 and HA2 links used in active-passive, active-active deployments require a dedicated HA3 link. This link
is used as packet forwarding link for session setup and asymmetric traffic handling.
Session Ownership
Within an activeactive cluster, the session owner device can be either the firewall that receives the first packet of a
new session or the device in an active-primary state. This device is responsible for all layer 7 processing, i.e. app-id,
content-id, and threat scanning for this session. This device is also responsible for generating all traffic logs for the
session.
Session Setup
The session setup device is responsible for the layer2 through layer4 processing required for setting up a new session.
Address translation is performed by the session setup device. The session setup device is determined by configuring
the session setup load sharing options. The separation of session owner and session setup devices is necessary to
avoid race conditions that can occur in asymmetrically routed environments
Note:
All packet forwarding between the two devices uses a dedicated link, also known as the HA3 link
When the session owner fails, the peer device will become the session owner. The existing sessions will fail
over to the functional device and no layer 7 processing will be available for these sessions.
When a device recovers from a failure, all sessions that were owned by the device before failure will revert
back to the original device
Asymmetric Flow
Note: Implementing A/A HA in vwire mode in a layer2 sandwich will result in switching loops if
Spanning Tree Protocol is not enabled on the switches. It is recommended to deploy A/A in vwire in a
layer3 topology.
Floating IP
This deployment option allows for the creation of floating IP addresses that can move between the HA devices when
a link failure or device failure occurs. The interface on the device in the cluster that owns the floating IP address
responds to ARP requests with a virtual MAC address. Floating IP addresses are recommended when VRRP- like
functionality is required. Floating IP addresses can is also used to implement VPNs and source Network Address
Translation (NAT) configurations, allowing for persistent connections when a failure occurs on the device offering
those services. As shown in the figure below, each interface on the firewall has its own IP address and a floating IP
address configured. Please note, the interface IP address remains local to the device but the floating IP address can
move between the devices upon device failure. The end hosts are configured to use the floating IP address as the
default gateway, allowing the traffic to be load balanced within the cluster. External load balancers can also be used
to load balance traffic between with firewalls within the cluster.
In the event of a link or device failure the floating IP and VMAC moves over to the functional device. A Gratuitous
ARP is sent out the by the functional device to update the MAC table of the connected switches. Once the device
recovers from the failure, the floating IP and VMAC will move back to the original device.
ARP load-sharing should be used only when a Layer 2 separation exists between the firewall and end hosts. In the
event of a link or device failure, the floating IP and VMAC moves over to the functional device. Gratuitous ARP is
sent out the by the functional device to update the MAC table of the connected switches.
yy: interface ID
When a new active device takes over, Gratuitous ARPs are sent from each of the connected interfaces of the
functional device to inform the connected Layer-2 switches of the new location of the virtual MAC addresses.
Device>high availability>setup
ID: This is the HA group ID. Both devices must have the same group ID. HA group-ID is used to calculate virtual
MAC.
Mode: Choose active-active from the drop down list
Device-id: Select unique device from the drop down list. The device-id can be either 0 or 1. The device-ID remains
local to the device and does not transition between devices during failover. This field is also used to calculate virtual
MAC address.
Peer HA IP Address: IP address of the HA-1 control link on the peer device
Backup Peer HA IP Address: IP address of the backup control link on the peer device. This field is optional
Enable Config Sync: This feature is enabled by default. This is required to synchronize configuration between the
devices in cluster
Device Priority: Enter numeric value for the device priority. Upon initial configuration the device with the lowest
priority (value closest to zero) becomes the active unit (default priority is 100). If two devices have the same priority
value, the device with device-id 0 becomes the active-primary unit.
Heartbeat backup: Select this to use the management ports on the firewall to provide a backup path for heartbeat
and hello messages
Preemptive: Select the check box to enable the higher priority firewall (priority numeric value closest to zero) to
resume active-primary operation after recovering from a failure. If this setting is off, then the lower priority firewall
remains active-primary even after the higher priority firewall recovers from a failure. This option must be enabled to
on both the devices for preemptive to work.
Preemption-hold-time: The time in minutes a device remains in the passive state before taking over as the active
device (default 1 min). If the two devices are configured with different preemption hold-down timeouts, then the
preemption hold-down timeout configured on the higher priority (lower value) device is used. The preemption hold-
down timeout on the lower priority device is ignored
Promotion hold time: The time a device stays in the active-secondary state before changing state to active-primary,
In the event the active-primary device has transitioned to a non-functional or tentative state because of a failure, the
active-secondary device will immediately transition to an active-primary state regardless of the value defined as the
promotion hold time.
Hello-interval: It is the time interval in milliseconds to send Hello messages to track the status of the HA agent.
Hellos are sent over the HA1 link. The default value of the hello interval is platform dependent. The PA-500 and
PA-2000 Series uses 8000ms and PA-4000 Series and the PA-5000 series use 1000ms.
Heartbeat-interval: The time interval in milliseconds to send ICMP ping to the HA peer over the control link. The
peer kernel directly responds to the pings. The default value of the heartbeat interval for all platforms is 1000ms
Maximum number of flaps: A flap is counted as the device changes state from active to non-functional. If the device
changes from active to non-functional to passive to active and non-functional, 3 times within 15 minutes, the device
enters suspended state. Flap max is the maximum number of HA state changes from either active to non-functional
before entering suspended state.
Monitor Fail Hold up time: The time the device waits before transitioning to the tentative state because of a
monitored object failure. Use this timer to prevent a device changing state to tentative due to a port flapping on the
directly connected upstream device
Additional Master Hold up time: Time the ACTIVE-PRIMARY device stays ACTIVE-PRIMARY upon a monitored
object failure. If the monitor hold up time is configured, the device waits MASTER HOLD UP TIME+ MONITOR
Control link
The HA control link also known as the HA1 link is used by the HA agent for the devices in HA to communicate
with one another. The HA1 link is a layer3 link requiring an IP address. The HA agent uses TCP port 28769 for
clear text communication, or SSH over TCP port 49969 if using encryption. This connection is used to send and
receive hellos and HA state information, and configuration sync and management plane sync, such as routing and
user-id information. Configuration changes to either units are automatically synchronized to the other device over
this link
The PA-4000 Series and PA-5000 Series firewalls have dedicated HA1 links. All other platforms require a revenue
port to be configured as a HA1 link.
Monitor Hold time: HA control link monitoring tracks the state of the HA1 link to see if the peer HA device is
down. This will catch a power-cycle, a reboot, or a power down of the peer device. To ignore the flapping of a link
that wouldnt necessarily take the HA control connection down, a monitor hold down timer for the HA control link
monitoring can be configured. The monitor hold down time is configured under the HA1 link. The default value is
3000ms.
Data link
The HA data link, also known as the HA2 link, is used to synchronize state, sessions, routing tables, IPSec security
associations, and ARP tables between devices in a HA cluster. The HA 2 link is a layer 2 link. It uses Ethernet as
transport by default with Ether Type 0x7261. Use this setting when connecting the HA2 link via switch or back-to-
back. The HA data link can also be configured to use either IP or UDP as the transport. This allows the HA data
link to be connected across layer3 networks. UDP encapsulation offers a benefit in that UDP computes a checksum
of the entire packet, as compared to IP, where the checksum is computed only on the IP header.
Note: The PA-4000 and 5000 series of firewalls also support using revenue ports as HA1 and HA2 links. Although
it's possible to use fiber ports for HA1, it is not a recommended use. The dedicated HA1 port allows for a direct
connection between the Control Planes of the two HA devices. By using an in-band port, the control messages will
be following a less direct route to the control plane through the dataplane. The possibility of a software fault on the
dataplane can cause a lost HA control message with adverse effects.
Backup HA links
In order to provide redundancy one of the data ports can be configured as a backup link for both HA1 and HA2
ports. The following guidelines apply when configuring backup HA links
The IP addresses of the primary and backup HA links must not overlap each other.
HA backup link must be in its own subnet.
HA-1 backup and HA2-backup ports must not overlap each other. Separate links (one each) for HA1 and
HA2 must be used as backup ports.
HA3 link
The HA3 link is used for packet forwarding between the session owner and the session setup device in an active-
active cluster. HA3 link is a layer2 link and uses MAC-in-MAC encapsulation. Aggregate interfaces can be
configured as a HA3 link on the PA-5000 and PA-4000 Series. This also provides redundancy of HA3 link. The
interface that will be used as HA3 link must be set as type HA
Note: No backup links can be configured for the HA3 link. Use the aggregate interface on the PA-5000 and PA-
4000 series if redundancy is required.
IP modulo
The session setup load is distributed in the HA cluster by the parity of the source IP address. This
option provides a deterministic method of sharing the session setup.
IP Hash
Hash of either source or combination source/destination IP address is used for distributing session
setup
Primary device
Device in the active-primary state will always setup the session. This setting will result in only one
device performing all session setup activities.
Note: Because of the overhead associated with the encapsulation on the HA3 link, the switch ports
connecting the HA3 link must be configured to support jumbo frames
If the session ownership is configured to the primary device, then the session setup defaults to the primary device. A
sample screen shot of the configuration is shown below.
Note: Setting the session owner and the setup device to be the primary device is not recommended since all traffic
processing will be performed by the active-primary device. However for the sake troubleshooting and capturing logs
and pcaps it can be useful to set the session owner and setup to primary since the packet processing will not be split
between the devices in the cluster. For all other purposes the recommended setting is to use First Packet for
session owner and IP modulo for session setup
The session setup load sharing will then be determined by the session setup and session load sharing configuration
under the HA3 link.
If you select IP-modulo for the ARP load-sharing algorithm as shown above, choose First Packet for session owner,
and IP-modulo for the session setup algorithm, as shown in screen shot below, The sessions will be setup and owned
by the same device.
Configuring Floating IP
From the Device>high availability>Virtual address section click Add to add a new virtual address. From the
interface drop down list choose the appropriate interface; and click Add. From the resulting screen chose the type
to be floating. The device priority determines which one of the devices will own the floating IP address. We
The command show high-availability virtual-address can be used to view all configured floating IP
addresses
--------------------------------------------------------------------------------
Tip: Interface management profile with PING as service must be configured in order to ping either the ARP load
sharing or floating IP Address
Before configuring the NAT rules, you must verify the floating IP address priorities on the devices.
This can be viewed from the Web interface or using the CLI command >show high-availability virtual-
address
In this example the following priorities are assigned
Note:
You must use the IP type as floating IP to configure interface based source NAT rule
From looking at the session details, we see that PA-2 is the session owner. This is because the first packet of the
session from the host 172.35.2.4 was sent to the IP 172.35.23.101 owned by PA-2.
The session setup is determined by the session setup load sharing configured on the HA3 link. Note that session
setup and the owner device can be the same. In this example the session setup is done by the peer device.
From this example we see the session setup device matches the NAT rule bound to the device-id 1,which is the
session owner, The source IP translates to floating IP address 10.1.1.101 owned by device-id 1
Note: If you have an existing active-passive configuration with pool based NAT, you will need two separate IP pools
in order to implement active-active HA
All existing sessions will be translated to the current NAT mapping even if the NAT IP is owned by the
failed device.
All new sessions are translated using the NAT rule matching the device-id of the functional device.
A destination NAT rule must be configured for both the devices to respond to the ARP request. The NAT rule
configured is shown below
Configuration
In the IKE gateway section of the configuration choose floating IP address as the IP address of the interface
A tunnel interface must be configured on each of the devices, with a unique IP address. Note that the IP addresses of
the interfaces are not synchronized between the peers. The routes via the tunnel interface will be synchronized
between devices.
PA-1
Also note the encap and decap byte counter increment only on the firewall PA-2, which owns the floating IP address
The remote-ip column shows 0.0.0.0 if the device does not own the floating IP address
Upgrade procedure
The upgrade procedure is as follows:
1. Suspend the active-secondary.
2. Verify that the active-primary is now passing all traffic.
3. Download and install PAN-OS on the active-secondary.
4. Restart the active-secondary to complete the installation.
5. Verify the active-secondary is passing traffic in a functional state.
6. Suspend the active-primary.
7. Verify that the active-secondary is now passing all traffic.
8. Download and install PAN-OS on the active-primary.
9. Restart the active-primary to complete the installation.
10. Verify the active-primary is passing traffic in a functional state.
11. Verify that both firewalls are passing traffic correctly as an active/active pair