Re: Problem with DNAT of UDP packets getting undone

[Pascal Hambourg <pascal.mail@plouf.fr.eu.org>]

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.