Firewall destination address translation and source address translation

Encountered a firewall failure, and have a further understanding of the working principle of the firewall and the destination address translation and source address translation, which are recorded here.

The result said in the front
The network structure is very simple: external network-firewall-intranet.There is a website on the intranet, and the domain name is used to access it on the extranet.The machines in the intranet need to access the extranet, and also need to use the domain name to visit each other.In this case, the address translation rules should be configured like this:

To access the internal network from the external network, only the destination address translation needs to be performed, and the source address translation is not required.

When accessing the intranet through a domain name, in addition to destination address translation, source address translation must also be performed.

The first item above has an "exceptional" situation, that is, the gateway configuration is incorrect. For example, we encountered: Intranet 6 has 2 network cards, both of which are configured with the intranet address of the same network segment, and each network cardBoth have gateways configured.Since they are on the same network segment, the two gateways are the same.In this case, source address translation must also be performed for external network access, otherwise the internal network can receive the request, but the processing result cannot be returned to the external network, and the result seen by the external network is no response.

The principle of firewall packet conversion and transmission
Why is this happening?This starts with the principle of firewall.The above external network accesses the internal network, the normal processing process should be like this:

The firewall receives the external network access request data packet, and the format contains [firewall external network IP external network user IP]

The firewall performs target address translation, and the data packet becomes [intranet IP, extranet user IP]

The intranet server receives the request, processes it, and returns the result data packet [external network user IP intranet IP]. Since the destination address is the external network IP, all routes are routed, and this data packet is sent to the gateway (firewall)

For the returned data packet, the firewall does the inverse operation of the target address translation, and the data packet becomes [external network user IP firewall external network IP]

The packet is sent back to the requesting user.

In the case of "exception" just mentioned, the problem lies in step 3. In the result packet returned by the intranet server, the intranet IP is not the IP pointed by the firewall, but another IP address of the intranet server., that is to say, the intranet server accepts the request through network card 1, but sends return data from network card 2.After such a data packet reaches the firewall, the inverse operation of the target address translation will fail (the intranet IP is inconsistent), so the data will still be sent to the user through the firewall, but it is a new TCP session/connection, which cannot be requested by the original user.package corresponds.The result is that a new data packet arrives at the user, and the user does not know who it is for, and the user's original request has never been "received" in response to the data packet.The external manifestation is that the user sees that the request was sent successfully, but there is no response.

In this case, if the source address translation is done at the same time, the process is as follows:

The firewall receives the external network access request data packet, and the format contains [firewall external network IP external network user IP]

The firewall performs destination address translation, and the data packet becomes [intranet IP, external network user IP], and performs source address translation, and the data packet becomes [intranet IP firewall/gateway IP]

The intranet server receives the request, processes it, and returns the result packet [Firewall/Gateway IP Intranet IP]. Since the destination address is still the firewall/gateway IP, the firewall can find the corresponding connection, and will accept the packet andto be processed.

For the return data packet, the firewall does the inverse operation of the source address translation, the data packet becomes [External network user IP Intranet IP], and does the inverse operation of the destination address translation, the data packet becomes [External network user IP outside the firewall]Network IP]

The packet is sent back to the requesting user.

It can be seen that even if the operation fails, since the firewall has already matched the data packet returned by the intranet server with the connection request of the external network user received by the firewall successfully, the destination address of the resulting data packet has also been successfully converted into the IP of the external network user, soThe data can be successfully sent back to the requesting user and corresponds to the user requesting session/connection.

From another point of view, although bidirectional address translation is feasible for external network access, it has a disadvantage that when the data packet reaches the internal network server, the external network user IP is converted into the firewall/gateway IP, so that the internal networkThe application cannot obtain the real IP of the external network user, and can only see that the request comes from the firewall/gateway IP.

Accessing the intranet through the domain name of the intranet
After understanding the above, it becomes clear why the intranet must do a two-way conversion to access the intranet through the domain name.The problem also occurs when the server that accepts the request finishes processing and sends the return packet.

Intranet 1 accesses intranet 6 through a domain name, without source address translation:

Because it is accessed through a domain name, the request data is forwarded to the intranet 6 through the firewall, and the user IP is the intranet address (this is the key)

Intranet 6 sends the result data packet after processing, and the destination address of the returned data packet is the address of intranet 1. Since it is in the same subnet, the data packet will be sent directly to intranet 1 through the switch, but the firewall

The problem arises. On Intranet 1, the request data is sent directly to the firewall, and the returned data is directly from Intranet 6, which does not correspond. It is another case of no response data packets.

If source address translation is done at the same time, the problem can be solved.Because when the request data of intranet 1 passes through the firewall, the user address (intranet 1 IP) will be converted into the firewall/gateway IP, and the returned data packet will also be sent to the firewall/gateway IP, and then converted by the firewall and sent back to the intranet1. There is no direct dialogue between Intranet 1 and Intranet 6, and the TCP data packets can also correspond, so there is no problem in accessing.

The working mechanism of different brands and types of firewalls may be different, but the principles are similar.In unprofessional places, please pass by the immortals generously.