Where the de-SNAT actually takes place?

Where the de-SNAT actually takes place?

[longraider]

Hi
I've sent this post on the c.o.l.networking also, and after that I've
found this mailing list, so please forgive this crossposting, as I don't
expect answer from c.o.l.n to this question.

I've been reading a bit about packet traversal in the linux kernel but
apparently my linux box doesn't like theory very much ;-)
My config:
linux-2.6.14.2 with imq patch
eth0 - iface where two inet connections are attached
eth1 - server
eth2 - LAN
There is SNAT involved on one net connection. The other conn is for
servers, and there is proxy-arp active (at eth0 and eth1).

I type:
iptables -t nat -A PREROUTING -i eth0 -j LOG
And after that, dmesg shows something like that:
17:08:53 IN=eth0 OUT= SRC=some_remote_IP DST=IP_of_the_linux_box

Shouldn't be there DST=10.0.0.5 for example (ie. de-SNATed)?

I've found that on google:
http://lists.netfilter.org/pipermail/netfilter/2003-July/045355.html
And that is weird. I think that in my kernelversion this is implemented
in different way, but actually I don't know what is going on.

And all that I want to do is ingress queuing using IMQ. I want to fwmark
packets according to their de-SNATed destination adress (and some other
things also), and then put them into the IMQ ingress queue.
I could use the packet matching available in the ingress queue itself
(by ip tool), but I don't know if the packets that go into IMQ are
de-SNATed or not.

So, where the de-SNAT actually takes place?

BTW is this diagram correct?
http://www.docum.org/docum.org/kptd/
I think not, since traversing the magle PREROUTING can't occur
simulatenously with de-MASQ. And is this de-MASQUERADE a de-SNAT also?

-- 
mati

Re: Where the de-SNAT actually takes place?

[Pascal Hambourg]

Hello,

longraider a écrit :
> 
> linux-2.6.14.2 with imq patch
> eth0 - iface where two inet connections are attached
> eth1 - server
> eth2 - LAN
> There is SNAT involved on one net connection. The other conn is for
> servers, and there is proxy-arp active (at eth0 and eth1).
> 
> I type:
> iptables -t nat -A PREROUTING -i eth0 -j LOG
> And after that, dmesg shows something like that:
> 17:08:53 IN=eth0 OUT= SRC=some_remote_IP DST=IP_of_the_linux_box
> 
> Shouldn't be there DST=10.0.0.5 for example (ie. de-SNATed)?

This packet probably does not belong to a SNAT-ed or MASQ-ed connection.
Actually, with this rule you won't see the return packets belonging to 
your SNAT-ed connection. In short, the 'nat' table chains only see the 
first packet of a "connection", and only if it has the state NEW (not 
RELATED). All the subsequent valid packets belonging or related to that 
connection (state NEW, ESTABLISHED, or RELATED) don't go through theses 
chains. The action taken by these packets is automatically determined by 
the NAT operation applied to the first packet and the direction of the 
packet.

For instance, with this rule :
iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4

The first 'direct' packet of an outgoing connection on eth0 goes through 
the nat POSTROUTING chains and matches this rule, so the SNAT operation 
is applied. Instead of going through the POSTROUTING chain, the 
subsequent direct packets (in the same direction) of the connection will 
automatically be applied the same SNAT operation. The return packets (in 
the opposite direction) of the connection will automatically be applied 
the de-SNAT operation instead of going through the nat PREROUTING chain. 
By the way, the subsequent packets of the connection don't need to go in 
or out eth0 (funny, huh ?) to be properly NATed.

> And all that I want to do is ingress queuing using IMQ. I want to fwmark
> packets according to their de-SNATed destination adress (and some other
> things also), and then put them into the IMQ ingress queue.
> I could use the packet matching available in the ingress queue itself
> (by ip tool), but I don't know if the packets that go into IMQ are
> de-SNATed or not.
> 
> So, where the de-SNAT actually takes place?

De-SNAT takes place in the NF_IP_PRE_ROUTING Netfilter hook at the same 
place as the nat PREROUTING chain, after the mangle PREROUTING chain and 
before the input routing decision.

For DNAT which occured in the PREROUTING chain, de-DNAT takes place in 
the NF_IP_POST_ROUTING Netfilter hook, at the same place as the nat 
POSTROUTING chain, after the mangle POSTROUTING chain.

For DNAT which occured in the OUTPUT chain, I observed that de-DNAT 
takes place in the NF_IP_LOCAL_IN Netfilter hook, after the mangle and 
filter INPUT chains.

> BTW is this diagram correct?
> http://www.docum.org/docum.org/kptd/

I think so, at least for the pure Netfilter part which matches my own 
diagram http://www.plouf.fr.eu.org/bazar/netfilter/schema_netfilter.txt. 
I don't know about the IMQ and QoS parts.

> I think not, since traversing the magle PREROUTING can't occur
> simulatenously with de-MASQ.

Incoming packets traverse the mangle PREROUTING chain just before being 
de-MASQ-ed if needed.

> And is this de-MASQUERADE a de-SNAT also?

Yes. Actually MASQUERADE and SNAT are similar, the only difference being 
in the choice of the new source address.

De-MASQ and de-SNAT both are destination address rewrite operations, so 
it is consistent that they take place in the same place as the nat 
PREROUTING chain which performs DNAT. But keep in mind that they take 
place *instead* of trversing the nat PREROUTING chain, so you will never 
see packets being de-MASQ-ed or de-SNAT-ed in any nat chain.

Re: Where the de-SNAT actually takes place?

[Jarek Poplawski]

On 19-08-2006 19:38, longraider wrote:
> Hi
...
> And all that I want to do is ingress queuing using IMQ. I want to fwmark
> packets according to their de-SNATed destination adress (and some other
> things also), and then put them into the IMQ ingress queue.
> I could use the packet matching available in the ingress queue itself
> (by ip tool), but I don't know if the packets that go into IMQ are
> de-SNATed or not.

IMQ can be configured, at which point of the traversal packets 
should be send to an IMQ pseudo-device (e.g. imq0). This diagram 
shows default variant (so called BA - Before PREROUTING - After 
POSTROUTING), which in my opinion isn't appropriate for common 
nat situations. So try to recompile your kernel after changing 
IMQ config to AB variant and it will see de-nated adresses both 
incoming (-j IMQ in PREROUTING) and outgoing (-j IMQ in 
POSTROUTING - beter don't use one imq device for both).

> So, where the de-SNAT actually takes place?

But you rather should use tc filter then (on imq it is egress 
always). MARK (fwmark) will see incoming packets de-nated only 
begining from FORWARD or INPUT so to use it like you planed, you 
should add IMQ rule for incoming packets in POSTROUTING, which is 
impractical (and excludes INPUT part).

Jarek P.

Re: Where the de-SNAT actually takes place?

[Jarek Poplawski]

On 23-08-2006 13:43, Jarek Poplawski wrote:
> On 19-08-2006 19:38, longraider wrote:
>> Hi
> ...
> variant (so called BA - Before PREROUTING - After POSTROUTING), which in 

or rather:
variant (so called BA - Before nat in PREROUTING - After nat in 
POSTROUTING) ...

Jarek P.