On Thursday 2008-11-27 00:24, Bryan Duff wrote: >> > Here is the rule: >> > >> > conntrack -I --orig-src 192.168.10.10 --orig-dst 192.168.2.206 >> > --reply-src 192.168.2.206 --reply-dst 192.168.2.204 -p udp >> > --orig-port-src 5000 --orig-port-dst 7002 --reply-port-src 7002 >> > --reply-port-dst 7000 -u ASSURED -t 60 >> > >> > 192.168.10.10 is the phone in my LAN. >> > 192.168.2.204 is the local WAN address. >> > 192.168.2.206 is the remote address. >> > >> > If that above rule is inserted, and I send traffic (that matches >> > the rule) out the WAN from the LAN, why would it not SNAT the >> > rule on the way out (from orig-src 192.168.10.10 to reply-dst >> > 192.168.2.204)? >> >> You just set up a NAT mapping and even marked it ASSURED, >> so no further mapping modifications are accepted. > > Wait. So I don't need to do anything else? It should work? I did not say that ... I merely said that packets from the connection will not traverse the nat table anymore because the connection is ASSURED. The ASSURED bit (a _status_ bit) is distinct from NEW/ESTABLISHED (a _state_ bit), *but* I would say that setting ASSURED requires that the connection be at least ESTABLISHED, and that the connection state is implicitly upgraded to ESTABLISHED if you try to set it to ASSURED. That is the first issue. The second one may be that because the connection might not have the IP_NAT_MANIP_SRC flag set that no SNAT is done at all. Can't say much more though, since I rarely need conntrack(8) currently. -- 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
