VRRP with Cisco router LAN interface

[DonCurrie]

My default branch configuration, the WAN router is the default route for the client devices on the LAN.  Lets say 10.10.1.1/24

My firewall is the default route of the WAN router, lets say 10.10.1.254/24.

Cheap layer 2 switfh on the LAN, so no L3 routing option there.

In the above setting, clients send all packets to WAN router, Internet traffic is then sent to firewall for local browsing.  private packets send over WAN circuit.  If WAN circuit fails, all packets sent to local firewall.

My firewall has a backup IPSec tunnel in case the WAN circuit goes down.

All above is fine if only the WAN circuit goes down.

I want to further this backup/redundnacy by running VRRP between my Cisco WAN router and the PA firewall. so if the Cisco WAN router dies, the firewall becomes the 10.10.1.1/24 address and thus the default route for the client devices on the LAN, and thus uses the IPSec backup tunnel.

In the past with Juniper firewalls, this was no problem, Juniper supports a VRRP group and virtual IP for the LAN Trusted interface.

I dont see this available on Palo Alto????

[kiwi]

Hi @DonCurrie,

At this time the VRRP protocol can pass through the firewall, but it will not participate. Clustering uses proprietary mechanisms (requiring a HA1 and HA2, and possibly HA3 direct link between 2 chassis) and is achieved through gratuitous ARP.

There is however an existing feature request for this.  Please reach out to your local SE and have him add your vote to FR #2666

: To support the VRRP Protocol to do a cluster between the Palo Alto Networks Device and a router or another FW.

Cheers !

-Kiwi.

[Eco-Energy]

As it stands, the problem here is that there is no alternative to a traditional DMZ when dealing with multiple Firewalls that are not in an active-active setup due to geographic location or any other reason that they are not using HA. 

In those scenarios with two separate firewalls you also have the scenario of a typical single inline firewall vs a dual inline firewall scenario (one firewall facing public/DMZ , one firewall facing DMZ/Internet).

When you combine two seperate firewalls with a single ended DMZ where the default gateway for the DMZ exists on the firewalls, you are put into a situation in which you need separate independent (automated) IP migration like VRRP. 

In that situation you have to have to firewalls each with an independent address (lets say 172.16.1.2 and 172.16.1.3) but on your client devices you typically have 1 singular default gateway (lets say 172.16.1.1). So in order to control traffic, you have to add a 2nd IP address (172.16.1.1) to the DMZ interface of a single firewall. Given that you do not support VRRP there is no automated way of moving this IP from independent DMZ firewall 1 to independent DMZ firewall 2. So instead, as an administrator, I have to manually migrate the IP address in the event of a failure which isn't exactly clean (considering the side that is down still technically has the IP attached). 

So when a failure occurs, I can make the IP appear again on the backup manually, but since I can't access the primary (due to a site failure lets say) I can't get in there to remove the 2nd IP (172.16.1.1) from the primary firewall. Meaning two things will happen. 

One if the Primary side comes back online, communication is broken (due to duplicate 172.16.1.1 addresses existing) until I can get in and remove the address from the backup. 

2nd, if the sites are flapping due to a provider issue, there is no mechanism to quickly transition the IP from one FW to the other FW.

What I would recommend from a development standpoint is that you focus your clustering on being able to withstand geographically distant firewalls, from there integrate the floating IP function across the Clustering function where if the cluster link is lost, the IP pops up on the other side (similar to how VRRP works). 

To be clear, it is not that you need to provide VRRP specifically, Only that there is a mechanism to automatically move IPs between firewalls that are not in an active-active pairing that can connect not just two firewalls but up multiple (like up to 😎 in such a way that you can host your DMZ horizontally across multiple datacenters to provide higher availability. 

[Eco-Energy]

TYPO

(one firewall facing public/DMZ , one firewall facing DMZ/Inside LAN)

[OtakarKlier]

Hello,

Why not use the same firewall for all functions? A DMZ is just a vlan where the traffic passes through the firewall upon entry/exit.

Just a thought?

[Eco-Energy]

So I think what you are probably describing would require a separate DMZ switch or a separate firewall, where in my environment, all Vlans traverse out to my core switch, but the DMZ vlan is flat outside of the firewall, that way I can extend into VMware and such for hosting virtual machines. I'll attach an image as a brief example of what it looks like logically.

In order to utilize the firewall at a L2 level the firewall would have to physically sit between the DMZ host and the DMZ gateway. I will post a proposed picture as an example in a minute.  one example I can think of is a separate switching structure (not just a vlan) to force L2 traffic to go through the firewall and across into a default gateway sitting on the other-side of the firewall. Another example, is you add in a 2nd firewall inline with the current one so that one firewall operates at L2 and the other operates at L3, though the default gateway would have to be migratable still on a switch... so you would be looking at a firewall and two more switches.

[Eco-Energy]

Here is that example with a separate switch stack.

You essentially use the firewalls as L2 in-line with your primary core VRRP switch stack being the only switch that can actually route out of the DMZ. If you tried to do this on the same L3 switch you would essentially bypass the firewall all together which looks very similar to this except, it would be a switch stack with routing that would be isolated separately on the switches, with the primary switch stack still keeping the DMZ vlan as an L2 flat vlan. 

[Eco-Energy]

Hello again, 

Here is an example with two sets of VRRP switches still one set is more or less dedicated to routing the DMZ while the other is flat. In this situation, all L2 traffic still flows through the firewalls to a set of DMZ L3 switches that perform VRR. While the regular Production switches maintain the flat Vlan. Because the router is connect to both at the L2 level, it can intercept the traffic on its way to the default gateway. Once it reaches the default gateway, it then needs a unique routable path outbound to one side or the other. In my example I used a separate Vlan + Vlan interface for the 172.18.2.x network, which would be a routable outbound path to the rest of the environment. I..... think the palos might be capable of doing all of this without the 2nd vlan I'm referring to by perhaps using a DMZ vlaninterface and assigning an address of 172.16.1.3 + 172.16.1.4 to the routers, but i'm not sure. I do however know that it can be a trunk in which the DMZ vlan is flat, but the DMZ EDGE Vlan has a subinterface. 

But regardless the path would start on a flat vlan in a production switch go through the firewalls, into a separate set of switches hosting the default gateway, then from there be routed back out to the rest of the environment.

If you have any ideas on like other ways to do this I am 100% open to alternatives. Please correct me if i'm wrong in here somewhere as I am doing this all on theory. I am sincerely looking for a possible answer that doesn't require manual movement of Default gateway IP addresses.  

As a side note to this, one thing I have been reading up on is the use of multiple default gateways on the server. Like removing the single IP default gateway but have symmetric routing so that traffic comes back the way it came. But I have personally never done it, but it might another option.

[SARowe_NZ]

Hi,

It's a constant pain with Palo and I can't believe they still don't have a solution to provide automated gateway redundancy but that is the reality (unless you have A/A firewalls which almost no one can do).

In your scenario you only need the IP on the interface on the second firewall if that firewall needs to route over that interface under BAU. If it does not, you can simply have the interface with the real IP on your primary firewall and no IP on the secondary firewall, then create it on the secondary firewall in a failover scenario.

If dealing with multiple interfaces you can script it to create/move the IP a little faster.

Another way I've dealt with this (when using more upstream or downstream routers is not an option) is to create all your required interfaces in a second VRF on the second firewall, all with the real IP address. If you have a failure, just enable routing between the VRFs to "liven up" all the interfaces that are usually offline. This could be static if your subnetting allows for a single route in each direction, or you could use a dynamic protocol and just have it disabled under BAU. This works really well for DR / BCP environments or when dealing with a lot of interfaces that would make manually moving IPs very tedious.

Not saying it's a solution - just another way of working around the lack of functionality...