1. High Availability Overview
In this lecture, we’ll talk about high availability. The Palo Alto firewall supports two types of high availability: active passive and active active. In the case of active-passive, you have two firewalls. One of them is the active firewall that is forwarding the traffic, and the other is a backup firewall that is sitting there waiting for the active firewall to fail. And if the active component fails, it’s going to take over the functionality. So the two firewalls, active and stayed by, work together to ensure that no sessions are dropped and that the user does not have to reestablish the session. The active firewall synchronises the sessions with the standby firewall, and it also synchronises configuration with the standby firewall. In the event that the firewall fails, the standby firewall would take over. The way the firewalls would feel is if any of those different scenarios occurred, such as link monitoring or path monitoring. In the case of link monitoring, the firewall has interfaces for trust and untrust. You can also specify the number of interfaces that will occur if one of the interfaces or multiple interfaces go down the field. If the active firewall has a couple of interfaces and one of them goes down, it sends a signal to the standby firewall that “hey, one of my interfaces went down,” and then the firewall would take over the session and continue forwarding the traffic out to its own interfaces. In the case of path monitoring, if the firewalls are connected to upstream devices, and you want to ensure that this firewall is in one switch and this firewall is connected to another switch, and that the firewall, the active firewall, monitors the outer, And if the code outer goes down, that means the switch is down, and if the core router is down, that means the switch is down.
When a switch encounters a problem, such as a routing or spanning tree issue, it will signal by pinging the router’s IP address that this address is not reachable. In that case, the other firewall, if it has connectivity to that router, is going to go ahead and take over the functionality. So this typically gets used if you want to monitor an upstream path and ensure that that upstream path is reachable. And if that upstream path is not reachable, then the firewalls would failover to the standby firewall. So those are the two types: link monitoring and path monitoring. You have different types of platforms: the Palo Alto platforms, the low-end Palo Alto platforms like the PA 200502,000, don’t have a dedicated Ha interface. So there are two types of HAL interfaces, and we’ll see the difference between the two. You have one and two. The small low-end Palo Alto firewalls do not have the same high availability as the VM series.
They don’t have high-availability interfaces. However, everything that’s 3000 and above will have an Ha-1 interface and an Ha-2 interface. The benefit of using the Ha One and Ha Two interfaces is that they are located on the firewall itself. There are two planes. You have the management plane, and then you have the data plane. The management plane and the data plane are typically on different CPUs, and the data plane is much faster than the management plane. If you have an H1 or H2 interface, it will go through the data plane. Low-end platforms, such as the PA 200 and $502,000, lack dedicated CPUs for separating management and data planes. So the recommendation from Palo Alto is that if you have one of those low-end platforms and use the management interface for Ha One, you’re still able to run High Availability. On the low end You are repurposing the interfaces that you would use for traffic. You are repurposing them for high availability. We’ll see how to do that. The control link, data link, backup links, and path monitoring links are the various types of high availability interfaces. The control link is the Ha One interface, and the control link is used to send a heartbeat between the active and standby firewalls.
It’s used to synchronise configuration, user ID information, and other IPsec-limited information. The data link is the shape interface, and the HJ Two interface is used to synchronise the sessions, arc tables, routing tables, and session-related types of information. If you want to have a backup for Hoon to ensure that if HRone fails, there is a backup for that issue, use the backup links. One, you can configure an itchy-one backup, and you can also configure an itchy-two backup if you want to ensure that there is no failure on ha two. If H fails, an interface takes over the functionality, and then path monitoring links are used for active firewalls. Where do the backup links become useful? If you have, for example, two firewalls, the He1 interface is connected to one switch and the Ho2 interface is connected to another. The Ho One backup interface is connected to another switch, and you want to guarantee that if that switch fails, the interface connected to the Ho One backup interface connected to the other switch would take over the functionality. So you are trying to eliminate a single point of failure.
So the Ha One and the Ha Two interfaces rely on underlying protocols to synchronise information. The Ha One uses TCP ports 287-6969 and 28-260, and the Ha Two utilises either. If you have the two firewalls connected directly to each other, it’s going to be using Ethernet. It’s not going to be using any IP protocol. It will use its own internal Palo Alto proprietary protocol over Ethernet. Ethernet type 761 if you have firewalls connected across networks. So if you have the firewall connected across a routing network and you are using a routed interface to send traffic between, for example, two locations for active standby failover or active failover, you would use the IP, which would use IP protocol 99, or you can use EDP, which utilises UDP port 29 two eight one. The same thing happens with Ho.1, which employs TCP for communication. If you want to perform an issue one backup, use protocols 28 770 and 28260 in case there is a firewall between the active and standby active and the active firewall. The recommendation is to have a heartbeat backup that utilises the management interface. So you can use a heartbeat backup interface that uses the heartbeat backup and set it to paying the management interface to guarantee that there’s another level of guarantee that the other firewall is up and running. Another thing we have to talk about is preemption. As a result, each firewall has a device priority.
So if you have a firewall in an active-standby pair and both of them are coming up, whoever becomes active first would stay active. If you have a priority that’s lower, like, for example, this is ten and this is 100, 100 is the default. If you have a lower priority firewall, it is preferable to be active. However, we have to set preemption. So if you set preemption, if there is a failure on this firewall, the slower priority goes down, and the other firewall picks up. And if that firewall comes back up, and you don’t have preemption enabled, the standby that became active will remain active. However, if preemption is enabled, the firewall with the lower priority will take over the active wall. So this is basically like HSRP preemption. If you’re familiar with HSRP, it’s kind of the same concept. You should also set the active firewall to a low priority and enable preemption for it to preempt. In a failure situation, the same thing occurs. If an interface fails on the active firewall, the stem firewall will take over. And if that interface comes back up again, if you don’t have preemption enabled, the standby firewall will stay active. But if you have preemption enabled, once that interface comes back up, the firewall with the lower priority will become active.
2. Active Passive Configuration Configuration Example
In this lecture, we will see how to configure Haactive standby on a pair of Palo Alto VMs. And this diagram is a little bit busy, but I want to go over it to explain what’s happening here. So I have two firewalls in this configuration, and Ethernet 1 4 and Ethernet 1 5 play the roles of Ha 1 and Ha 2 on both firewalls. And this network—170, 216, and 1130—connects to a router, and then from the router, it connects back to the other firewall. So the Ha one has connectivity from between interfaces—that’s Ethernet 1—all the way to the other firewall.
That’s how the Ha is configured. The Ha two experienced the same thing. This is the second installment. This is the Ha 2, and the Ha 2 is connected to both via Ethernet 1, 5. The IP address of the H A 2 interface on this firewall is 172 16 2 1. This router’s IP address is 172 16 2. It’s 172, 162, 266. And then I have the Untrust and Trust interfaces. This is the untrusted ethernet and the trusted ethernet, and I just have two routers to represent the inside and the outside. So, let’s look at how to set up the HA or active standby on this setup. And now that I’m logged in, I’m going to go to the network tab. I’m going to start with the firewall one. I’m going to go to Ethernet interfaces, and I’m going to click on Ethernet 1-5 and change this to an H interface. Just select H and then bring the interface up. Then do the same with Ethernet 1&4. I’m going to change this to “Ha, bring it up.” Returning to the diagram, h1 represents Ethernet h4. Ethernet 1/5 is H A 2. So we’ll go ahead and go to deviceset up high availability, then click on this settings icon, enable achieve, and then specify the group ID. The group ID must match between the active and standby firewalls, and active and passive must be specified. And then we’re going to specify the HA-1 IP address of the peer. The peer’s Ha-1 IP address is 170 216 1 5. So I’ll put 171 and 5 together. And Ha One’s IP address is 1-6-1130. The default gateway for this connection is then 1216 1 2; If the two firewalls were connected to the same network, you wouldn’t need to set a default gateway.
However, if they are on a different network, as in our case here, where this is going through the HRone router, we must specify the next top, which is the gateway. And then we’re going to go ahead and click on the settings for controlling Ha 1. We’re going to specify the interface, which is Ethernet, and put the IP address (172 16 112 55 2552) and default gateways. And now we’re going to need to change H.2 to H.2 as best practise to enable session synchronization. Otherwise, they’re not going to synchronise the sessions. Choose the interface, which is Ethernet. Specify the IP address. The IP address of Ethernet is once we do “16 two,” “dotone once we do “16 dot two,” “dot 125-5252,” the gateway is “7216 two,” because they are not on the same network. There’s a layer of three hops in between. You have to specify either IP or UDP. I want to specify IP, and then the hoto keep alive is: what is the threshold if you want to doan H A two keep alive? Or if you want to do a split data path, which I’m going to explain now, we need to go to election settings, and this is H E 1. This is Firewall one. We’re going to set it to ten and then set it to preemptive. This is the heartbeat backup I was talking about. Using the management interface, you can specify which hard drive backup is the heartbeat backup. We’re not going to check that. Click okay. And then click “commit.” We’re going to do the same thing on the second firewall under Device High Availability. We’re going to click on settings with the setup for HAEngagement Group 1, the same group we selected. The type is active-passive ho one IP address, the ho one IP address of the peer is one, and we’re going to go to the ho one interface we’re using. There’s a step messed up here.
We need to go to Network and select Ethernet 1415 as a Ha interface to bring the interface up, then go back to the High Availability tab. We are going to configure the HAWK link for Ethernet. 172, 16, 15521, and 7216-1 are the IP addresses. I’m not going to encrypt it because I want to show you guys in the TCPcapture the actual traffic with synchronization. So this Ethernet one four, followed by Ethernet one five, is the Ha two; that is the IP address of the problem. Two is 1216 for firewall two, two five, and two six is the default way six. We’ll do the same thing we did here: choose IP and issue keepalive, and this device is priority 10. This device has priority 100. You can also enable preemption, and then we’re going to go ahead and commit. Before I commit, I want to show you the current capture so we can see the traffic going over the Ha 1 and HJ 2. So we’ll capture this one as well as the other two. We will see the traffic. Once I push the configuration, I’m going to commit this, and we should start seeing some traffic here. This is not being found. It’s still synchronizing. So the firewall is trying to synchronize, and now it looks like it has started synchronization. So we have a TCP session, like we mentioned in a previous lecture.
The starting port is 28 and the ending port is 7, 6, 9. and this carries the configuration data. So I’m going to do a follow TCP stream, and we can see the data of the configuration that passed across here. There’s some traffic. The IPV. Four traffic. It’s protocol. When I specified IP, it’s a protocol. What’s the protocol number? It should be protocol 99. any private encryption scheme. So we actually see communication across the board right now. Let’s see if we see any more data. I see it. Binging. This is the heartbeat. And we have the TCP session here. If I go ahead and follow the TCP stream one more time, we have data going across here for synchronisation of different settings to look at the dashboard. You can look at the dashboard and see that the status says “not synchronized.” We’re going to click on synchronize. I’m only active right now. I’m going to synchronise the passive. It should be synchronised right now synchronized.
So it should click on “sync to peer.” It’s going to start synchronizing, and we have an issue with synchronization. Let’s verify the settings are correct. This H A one peer has one, 7216, and 1516 peers. One default gateway is 121-5161. One is up. Ho two has arrived. I’m going to initiate sync from both sides. The VMs are pretty flaky sometimes. So this is to demonstrate the modest active passive. This is the passive firewall, and the active is the pier. And now they’re synchronized. So we should have seen some more data as far as TCP conversations are TCP stream.There’s a whole bunch of data here. And this is the actual configuration getting sent across the wire. So that’s basically the procedure for configuring active standby. Next lecture, we’ll look at link-and-path monitoring and other settings for active standby and active passive.
3. High Availability Active / Passive different failure scenarios HA1 HA2 heartbeat
So now that you have the active and standby firewalls communicating with each other, anytime you make a change on the active firewall, it will synchronise with the passive firewall. So we’re going to go ahead and configure the untrusted and trusted faces so we can see that. And I have a debug going between them for the high availability agent. So, after going through all of these lectures, this is the first firewall we’ll put up in the untrust zone. I’m going to zoom through it. We finished preferring the interfaces and brought them up as soon as I hit commit. You should see the configuration going across here, sending a configuration load message.
And now, if you check the standby firewall refresh configuration, we have it configured the same way. I see on the dashboard that they are synchronized. When you see those, they’re red because they’re not forwarding traffic because they’re on standby, waiting for failover. So the configuration got carried over, and now if I create a session between the inside and the outside, I want to create a session between the router on the inside and the router on the outside so we can see the session getting transferred over to the other side. I need to create a net entry so we can add the traffic. You do the configuration on the active firewall; the original is in the trust zone; the destination is the untrusted translated packet; then it can be imported; and you translate the interface address (ethernet) and select the IP address. So once I click commit again, I should see the configuration getting sent again to the other side. They are confirming to each other that they’re in sync. Okay, so now on the other side, we should see the policy getting carried over. We see the policy, and I’m sorry I forgot to create a security policy. Just add a security policy to allow any confirmation that should be coming here any second. Okay, so I’m going to go to the router on the inside, turn it on, and then go ahead and terminate and add a password here. Sorry.
So this should be a constant session. If I go here and do a show session, I should see it. See, that session should show up on the secondary firewall because they synchronise with each other so that if one firewall fails, the other one will pick it up. We see that same session even though it’s not forwarding traffic, but it’s already waiting for failover to occur. One of the issues to be aware of when configuring active standby, and the reason for Ha backup and Harvey backup is a situation called “split brain.” Basically, what happens in a split-brain situation is that you have an active standby firewall. These ten firewall interfaces are not in use; they are turned off, waiting for the activiwall to fail or lose heart. If you have an hoon link and that hoon link goes down and there is no backup for that hoon link, there’s no hoon backup. The standby firewall doesn’t have any way of validating that the active firewall is reachable. The thing that it’s going to do is bring up the interfaces on both interfaces up.So this interface will come up, and this interface will come up. This firewall is not aware that the standby took over. So it will keep its interfaces operational. This is why it is important to have a home backup so that if this situation arises, the backup will pick up. There’s also a heartbeat backup that prevents a plate-brain situation. The Harvey backup utilises the management interface. If the management interface is on, both firewalls are able to reach each other. The manager interfaces were used to send a heartbeat.
So, if one fails and the heartbeat is still reachable, the standby firewall will not uncheck its interfaces, and you will not have two firewalls forwarding traffic. When you have two firewalls for traffic, what’s going to happen is that the switch down below will see the Mac address on both links. So let’s say this is the inside network. This switch will see the Mac address here, and then we’ll see it here. So it’s going to afford some traffic here and some traffic there. And the outcome of this split-brain situation is that you will have a non-functional network. So to avoid that split-brain situation, what you need to do is either have a heartbeat backup or a ho backup. This is the key thing, right? To synchronise the session table, use ho two. So let’s see when we shut down. I’m going to shut down the interfaces for Hoone, and let’s see the split-brain situation. So it’s Ethernet number one four. I’m going to shut down one router. Let me see the config first.
So one is no longer standing. If we look at the show debug log, it’s doing a host-based monitor. And right now what’s going to happen is that this firewall will bring its interfaces up, and you have a split-brain situation where I have two firewalls with the same IP address to see that this interface is still up. If I go to the dashboard tab, this interface (HR 1) is down, and HT (2) is down. Right now, there’s no way for this router to figure out that the other router is up and running. You’ll have to take the easy way out. For example, if the active firewall advertised, the standby firewall would not be advertising anything. In that situation where you’re going to have two firewalls, they might both advertise the default route, and you might have some traffic going one direction and the other traffic going the other direction because this is how, if you have two equal routes, they would load and balance the routes the way typical routers would load and balance the route.
Once I bring back the router again, the Host One network should be coming back up. We’ll see what happens here. It just hit start, and then, because I configured preemption, the active firewall would take over. So I’m going to keep refreshing here until I see a change. Okay. It now appeared and reclaimed the functionality of the active. And now, if you look here, the interfaces are down once more. So let’s simulate that same situation. with a backup heartbeat using the management interface Click here and then enable heartbeat backup. When you enable harbour backup, the configuration of the firewalls and the high availability are not synchronised across because they are unique to each firewall. So you have to make sure you have them the same on both sides. Click okay here, and I’m going to click okay here. Harvey backup. Okay, commit here. And now Harvey should be crossing as well. So I’m going to go ahead and shut down the throttle one more time, and we’ll see what happens.
Okay, so receive primary acknowledgement. If I look here, it’s going to show that the hoon is down, but the heartbeat backup is up. So it’s not going to go back to the situation where it’s going to bring up one interface and the standby firewall will bring up its interfaces. So that the two firewalls are not fighting over routing table entries and advertisements and making their way through our tables to downstream and upstream devices, which could cause major issues in your network. So that’s how you could potentially avoid it by configuring the heartbeat backup. And we’ll see what happens next week. So, let’s see what happens when I power down the HO router. For a refresher on the issue two router, see this. They’ll bring both H.2 and H.3 interfaces down. We’ll see what happens there. Now that issue two is down, the sessions are not going to get synchronized. Allow a minute for three lives. Issue two went down, and if I look at sessions, I’m going to initiate that terminal session one more time here. If I show a session as active, I have that session open. When I go to the standby and do show sessionall, there is no session and the issue 2 link is unavailable. The worst-case scenario is that these sessions will not get synchronized. And if it’s a situation where the sessions are not synchronised and the firewalls fail over to each other, what will happen is all the users will have to establish the sessions, which might be an issue or might not be an issue.
4. High Availability Active / Passive HA1-backup, HA2-backup configuration
We will configure the Ha One backup and the Ha Two backup in this lecture to see how the failover occurs when the Ha One backup fails and the backup takes over. And H A 2 backup will take over the rule of performing the Ha 1 role (configuration, synchronization, user ID, and other settings) and the Ha 2 role (sessions, arc tables, routing tables, and so on).
So I created an Ha-1 backup on the same routers here that I have, Ha-1 and Ha-2, and I’m using the third octet up from the existing one. So let’s go ahead and do the configuration. We have the two firewalls synchronized. Right now we’re going to go to “Network,” and we’re going to go to “Device High Availability.” Then we have the control link, HaOne backup, which will be Ethernet 1. We must first configure the interfaces to be Ho interfaces. So in my configuration, I’m using Ethernet one-six for Ha One backup and Ethernet one-five for Ha Two backup for Hoo backup. As a result, Ethernet 1/6. Then go ahead and configure the interface for Ha and bring the interface up. And then under Device High Availability, we’re going to hook up backup. We’re going to select Ethernet and put the IP addresses 172, 16, and 2252-525-5252. And the gateway is, followed by Hoo backup, Ethernet first.
Here you see the backup port’s one IP address. That’s going to be the other firewall IP address, which is one octet up, which is two dot five. So back up here: h.a.1.ip address, 16 two, dot five.Sorry, there’s a mistake here. I changed the addresses, so they could not have been used previously. So I’m going to change this to three and four instead of two and three because two was already new. So let me do that. Your backup is three, and Hotwo’s backup will be four. Okay, so let me reflect that here, and then take the Hoon backup IP and do the same here. First, go to Network and set the interfaces to hang them up. Yes, the commit is taken over because it is synchronized, but the high availability section is not configured because it is unique to each file. It also carries over the interfaces that the six and seven have. But the High Availability section is not configured. So we’re going to go ahead and configure that that’s Ethernet.
Then there’s H A 2172 dot 16, dot 4, 525-2521, 7216, four dot six. Then, as a backup, an IP address. and I’m going to commit this one here. Go to the dashboard. Now we see H’s backup heartbeat. Backup down. Let’s figure out why this is happening. Dashboard, it’s coming up right now. HR has two backups. HG’s one backup is down. Let’s verify that I have duplicate Arps here. So I must have configured something incorrectly. Check 353-625-2546. I have this configured incorrectly; it should be 2132; that’s why the one backup is down. I’m going to go ahead and commit. Okay, so let’s see now in the dashboard that everything is up and let’s capture the traffic. So we’re going to go ahead and capture the traffic on ha one backup, that’s Ethernet one two, and let’s see what traffic is going to cross. Just ping echo and ping reply request 3135. They confirmed that the other side is up and running over that home backup, that no configuration is required, and that synchronisation has occurred. At least we haven’t made any changes here. So, that’s ha one backup; let’s doha two backup and see what happens.
It is sending some data (protocol 99, probably encrypted data), so it is sending some stuff over; it’s probably a heartbeat, but let’s bring it in now, so right now when this is happening, we want to simulate a failure on HOA one and see what happens. Let’s create a session first. We’re going to create a session from this firewall, from this back-trusted router, so we have a different session here. On the first firewall, we should see a session that shows all of the sessions we have; on the second firewall, we should see a session that shows all of the sessions we have, even though it’s passive but transferring the session. So what happens when one backup fails? When one backup fails, nothing is going to happen; it’s going to continue working exactly as it is without any disruption. So we’re going to go ahead and shut down the interface to simulate a backup failure. You should notice that the hoon’s heartbeat is decreasing. One went down, but nothing changed; the firewalls didn’t failover, and there were no issues. If I create another session, the other sessions should continue working. We see two sessions here. We see two sessions here. It continues to work seamlessly working.
And if I do shut down the two-main interface, the same thing is going to happen. Because our two backups will take over this position. Issue two should have been resolved. Issue two takes over. So the sessions would still get relayed over the issue of two backups and create another session. On the active show session, all we have is the session transferred over, so that’s why you would need ha one backup and ho two backups, and it makes a whole lot of sense if you have a situation like we mentioned a couple of lectures ago where the ho network is going across two different switches. You want to make sure the hoon is going across one switch, and you want to make sure that one switch goes down. The backup switch with hoon backup takeover ensures that there is no failure. However, if the links are connected back to back and the firewall hook interface is connected back to back, it is extremely unlikely that the physical interface will fail. It’s still a good idea to have a backup just in case you’re arguing. You are kind of taking precautions in case a situation arises where somebody unplugs the HR One interface by mistake.
5. High Availabilit active / passive link and path monitoring, HA operations
In this lecture, we will talk about how to configure links and path monitoring. Link monitoring allows you to monitor the firewall’s link to determine whether or not it is operational. If the link is down, the link goes down. The other firewall, let’s call it this one, is an active and calming wall. You want to ensure that if one of my links goes through the firewall, it will fill over to the firewall. This is the purpose of link monitoring. So you can have a firewall with multiple interfaces, and one of them is not important. So you don’t want to failover in the case of this interface that connects to the management network or any other network that you don’t feel is important. You must configure the firewall for specific link monitoring to monitor specific interfaces and create your failover criteria.
So you can configure the link monitoring by default; it’s configured for any link, and you can configure it for specific links or link groups. So you can have a link group for the untrusted trustdmz and this link group; if any of those links fail, you will failover. This is a tap interface. You don’t want to failover if this TAP interface goes down. So you put those interfaces that are considered important for you in a link group, and if any of those interfaces fails, you payover to the other firewall, which is configured to high availability by default, and the failure condition is any. You can specify link groups. You can call this link a group of important links. And if any of those interfaces fails, Ethernet 1, Ethernet 1, Ethernet 2, will fail. Those are the important interfaces. If any of those go down, then you would failover to the peace wall, and then you have path monitoring. What path monitoring allows you to do is monitor a path to verify that it is reachability over that path.
So for example, if you have a situation where you have the active firewall and the best firewall configured connecting to two different switches and upstream to two additional different switches reaching the internet, the indirect failure of that upstream switch will not be reflected on the interface. So how can you verify that if the upstream switch fails and that upstream switch doesn’t equate to your interface on the firewall failing, you would want to monitor the path? Let me redraw this failure of this switch. It will not equate to the interface going down. So you want to monitor the IP address of the interface on the router. Or you can monitor a public IP address. For example, in our case, we’re going to monitor the interface on the upstream router. One. One. And if that interface goes down, or if that switch upstream goes down, that IP address will not be reachable via the active firewall. And the active firewall, once it realises that the IP address is not reachable, is going to signal a failover situation where the passive firewall will pick up. Once that switch upstream becomes active again, it will go ahead and take over because we configured preemption. I replaced that hub here; it was in the previous lectures. I replaced it with the switch, and I’m going to simulate the failure by bringing down that switch interface. Since this is a virtual environment, the switch interface going down doesn’t equate to the physical interface going down.
So that’s not going to trigger the link monitoring; that’s going to trigger the path monitoring. So on the active file, I’m going to configure and add a virtual router path. You have to specify the name of the virtual router that you’re going to be using because that’s where, if you have multiple virtual routers, you can have a virtual router monitor different IP addresses. And here I’m going to specify the IP address to monitor, and then the ping interval here by default is 200 milliseconds, and after the pin count of ten, it’s going to go down. So 200 milliseconds and ten would take at least two minutes to fail. We’re going to reduce this to two instead of ten. The maximum value of this field is the ten-pin count. Oh, the ping interval is 200, and the minimum pin count is three. So we’re going to specify the minimum, and the IP address is one. One. I can go ahead and click OK on that. We’re going to go ahead and commit. That information will not show up on the passive firewall because, like I said, the high availability configuration is unique to each firewall. So that’s not going to translate to the peace wall. Well, it’s finished, just to prove the link path monitoring on the passive firewall refresh.
There’s no configuration here because that’s unique to each firewall. So I’m going to go ahead to the switch and I’m going to shut down the interface connected to the active firewall, which would be interface Ethernet Geo 1, and that would result in the firewall failing the path test, even though there is no direct link failure. And it’s going to switch over to the other firewall as soon as you want. So I’m shutting down that interface, which should be okay. And you can see that local is no longer functional, the path is down, and peer has become active. We go to the dashboard, and here the peer has become active, but because we configured the preemption and the active firewall has a lower number as far as the file priority, it’s going to go ahead and failover once that interface becomes active. So if I go ahead and unchart that interface, the active firewall should take over. Dashboard is still inoperable. And now, this farewell has realised that the path is now reachable, and it intends to take it. The preemption still hasn’t preempted yet, but it should preempt in a minute under High Availability. The preemption timers’ defaults are 2000 milliseconds (2 seconds) and the preemption hold time is 1 minute. So it’ll take at least three or four minutes to fill over.
And this is done to prevent link flaws from causing the firewalls to fill up. And as you can see, it became operational. After 24 minutes of that interface being back up, the active firewall reclaimed responsibility for active forwarding. And the reason why this is done is to guarantee that if you have a link flap, they don’t failover back and forth quickly enough to cause issues under the election settings here. The recommended hovers can be recommended or aggressive if you want to make it failover faster. Or you can select Advanced and specify your own settings here. And then finally, under Operational Command, one other command that you can issue is, let’s say you know that there is going to be an issue with the active firewall and the interface is going to go down because of a predetermined change that’s going to happen.
You can go to Device, then High Availability, and then specify Suspend local device, which will make that device non-functional. And this firewall would become active. This could be done because you’re going to be upgrading the firewall operating system. Or it can be done because you’re making a change that would cause an issue on the active firewall and you want to preamp that failover in a controlled manner. And then once the device is back on your personal list, you can click on “Make Active” again. And once you make it active because preemption is enabled, it should pick up as well. And it will pick up because after the timeout, the whole time expires, which is like three minutes.
So it should take three minutes. You can also do this from the CLI. From the CLI, there’s a command that you can use to create that firewall. Is this the active firewall here? It’s still passive. Let’s wait until it becomes active. Redemption isn’t able to; it should become active any minute now. and it became active. If I refresh here, I can do the same thing; it went from passive to active. And I can do a request system with “high availability,” “high availability,” “state suspend,” that’s going to do the same thing. As a result, I’m suspending the active. If I return here, it will be suspended, and the other one will failover. So you can do this from the CLI or the web here. I’ll say it again: “functional back” and “now functional.” It’s going to take, like, three minutes for it to become active one more time. So pretty much, we covered everything under this tab with the backup, the heartbeat configuration, the link and path monitoring, and the operation command. So that should take care of this. We’re going to talk about active and passive in the following lecture.
6. Active Active High availability intro, Floating IP
So in this lecture, we’ll talk about the fundamentals of active functionality in the Palo Alto Firewall. So, active firewall functionality allows you to have two firewalls processing traffic at the same time. In a previous lecture, sure, we talked about the “Ha One” interface that’s used to synchronise configuration, user ID, and other features, and then “Ha Two,” which is used to synchronise sessions. In the case of an active firewall, you have another interface called Ha Three. And H A Three is used to send traffic between the two firewalls when they are an active pair, and we will see how this is done. So you have active primary, active primary, and active secondary in the active. And we have the concepts of session owner, ownership, and session setup. In active sessions, the session owner can be either the active primary or the device that received the first packet of the session. And this device is responsible for alllayer seven processing, content ID, app ID, threat scanning, and so on. So this is the session owner. The Session Setup device is responsible for layer 2 through layer 4 processing.
And the Session Setup device is determined by setting up the Session Setup load sharing option. And we’re going to see how to configure it so that the separation between the session owner and session setup is in place to ensure that there’s no racing condition between the two firewalls, meaning that the two firewalls would fight over who’s handling the processing of the traffic. So all packet forwarding between the two devices goes through the Ha-3 link. It’s also noted that if the active state fails and the firewall fails over to the other side and this firewall is not available, all traffic that was handled by the session owner that moves to the session setup firewall would only get layers two through four. They will not be able to access layers seven and eight, which contain the content, app ID, and thread scanning. So existing sessions, if they failover to the firewall and the owner firewall goes out of service, the actual firewall that takes over the traffic would not be able to handle the layer seven processing, the content ID, app ID, and threat scanning. Those devices are in a cluster, and you designate a device of priority, Device Zero, and Device One. Device Zero is the active primary.
Device one is the active secondary. so you can configure load sharing. When you configure load sharing, one firewall becomes the session owner and the other becomes the session setup device, or one firewall becomes both the session owner and the session setup device. So if I have two firewalls here and I configure load sharing, one firewall would be the session owner, and this could be configured to be the firewall that has received the first packet. And then you have the session setup device. So you could have a situation where traffic comes in from a host to the active primary firewall. And this firewall becomes the session owner, determining based on the load sharing that the session setup needs to be handled by the other firewall. So it’s going to send the traffic to the opposite firewall for processing and setting up the session. And the traffic would make a return back to the session owner for layer seven processing, and the traffic would exit out.
The session owner gets the packet back, and the session setup function is done on the secondary active secondary firewall. In the case of asymmetric traffic flow, suppose the traffic goes out one firewall, gets out, and then returns to the other firewall. The firewall that receives the packet would check to see who’s the session owner, and it would send that traffic back to the session owner. So this could be handy in an asymmetric flow situation where you could potentially have traffic going out to one firewall and returning to the other firewall. In virtual wire, you can set the active state. In virtual wire, however, it may result in a spanning tree loop. It is not recommended to configure it in virtual wire, but rather in layer 3. This way, you don’t have a spanning tree loop situation. If you have two firewalls on the same length segment on both sides, a switching loop can occur if they are configured in virtual wire. In layer 3 mode, the firewall can be configured using one of two methods: floating IP or autoflow sharing. In the case of floating IP, you have the two firewalls, and each file has If we give an example here, this is the Ha triangle, and the firewall would have an IP address, a physical IP address, and a floating IP address.
So here, for example, I can have the physical IP address 1124, here the physical IP tenancy 1224, and then I have a virtual IP. And the virtual IP This could be used as a method of having Some devices, for example, would have their IP address default gateway pointing at ten one five, while others would have their default gateway pointing at ten one six. As a result, those devices will have this as their session order, and traffic will be routed from one device to another in this manner. This way, both firewalls are active, and the outside interface can have the same configuration: a physical IP and a virtual IP. And the traffic that gets forwarded returns back to the same firewall. If that firewall fails, the virtual IP will be carried over to the standby firewall. So in that event, the traffic would still get forwarded, but it would get forwarded to the active secondary firewall. So that’s also the failure scenario with the floating IP, which would move over to the other firewall. So this is one way of doing load sharing using Layer 3 and floating IP, and the other method is RPM. What you’re.
7. Active Active with Floating IP configuration example
So in this lecture, we will see how to configure an example to kind of explain this active setup that will show us the floating IP in action. So, in this case, we have two firewalls that we want to configure as active-active. And what will happen is that we want to have some users use this firewall and some users use another firewall. The interfaces on the trust side are configured for the physical IP 168, one two, and the virtual IPs, floating IP 182, 68, one dot five, and floating IP 182-1681, dot six. Then, on the untrust side, we want a physical IP and a floating IP of 1 when this traffic exits. So let’s say you have those two firewalls and you want to forward some users through one firewall and other users through another file. The easiest way to get this done is to convert a floating IP. And with the floating IP, you point some users to this gateway as their default gateway, and some users to this as their default gateway. This is one of six. So traffic that goes out of this firewall has been added using this floating IP.
Traffic that exits this firewall will be added using this floating IP. The nice thing about this is that if this firewall fails, the traffic is routed through the second firewall. The reason why is that the floating IP would move from the primary to the secondary firewall. If this firewall fails, one five will switch to this guy, and 1615 will switch to this. So there will be none; it will be seamless to the devices, and you will essentially use both firewalls as active and benefiting from your hardware rather than sitting idle doing nothing. We’re going to make the session owner and session setup belong to the firewall that received the first packet in order to avoid having traffic go across the Ha-3 link. As a result, we avoid forwarding traffic between the Ho-3 first packet. So if this file is the default gateway for devices with their IPS, one nine two and 68 one five, and this one is for IP addresses with devices that have their default gateway, one six, then the traffic will be basically handled by each firewall.
We don’t want to send session settings up to the other firewall; we just want to basically maintain the traffic over to the firewall that receives the first packet of the session. So let’s see how to configure that. So we have two firewalls configured here: one for the outside interface, one for the outside router, and one for the inside router. And I have Ethernet 1 and 2 marked as trusted, while Ethernet 1 is marked as untrusted, and we’re going to configure the IP addresses we specified to use Active. You basically enable Ha, create the group, and specify that it is an active group with a single IP address. We’re going to use the same IP address scheme we used in the other lectures. So I’m going to breeze through this setup, and we need to go back here and configure the interfaces for Ha. So in my case, I’m going to be using one eight and one nine for H A one and H A two.
So ho one is equal to one eight. Ethernet 17 is going to be used for Ha 3. So we’ll configure all those three interfaces for Ha. Ethernet 19 eight will be Ha. Ethernet is going to be ha-ha-ha, and I’m going to bring the interfaces up. And then, under high availability I’m going to go back here and configure the Ha 1 interface, which is Ethernet 1-9, and give it an IP address, and then configure Ha 2. And then under the active configuration, I’m going to specify that the interface for port H3 is Ethernet. This is virtual synchronization, if you want to synchronise the virtual router for dynamic routing and QS synchronization. And then we’re going to specify here that the session owner is going to be the first packet, and the session setup is going to be the first packet as well to make sure that we don’t force traffic unnecessarily across the HDR three-link.
And then we’re going to go under network, configure the Ethernet one, clear three, and go to screen zone. The default screen zone contrast IP address is going to be the physical IP one, one, two, and three. So this one is going to be two and bring the interface up, and then we’re going to create a default route to forward the traffic to the next top router, which is one one one.Okay, we can add the virtual address; that’s the floating IP. So, for Ethernet 1, we’ll have a floating IP of 1, 5, which will be owned by the device priority zero. Device zero is this device’s active primary. Device one is the active secondary. This will be preferred on the active primary with the highest priority, and the secondary will be ten. This is active with a lower priority, and the standby, or not the standby, is in the secondary with the backup for the floating IP.
This way, one would stay on firewall one, and then we can add one; the floating IP and device zero priority are 110 for device one. This way, device one is going to be the owner of the floating IP number six. So that was one of the six. Then, on the inside, we’ll select Internet One and Two and create virtual addresses for them, which will be the primary on device zero and the secondary on device one. Oh, sorry, the opposite and six: it’s going to be primary on device one and secondary on device zero. This firewall, the active primary, would own one five, the active secondary would own one six and one eight two, and the inside would own 61 five and one six. So this way I can send traffic to one five.
Some devices would have the default gateway as one of the five going out this router, and some devices would have that as the default gateway sending it out this router. So let’s synchronise this configuration, and we’ll show you the net. And we’re going to do the same thing here on this device. We’re going to configure HAGR group one; this is Active; and this is device one, the IP address of the primary HAGR device one. We’re going to change the interfaces, making devices highly available. We’ll confer the ho one and ho two before going active. Active. We’re going to specify the Ha Three interface looking at synchronize, and then the owner session set up is going to be the first packet, and then we’re going to commit this. We returned to the primary firewall after we committed to it. Right now it doesn’t see it; it sees that it’s the active primary and the peer is unknown because we didn’t have it configured yet.
But it should be appearing now, synchronising with Peter. Okay, so it’s waiting for hold time, but right now they’re synchronized, and you’ll notice something on the active standby of the active secondary: it didn’t configure the IP addresses for you. The reason why is that you have to have a separate IP address (a physical IP address) on each firewall. So we’re going to go ahead and configure that. It configured the zone and the virtual router but left the IP field empty. So we’re going to configure it, along with the virtual order and the zone, and we’ll put the IP address here. And if we go back and look at the few, keep in mind that we didn’t set the device priority to Active. It did it for us because this configuration is going to be shared by both devices. So from now on, you configure the firewall under “Active Primary,” and basically the configuration will carry over to “Active Secondary.” And now it’s finally synchronized. We have it correctly configured with the floating static IP, and the next step is to forward the traffic for the net to go out each firewall. So we want the traffic that goes out of this firewall to be netted to five and this firewall to be netted to six.
And we want to maintain that because we want traffic outbound to return from the same firewall, and we want to utilise both at the same time. So we’ll make an advertisement for Firewall One and specify trust for an untrusted translated packet. I’m going to translate dynamic IP import and interface IP address, interface Ethernet number one, floatingIP number one, and five under Active Active binding. We’re going to specify that this is bound to device zero. It means that it will always be translated to device zero. And then we’re going to go ahead and create an ad for firewall two, and we do both at the same time on the active primary. The active secondary is just going to basically receive its configuration from the active primary one six.And device 1 will be the active HR binding. So when traffic goes out, device zero is going to be another two on the list.
It will be the one six when traffic is directed to device one. Let me go ahead and commit. And now, to test that out, we will see what happens. I have an inside router and an outside router. I’m going to forget the default gateway on the inside router, go to one end (261-5), and then see what the session will show up on the outside router. And then I’m going to go to port 1 6 and point it to port 1 6 to see how the session works. So this is the inside router. It’s currently pointing to five. I’m going to ping one one.Okay, let me set up management profiles so I can pin them on the inside. It could have been that the synchronisation didn’t finish synchronising correctly. So I need to configure the IP addresses one more time here. That’s probably why it’s not working. I should have set up the management interface for this.
No, it’s set up here. So, it synchronised that. Let’s see if we can ping now. Okay, so I can ping both IPS; both are loading static IP. My default gateway is pointing to IP number five. So if I telnet to one, which is the outside router, I should be showing up. Well, I don’t realise the issue here. The policy’s security policy is not configured, so nothing is going to go through. As a result, we must include a security policy source trust destination trust allow click. Okay, commit. Now I should be able to terminate. So if I turn that to 1, it should be coming from IP address one five.And if I change my default route to be the other router, the other firewall will make it appear as the default gateway. So now it should be going out the firewall, and I should be coming in from six. Okay, so one caveat to this is this: Both firewalls need to be in the same segment, inside and outside. But that’s pretty easy if your goal is to have both firewalls active at the same time and have them both utilised for your internet traffic.
8. Active Active session owner, session setup using IP modulus, failover example
In this lecture, we will talk about some additional information relating to high availability. Active active. In the previous lecture, we set up virtual floating IP addresses to be used, and traffic could be pointed to each virtual IP address. This way, you can utilise both of your firewalls and keep them both active. And for the traffic here, you can show a high-availability virtual address. It will show you which IP addresses are handled by which appliance. I’m on the active primary right now; one of the five is active on the primary (active primary), and the other six are not active on the active primary (268).
Under the network configuration, one five is also active on the active primary under the device high availability. We have it configured so that the first packet contains the session owner selection and the session setup selection. So we’ll talk about the different options there. So the other option that is available is to have the session owner be the primary device. and we’ll see what happens. When you select the session owner as the primary device, you have to make this selection on both firewalls, and we go here on the active secondary and we make it the primary device. And, now that the session owner is the primary device, we’ll see how this affects things. So even though I have my inside router here pointing to one A 268, I’m going to point it to one A 268.
The secondary firewall is number six. It’s pointing to that right now. If I tune that to the outside router, you will see what the outcome of my session is going to be. It might be still synchronizing; it’s still in the synchronisation process. And if I do show users the IP address that I’m going to see, even though I’m pointed at the secondary firewall, the IP address that I’m going to see is the IP address of the primary firewall. Why? Because when you configure active primary, you are actually configuring the firewalls to be active passive. That’s basically the outcome of making the session owner the active primary. So in the case of pointing the active primary and saying my session owner will be the active primary, what happens is the traffic will get to the secondary firewall, and the secondary firewall will say, basically, “I’m going to forward that traffic across to the Ho 3 link, and it’s going to go out the firewall that is the active primary.”
As a result, you have an active passive setup, which does not benefit from your active primary setup, and there will be additional overhead because traffic must cross the Ha three link to reach the session owner, who is the active primary. So that’s not a recommended setup because you won’t be able to tell the difference between active active and active passive. We’ll go back and switch that up to be the active first packet and get the session set up. We had it set up in his lecture as the first packet. Now we’re going to choose IP modulo for both. So what happens when you specify an IP model is that the session setup load will be shared amongst the two firewalls based on the IP addresses that are coming in. Based on the packets of IP addresses that are coming in, The session setup function basically does layers two through four, processing layer seven, which is app ID, thread ID, and content ID, which will be handled by the firewall, which is the session owner. So this session is set up, and this is the session owner.
Okay? So if I have that session set up to be based on hash, what happens is that the traffic that’s coming in, if my traffic comes into the secondary file, for example, it’s going to look at the module of the IP packet and it’s going to say, “Okay, I’m going to have this function go to the active firewall,” and then the other one is going to handle it itself, and vice versa. So that load of sharing the session setup function will be shared across the two firewalls, which, in my opinion, I don’t see a whole lot of benefits from doing because I’d like to have the session set up and the session owner be on the same firewall. So let’s try that out. So I’m going to exit out of that session that I created. So right now, the session owner is the Ipmojulo. So if I’m going to turn that to one and now my IP address is probably still on hold as the change occurred, it’s going to put itself on hold. So let’s get this show session started. And if we look at that session, we do show session ID 2. We will see here that the session owner is the active device. There is no session setup locally. So the session setup is locally set up, but in that case, it’s going to take that net IP address from the session owner. So the net information gets processed by the session owner. So to enable this to work because the traffic bounces back between two firewalls for session setup, So, in my case, my router is sending traffic to one six, and based on the IP modulo this firewall, the active secondary determined that the session setup function must be performed by the active firewall.
So traffic goes across and then comes back to get processed here for the session ownership. So that traffic going around is typically blocked by the firewall because it typically blocks asymmetric traffic. So the symmetric traffic is caused by traffic entering one interface and then exiting another and leaving the firewall. So it comes in on this interface, but then it also comes in on this interface. So that’s the reason why if you don’t have TCP symmetric settings enabled, that setup is not going to work. So you’ll need to go to the CLI on each of the firewalls, then configure, and then TCP device configuration System TCPsettings TCP, and then asymmetric path bypass. As a result, when traffic arrives asymmetrically, it will be dropped by default. You need to allow it for that session to pass through. One of the reasons I don’t like to have active with the session setup function going across is that you have to enable asymmetric routing, which breaks the logic of ensuring that the firewall doesn’t allow traffic that shouldn’t be allowed. I’m going to do the same thing on the secondary firewall active secondary device configuration system, so now that that’s done, I’m going to go ahead and commit. So on my inside router,
I’m going to go ahead, and then I’m pointing to the secondary firewall. So I’ll take that outside to show users and traffic. The session owner is the active secondary because I’m pointing at the active secondary, so I should be added to six, but the session setup might be different. So we have to look at the actual firewall and then show all sessions. And then here we see that there’s an active session. It lets the session go through. If you do show session ID five, we see here that the session owner is this device because we set up the high availability to have the session owner be the first packet. So the first packet arrives at the active secondary, so that’s the session owner. However, that doesn’t guarantee that this device is the one for which the session is set up. So the session setup is not local. The session setup is done on the active primary, so that’s why the traffic is going across the firewall and causing an asymmetric issue for connectivity. And then we see that the net rule is also the network firewall, because the traffic will exit from the decision owner; it will not exit from the other device; it will exit from the session owner. So let’s point our default gateway to 501 1st. Before you do that, what does the session show on the active firewall? So show all sessions; there is no active session. There’s no active session. Let me restart that session. Okay?
So show session everyone. I have it active on the secondary. Let’s see if that session is also in the primary. It’s also present in the primary array, but with a different session ID. So here’s session seven, and here’s session eight. So what happens if I turn off the standby firewall, the secondary firewall? Let’s see what happens. Go here and turn it off, and let’s see if my session is maintained. So it may take some time because it is sort of failovering the floating IP, but my session is still active. But if we look at the actual session, layer 7 processing is not going to be done on this firewall because it’s not the session owner. It took over the session, but it’s not the session order. That’s why you see layer seven processing completed because that was already done by the active secondary, which no longer exists. So the nice thing about the active primary and active secondary is that you have failover capability, but there’s a caveat in that the layer seven processing is basically broken when the session owner disappears and the other firewall picks up the traffic. So let’s bring it back to the firewall.
So the firewall is back up. I’m going to go ahead right now and change my default gateway to the firewall one. So let’s do that again and see what IP address we can get. All right, so show session all. I have a session here, but if we look here, which shows session all and session ID two, we will see that it’s not the session owner. Because I’m on the active list right now, I’m still tentative. So let’s give it time for it to come up. You can see that it says tentative here. My sessions should be on the active primary because my default gateway is pointing to the floating ID of the primary. So show session nine; show session all. So because Oz’s secondary is not in service yet, decision setup is done on the active primary, but that doesn’t necessarily mean that it’s going to stay the active primary once the active secondary comes up. So it should take like 50 seconds.
Now it’s ready, so you start the session again. Okay, so now that the active secondary is back up, let’s see what happens: it still didn’t do the session, it still didn’t give the session set up for that firewall, but it’s based on the IP hash, so it might not give that functionality to the other firewall that has a session owner and a session set up. However, we previously observed that the session setup was going across, resulting in the session being unable to establish at all. The reason why is the asymmetric routing. So you have to do the asymmetric routing bypass on the firewall, and in this case, let’s point it back and see the Ha 3 traffic. So if we monitor and capture the HJ-3 interface right now, I don’t have any traffic going across, but if I point my IP route back to the secondary firewall, we should see the traffic going across. However, the traffic is encrypted. So we’re not going to be able to tell what’s going on or what type of information is in there. And we see that here. So we see the issue in three directions:
And this is a proprietary Ethernet protocol. And that’s one. Of the reasons why the two active primary and active secondary firewalls have to have a layer-two connection between the two locations, it also has to have support for jumbo frames because there is encapsulation involved. On that layer two link between ho three, jumbo frames are required. So, if you have two firewalls in two different datacenters and want active functionality with traffic crossing the ho three lane, you must ensure that the layer two network supports jumbo frames, and layer two cannot be layer three.
9. Active Active Static Nat Configuration Example using NAT HA binding Primary
In this lecture, we will see how to create a static network with the active-active setup. So, from the active primary or active secondary, we’ll create a static net to netone one and map it to an internal IP address of 18216, 8111. So we can create the source static net. And there’s something called net binding. We saw this before when we did Ha binding. We saw this earlier when you used dynamicnet for internal traffic. Now we’re going to do a static net for traffic coming in from the inside out or from the outside in, bi-directionally. So we’ll see. So we’ll do a static net. Example: I have a host here on the internal network, and this host is going to be serving public services to the outside world, and they’re going to be added one by one to oneone.
And, because I have active primary and active secondary, I have two options: point to the floating static IP address as the default route or point to the interface’s physical IP address. So if I point to the physical IP address of the interface for my static route default route, when this firewall goes down to this IP address, the host will not be reachable anymore. So the best way to do it is to point it to the floating IP. As a result, when the floating IP is set as the default from your server’s public host, it will be one of the five walls. In our case, the floating IP Here are numbers 5 and 6. We’re going to make it the default gateway on Five. In addition, traffic from 168 to 111 will be netted to one, and traffic from 111 will have a destination added to eleven. So, when you do the net binding, you can add to device zero, device one, or both the net and the device as your binding is both, and it will be advertised on both sides.
But the issue with that is you’re going to have an ARP conflict because both firewalls will ARP for one another. So this is one way of doing it. You can specify both, or you can specify the primary. Okay, so when the firewall is active primary, this is active primary, and this is active secondary. When the active primary firewall goes down, the active secondary will take over. Both the static network that you have created and the one IP address will move here, just like the floating IP will move here. So this is the best approach to doing this. So let’s see this in the lab. Well, here’s the diagram. I have a network host here, and this is going to point to the floating static IP of firewall one. And then I’m going to source-net this address to one, and I’m going to tie it into the active primary. This is due to my static artist pointing to Firewall One’s floating IP. The active primary would be the one that’s responsible for the net.
So we’ll go ahead and create a net entry. This net device will be referred to as source netr and primary. It’s bound to primary. So here we’re going to specify the source of trust. The destination is untrusted, and the source address is 168.1.1.32. It will then perform a static IP, and we will specify the IP address here, which is 168.1.1.32. You don’t need to specify 32 here; bidirectional is sufficient, and the active active binding is the primary. Okay, so you can specify both, which means it will be available on both; only see a scenario in a future lecture. When does it make sense to have it available on both? That will be seen in a future lecturer primary or linked to device zero one. In our case, we’re going to specify that this is for the primary since this traffic-dynamic network will be matched first. So we’ll move this up and then commit it to the router that I’ll be netting show IP to. My default gateway is 1, which is the floating IP of the active primary. The net was completed. So now let’s take a look and go outside to see what my public IP address is. and it should be 111. There you go. Let’s go ahead and see that session.
All we see here is the session, and we have session ID 396. We see that the session order and session setup, since we set them up for the first package, are going to be on the active primary, and traffic is getting netted and matching the correct netting policy, which is source net router. and that’s from the inside out. Let’s look at it from the outside in. So from outside, I’m going to connect to the outside router and turn it to 111. It should be coming in from one to one. And if I look at the session show session, all I see is the session here from the outside, one going into 111, translated to 168, with one session owner and the session set up in its first packet by me setting it up this way. The active primary will always be responsible for this network and the floating IP address of the firewall. One is always going to be the default gateway for this route. If the device or question that you do in public services for this hosting to the outside is not directly behind the firewall, you can take a policy-based approach. the traffic through your routers to the address of Firewall One’s floating IP address So what happens if we shut down Power One? We shut it down. Let’s take a look at the secondary, and the session should migrate over.
Why is it going to migrate over? because once the active primary goes down, who becomes the primary? The secondary will become the primary. You see here that the secondary firewall became active and the floating IP moved. So my static router still has a connection. I still have a session from my inside host that’s publicly netted, and I still have a session from the outside host that’s connected to the public host. So I didn’t lose anything by doing that. That’s the advantage of tying it into the device, the primary firewall, and then pointing the public host to the primary firewall’s actual floating IP. I’m going to go ahead and start this backup. Once the active primary file returns, it’s going to preempt and take over, and the traffic is going to get sent using the active primary file. If you are in two separate data centers, the oculus texture may require a three-layer aslayer two between the two firewalls, and then the outsideland must be common across the two data centers, as we will see. If the outside land is not common, we will see this in a future lecture.
10. Active Active High Availability Arp Load Sharing Configuration Example
This lecture will cover active participation in R flow sharing. In this example, the two firewalls and Active are set up. Furthermore, we will use the Art floor sharing feature to load balance traffic between the two firewalls. So, what is our contribution? Our flow sharing relies on the firewalls responding individually to each specific request. This is also based on appi modulo. What IP Mojolo does is look at the parity of the IP address of the requester. Parity means it’s odd or even, right? So, if my IP address is 1, then This is four even, for example.
Okay? If my address is 2, this is 1235; that’s odd. So if it’s odd, it’s going to go to firewall 1. Firewall would respond to the art request. If it’s even, firewall two would respond to the art request. So if I have traffic coming in from the outside, is there a device here that wants to talk to an IP address that is netted based on the IP address? If my IP address is odd, my app request would be responded to by firewall one or firewall zero. If my IP address is even, the request would be fulfilled by the second firewall, and this would result in the traffic coming in and getting distributed across the two firewalls. So the way this is typically done is that you have to have the devices that are making the request on the same broadcast network, right? So, typically, you’ll have an F-5 load balancer, and the F-5 load balancer will have odd, uneven IP addresses, and when it sends a request, Firewall 1 will respond to the odd IP address of the F-5 load balancer. Firewall two will respond to the IP address of even. expanding on that here.
So if I’m a company, right, and I have F5, and I have multiple data circuits coming in or multiple connections coming in, and I have an F5 load balancer that receives the request, the F5 load balancer would initiate a connection based on my request. The odd F-5 would be pointing to the IP address that Firewall 1, the primary firewall, would respond to, and even one would be responded to by the even firewall. So that’s kind of an example of how this would be done, right? This type of scenario relies on the destination network for it to work. So in my previous case, when we didn’t, we source-netted it to 122, but we will go ahead and change this net to a destination net, and that’s how we can do this. And then I’m going to do a destination net on both firewalls. That destination net would say that if you requested 133, this would be an ARP load-sharing IP address. So, based on the ARP requester, the appropriate firewall would respond and then do that destination at that IP address to the public resource, which is one nine two one. So under device size, high availability, and ActiveActive, we’re going to create a new virtual address, and we’re going to specify the outside interface for that virtual address. And then here we’re going to add an IP address, and this IP address will be 1133, and this is ARP load sharing.
Okay? And the ARP response would be based on either IP modulo or IP hash. The IP modulo looks at the IP address of the requester, and if it’s odd, the request is going to be fulfilled by Firewall Zero, even if the request is going to be fulfilled by Firewall One. So we’ll add this one, and basically, as an Rflow cherry, we need to add it here under Ethernet. We need to do it in the active primary. That’s where all your changes are, 133, and we’ll go ahead and commit. The configuration should see it on the other firewall. Okay, so we have the Arc loadsharing for one or three three.Now we need to create a destination network. So we’ll add it here. According to Arthur originalpacket, any destination is untrustworthy. And then the translated packet that will be the destination address will be 133, and the destination translated address will be 18216 eight one, the IP address of the public host, and then active active binding will be both and then click.
Okay, so let’s see if that’s going to conflict with anything else. Any untrust should not cause conflict. We’ll go ahead and commit and commit.So I’m going to ping that address and see what the firewall response shows as IPR. According to my IP address, the request was most likely fulfilled by Fire One. The issues the Mac addresses are the same on this and on the VM, so we cannot really prove that out. But that’s the idea: our load sharing enables you to load share requests based on our requests across the two firewalls, allowing you to have both firewalls active and responding to requests for that traffic here. Let’s say firewall. One response, firewall; two responses My default gateway is Firewall 1. So the traffic will go through that link, the Ha-3 link, which is one disadvantage of that method sharing: the traffic may occasionally cross the HS-3 lane, which requires you to enable the Asymmetric Crowd feature.
I tried to explain to her that it was most likely not working because the asymmetric path was not enabled. So let me enable Asymmetric Path device configuration because TCP timed out because Asymmetric Path is not enabled. Bypass Asymmetric Path and we’ll do the same thing on the other one. Set device configuration; set device configuration: TCP asymmetric bypass; bypass; now try it again. There we go, because potentially the traffic is going to go across the HOA Three Link. My default gateway for this router is Firewall One, the floating static IP. The traffic can come in on Firewall 2, and then it’s going to cross over to Ho 3 and come back this way. That’s why you require an asymmetric path to be bypassed. That’s why I don’t like this option. I prefer to nail my traffic to either one firewall or the other, but not both. But that’s an option for you to use. which is our flow chair.
