Building the conntrack rule from scratch

Building the conntrack rule from scratch

[Bryan Duff]

If I build a conntrack rule (before any traffic actually traverses), and 
then send traffic through, the conntrack rule gets used, but no SNAT 
takes place.  It sends the packet outbound with a source IP on the LAN 
instead of using the reply-dst and SNAT'ing to the WAN side.

How do I get it to SNAT the packet?  In this way I'm circumventing 
iptables (why use it when you already have all the information anyway) - 
so nat POSTROUTING is never actually touched by the first outbound 
packet - it's picked up by the conntrack rule.

Tell me if I'm missing something, or if more information is needed.

-Bryan

Re: Building the conntrack rule from scratch

[Jan Engelhardt]

On Wednesday 2008-11-26 22:45, Bryan Duff wrote:

> If I build a conntrack rule (before any traffic actually traverses), and then
> send traffic through, the conntrack rule gets used, but no SNAT takes place.

Elaborate?

> Tell me if I'm missing something, or if more information is needed.

The actual "rule".

Re: Building the conntrack rule from scratch

[Bryan Duff]

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)?

iptables -t nat -A POSTROUTING -o eth1 -s 192.168.10.1/24 -m realm 
--realm 1 -j SNAT --to 192.168.2.204

Thanks.

-Bryan

Jan Engelhardt wrote:
> On Wednesday 2008-11-26 22:45, Bryan Duff wrote:
>
>   
>> If I build a conntrack rule (before any traffic actually traverses), and then
>> send traffic through, the conntrack rule gets used, but no SNAT takes place.
>>     
>
> Elaborate?
>
>   
>> Tell me if I'm missing something, or if more information is needed.
>>     
>
> The actual "rule".
>   

Re: Building the conntrack rule from scratch

[Jan Engelhardt]

On Wednesday 2008-11-26 23:57, 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.

> iptables -t nat -A POSTROUTING -o eth1 -s 192.168.10.1/24 -m realm --realm 1 -j
> SNAT --to 192.168.2.204

Re: Building the conntrack rule from scratch

[Bryan Duff]

Jan Engelhardt wrote:
> On Wednesday 2008-11-26 23:57, 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?  Or is 
there still something I'm not doing (like setting up --src-nat in the 
conntrack -I command)?  Because when the packet from 192.168.10.10 going 
out eth1, is still has a source IP of 192.168.10.10 (and not 192.168.2.204).

I also assume that the SNAT rule below is ignored (when the conntrack 
rule above is used).
>> iptables -t nat -A POSTROUTING -o eth1 -s 192.168.10.1/24 -m realm --realm 1 -j
>> SNAT --to 192.168.2.204
>>     

Re: Building the conntrack rule from scratch

[Jan Engelhardt]

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.