Employing two DNS zones is a viable alternative, but not always the solution. It's about accessing a server placed behind NAT from both the Internet and the LAN. So permit me to summarize the solution here.įirst of all: forget about NAT (if you can) - the question is not at all about configuring NAT. Recently answered a similar question: Cisco static NAT not working on LAN side and just realized that this is a Canonical Question. external users, or by configuring the DNS server to respond differently according to the address of the requesting client.
The best is split-horizon DNS, where your organisation serves different answers for the original lookup depending on where the requesting client is, either by having different physical servers for internal vs. All such discussions are outside the scope of this answer.īut as others have said, properly-enabling hairpin NAT isn't the best way to handle the problem. Note that such rules need to be in the right place in the relevant chains in order to work properly, and depending on settings in the filter chain, additional rules may be needed to permit the NATted traffic to flow. But to enable hairpin NAT, one would also need a rule such as: iptables -t nat -A POSTROUTING -d 192.168.3.11 -p tcp -dport 80 -j MASQUERADE Which will enable simple DNAT for the HTTP port, to an internal server on 192.168.3.11. Linux uses iptables to do the DNAT thus: iptables -t nat -A PREROUTING -p tcp -dport 80 -j DNAT -to-destination 192.168.3.11 Proper networking devices can generally be told to work, but - because they are not in the business of second-guessing their admins - they do have to be told do so. A discussion of which consumer-grade devices are which is off-topic for Server Fault. Others aren't, and so won't, and it is unlikely that they can be made to work.
Some consumer gateway devices are bright enough to recognise those packets for which the second NAT step is needed, and those will probably work out-of-the-box in a hairpin NAT scenario. The server thinks it's talking to the gateway device. The client thinks it's talking to an external server. 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)
