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.
