Building a fault-tolerant firewall system with virtual machines: Routing


(0 comments)

Routing is an interesting and important issue. Not only smoothing traffic, routing work also determines the path of a packet so that the correct packet filtering can be performed.
We start from the client. There are two ways out from the client, so which way to go?


192.168.2.1 on the firewall machine fw-1 cannot be set as the client's default gateway, as such the firewall machine fw-2 is completely disabled. Likewise, the firewall machine fw-2's 192.168.2.2 cannot be used. The solution is to use the virtual IP address 192.168.2.100 generated by the HA system. From the point of view of the HA system, all four machines above are real machines. It generates virtual IP addresses for automatic routing. If the firewall machine fw-1 is the primary firewall, the address 192.168.2.100 will be added to fw-1's eth1 interface


So the client needs to create a route through the default gateway 192.168.2.100. You run this command:

sudo ip route add default proto static via 192.168.2.100 dev eth0


Traffic was clear. If the firewall fw-1 is down, the address 192.168.2.100 is assigned to the firewall fw-2's eth1 interface and the client always has a single logical route to get to the service it needs.

Network address translation
But the above only addresses the route in the client network, which is 192.168.2.0/24. Consider the routing table of the omarine server


Apparently the client network 192.168.2.0/24 is not present in the table. A connection originates from the client, when it reaches the omarine server it has no way back in bidirectional client/server negotiation. To fix it, we add a route as follows:

sudo ip route add 192.168.2.0/24 via 192.168.0.100 dev br0



Another approach is network address translation. Network address translation or NAT is a familiar concept. However, its application is situation-specific. NAT's job is simply to handle layer 3/4 protocol headers to modify the source/destination address usually for the purpose of making it possible for the packet to reach its destination. The commands below create the table nat on the firewall machine, add the chain postrouting to the table, and then handle packet going from the client to the omarine with a rule that changes the source address 192.168.2.3 to 192.168.0.100 as it goes out of the firewall from the eth0 interface

sudo nft add table inet nat
sudo nft add chain inet nat postrouting { type nat hook postrouting priority srcnat \; }
sudo nft add rule inet nat postrouting oifname eth0 ip saddr 192.168.2.3 snat ip to 192.168.0.100



The corresponding packet on the way back will return 192.168.0.100 instead of 192.168.2.3. The new destination 192.168.0.100 is obviously transparent to omarine's routing table. At the firewall's eth0 station, the NAT translates this destination again to 192.168.2.3 for the packet to return to the client.
Again, the entrance to the firewall system of a packet on the way back is the virtual IP address 192.168.0.100 and not the actual IP address of the eth0 interface of the firewall machines. It is a single, logical path through a road-fork firewall system that automatically chooses the route.

Currently unrated

Comments

There are currently no comments

New Comment

required

required (not published)

optional

required


What is 5 - 4?

required