That in turn gives the gateway a chance to balance the effects of both DNAT and SNAT on the inbound packet by rewriting both source and destination addresses on the return packet.
The server then thinks the client is the gateway itself, and replies directly to it. The solution is that for packets which require such destination NAT, and which reach the gateway from the internal network, to also perform source NAT (SNAT) on the inbound packet, usually by rewriting the source address to be that of the gateway. It has no idea that the two packets are part of the same conversation, so no conversation happens. The client thus sends a packet to an external IP address, but gets a reply from an internal IP address. Since that reply is direct, it doesn't go via the gateway, which therefore never gets a chance to balance the effect of inbound destination NAT on the initial packet by rewriting the source address of the return packet. The server then receives a packet with an internal destination address (its own), and an internal source address (the client's) it knows it can reply directly to such an address, so it does so. The problem arises when the gateway device rewrites the destination address, but not the source address. It is this sharp about-turn the packet makes at the gateway that gives rise to the name hairpin NAT, by analogy with the hairpin turn. Their packet goes out from the client to the gateway device, which rewrites the destination address and immediately injects it back into the internal network. Internal users then try to access those services via the external address. This question applies to services provided by servers on RFC1918-addressed IPv4 networks, which are made available to external users by introducing destination NAT (DNAT) at the gateway. Since this has been elevated to be the canonical question on hairpin NAT, I thought it should probably have an answer that was more generally-valid than the currently-accepted one, which (though excellent) relates specifically to FreeBSD.
0 kommentar(er)
