Actual combat case: 90% of network engineers have encountered it! In the scenario of unequal paths, packets will be lost through the firewall. How to solve it?

Background

Recently, a certain enterprise has recently undergone a network transformation and needs to isolate the department's access rights to the private network and the public network, that is, "the R&D department uses a certain C firewall to access the R&D private network, and the office area can access the Internet, but it must be ensured that both can access each other." The topology is simplified as follows:

• R&D Department-VLAN10: The gateway is 192.168.10.2, which is the private network protection wall. It can access the R&D private network.
• Office area VLAN20: Gateway is 192.168.10.1, which is the core switch and can access the Internet
• The firewall is configured with static routing, and the next hop of destination VLAN 20 is given to the core

After deployment in the above manner, IT staff found that only the R&D department VLAN10 could access the office area VLAN20 but not vice versa. After investigation, they found that the reason was that the access paths were not equal and the firewall dropped the packet!

Problem Analysis

Those who have played with firewalls (hereinafter referred to as FWs) have more or less heard that FWs can lose packets due to unequal paths. What is the principle behind this? Let's take a look based on this topology.

First, check that VLAN10->VLAN20 is successful. The path is as follows:

It can be seen that the path from VLAN10 to VLAN20 is (PC2-FW-core SW-PC1), that is, ①②③④. After the ICMP Request sent by PC2 passes through the FW, a Session is generated and the packet is forwarded.

The reply path of VLAN20 is (PC2-Core SW-PC1), which is ⑤⑥. This ICMP Reply goes directly to the R&D department without passing through the firewall, and the round trip is successful.

Then see VLAN20->VLAN10 fails, the path is as follows:

The path for VLAN20 to access VLAN10 is ①②. The ICMP Request can be received by the R&D equipment without any problem. However, the reply path for VLAN20 is ③④. At this time, when the FW receives the ICMP Reply, it will check whether the Session status exists. The answer is no! Because no Request has been received.

After the session check, the FW discards the ICMP Reply. This is the principle of discarding packets with unequal paths in the FW networking scenario. The same is true for the TCP three-way handshake. I will not go into details here. So how to solve this problem?

Solution

The above analysis shows that the firewall drops packets based on the session state detection mechanism, which is the default "strict mode". The H3C firewall can achieve a similar loose effect by configuring the session state machine to "loose mode". The relevant commands are as follows:

 <H3C> system-view [H3C] session state-machine mode loose

Note: Enabling "loose mode" may bring certain security risks. It is recommended to configure it carefully according to the specific network environment and security requirements, and combine it with other security measures to ensure network security.