Re: full_cone_nat

[Amos Jeffries <squid3@treenet.co.nz>]

Jan Engelhardt wrote:
> On Tuesday 2009-04-07 20:16, Jozsef Kadlecsik wrote:
>> On Tue, 7 Apr 2009, Hugo Miguel Mendes wrote:
>>
>>> What I mean with Full Cone NAT is the following:
>>> [...]
>> I answered you on Thu, 2 Apr 2009 when you asked the same question on
>> the netfilter mailing list. The answer hasn't changed since then: 
>> currently there's no way to create full cone NAT.
>>
>> It might be possible to write a new full cone NAT target by creating 
>> wildcard expectations.
> 
> Yeah there is a case where cone nat does not quite work. Assuming there
> are the following mappings:
> 
> origsrc=192.168.17.2 origdst=80.10.20.30 replsrc=134.98.76.54 repldst=80.10.20.30
> origsrc=192.168.17.3 origdst=80.20.30.40 replsrc=134.98.76.54 repldst=80.20.30.40
> 
> Then there is no way to ambiguously map incoming IP_CT_NEW connections
> for 134.98.76.54 to an origsrc.

You are right when IP-only tests are considered. The joy of full cone 
NAT requires ports to be added to that equation.

The NAT algorithm must be adapted to ensure every outbound 
src-ip:src-port combo sent to the Net is completely unique and replies 
from any ip to that particular sending port cone back to the unique 
internal machine that opened it.

For your case origsrc-ip:origdst-ip:origdst-port tuplets are different.

/2c

AYJ