On Thursday 2010-10-07 02:13, Amos Jeffries wrote: >> >>> - NAT, even if NAT66, still interferes with ETE connectivity. Think >>> FTP-SSL connections. That may not be your problem, but it's the Working >>> Group's and the Draft's. >> >> Yes - there are protocols that rely on addresses such as SIP, active FTP >> etc. >> I don't plan to add NAT helpers for them, thats pointless somehow. > >FWIW: FTP EPSV/EPRT extensions remove the need for layer-7 IPs and work >with NAT44 and NAT66 nicely where the firewall supports them. Yeah but if both sides are behind NAT, all bets are off with encrypted connections. >NAT66 is designed to work stateless AFAICT. As such the mapping likely >does not need conntrack at all. It does not /need/ it. But it interferes with it, given that conntrack runs before mangle and thus sees received packet with their original contents (2001:db8:1::<->2002:db8:1)), but locally originating packets with (fefe:babe:1::<->2001:db8:1::). >Is there perhapse some way to only configure the map once but have it >apply to both src and dst depending on the packet direction? No, for the following reason(s). conntrack first has to figure out the direction of the flow too, by looking at src/dst and comparing it with a table of known connections. So if you wanted MAP66 to be a single rule too, you would have to make MAP66 stateful at the very least. Let alone there is, with the exception of the FORWARD chain, no place that is entered by both receiving and sending side. Even nf_nat's DNAT, which is normally only usable in PREROUTING, has a secret hidden hook (NF_IP_PRI_NAT_SRC) on the "POST side" so that reverse-direction mapping works. >Why is /128 not allowed? that would be extremely useful for roaming >devices internal firewalls and high-security setups with multi-homing. To avoid user confusion, I suspect. When you declare -j MAP66 --from fefe:db8:1::12/128 --to 2001:db8:1::15/128, you won't actually get 2001:db8:1::15, but something that fulfills the checksum constraint. Like 2001:db8:1::f00d or so - which would then be the point of user confusion. -- 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
