On Wednesday 07 of December 2011 18:57EN, Gáspár Lajos wrote:
> "A": the local router/gateway/firewall connected to the Internet and
> the LAN "B": a server on the LAN
> "C": a client on the same LAN or on the other side (Internet)
>
> If "C" connects from the Internet to a service on "A" (in reality the
> service is on "B") then everything is fine because I can DNAT the
> packets to "B"...
> But if "C" is in the LAN then the packets are simply disappearing...
They are not. If you monitor the LAN traffic, you should notice that the
problem is not the redirected packet but the reply from B to C. Because
B and C are in the same segment, the response goes directly to C (not
through A) and its source address isn't translated back. Thus C sends a
packet to A but gets response with source address of B (which it can't
recognize). There are three usual solutions to this problem:
1. Don't put services accessible from outside into LAN, create a DMZ and
put them there. Then the response will go through A and it will
translate its source address.
2. Make clients from LAN use the real address of B rather than A. This
is often done via views in BIND - you translate the name differently for
clients in LAN and for the rest of the world.
3. When translating the destination address from A to B for packets
coming from LAN, translate source address as well ("masquerade"). Then
the reply will go back to A and it will translate both source and
destination address. Awful? Definitely, but this is where all those
masquerades got us...
Michal Kubeček
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
