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
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
