Hello,
Grant Taylor a écrit :
On 11/06/07 11:03, Martijn Lievaart wrote:
This is expected. A nat mapping is set up on the first packet of a
"connection" and a reverse NAT is done automagically on all return
packets. Exactly what you are seeing.
I'll agree to the NATing part.
So do I. Otherwise, stateful NAT would not work very well.
However the fact that the OP is
successfully using the loopback interface surprises me. It was my
(mis)understanding that the loopback interface was holly and would not
talk to traffic that did not originate or terminate on the loopback
interface as well.
You may confuse with the restriction from some RFCs stating that
127.0.0.0/8 addresses are reserved for internal host use, i.e. the
loopback interface. There is no such restriction for other addresses
that may be configured on the loopback interface. Also, the Linux IP
stack follows the "weak" model by default, so any unicast address
(except 127.0.0.0/8) configured on any interface can be used for
communications on any other interface. So any non-127.0.0.0/8 address
configured on the loopback interface can be used for communications on
any other interface.
Or is the a side effect that the NATing code is
sending the traffic out the loopback interface destined to the loopback
interface as well, thus NATing is bridging the security barrier? I am
almost positive that the same could not be done with routing.
Nope, NAT has nothing to do with this, and the loopback interface is not
involved.
This cannot easily be solved with current Linux kernels. Current
kernels only do connection oriented NAT. You could insert a Cisco
device or something similar to do the kind of NAT you require.
Would it be possible to use stateless NATing via IP Route 2 rather than
IPTables to achieve this?
The old stateless NAT in the routing code controlled with iproute2 is
considered broken and all references to it were removed from kernel
2.6.9. But a new stateless NAT is coming with the next kernel release
2.6.24.
For now, an ugly workaround may be to use the NOTRACK target in the
'raw' table on the (supposedly) return packets, to skip the connection
tracking and the automagic reverse DNAT. I think this will work for DNS
over UDP, maybe not so well for TCP.
-
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
