Re: connmark and nat

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



02.04.2015 01:58, Pascal Hambourg пишет:
Dmitry Melekhov a écrit :
I'm trying to do DNAT/SNAT on the same host with connmark and can't get
it working.

My host has static ip 192.168.22.252 and it can get address
192.168.22.99 from VRRP, so bind doesn't listen on 192.168.22.99,
Why not ?

because there is no such address on interface, it becomes available only at VRRP state change to master :-)

but if host got this address it has to answer on it the same as on
192.168.22.252.

So , if traffic goes to 192.168.22.99 port 53 udp, I need to redirect it
to 192.168.22.252:53,
Not if you can have BIND to listen on 192.168.22.99 when your host gets
the address.

Yes, really, I can, but I'd like to solve this by using iptables, just for fun, you know ;-)

and if it was to 192.168.22.99 host need to reply from this address.
This is automatic with stateful destination NAT (DNAT).

Really not, bind uses udp, so it will reply from 192.168.22.252, i.e. from address it listens.

DNAT part works:

#mark
iptables -t mangle -A PREROUTING -d 192.168.22.99 -p udp --dport 53 -j
CONNMARK --set-mark 0x100

#restore mark inside connection
iptables -t mangle -A PREROUTING -d 192.168.22.99 -p udp --dport 53 -j
CONNMARK --restore-mark

#do NAT
iptables -t nat -A PREROUTING -m mark --mark 0x100 -j DNAT
--to-destination 192.168.22.252
What a complicated setup. Why not just this :

iptables -t nat -A PREROUTING -d 192.168.22.99 -p udp --dport 53 \
   -j DNAT --to-destination 192.168.22.252

Please, see above, in this case replies are go from

192.168.22.252

and clients just drop such packets.


But SNAT doesn't:

#restore mark
iptables -A POSTROUTING -t mangle -j CONNMARK --restore-mark

#do nat
iptables -t nat -A POSTROUTING -m mark --mark 0x100 -j SNAT --to-source
192.168.22.99

I see that no packets hit rule:
Of course not. Stateful NAT automatically takes care of reply packets
and replaces addresses as expected by the original sender. Only the
first packet of a new connection goes throught the chains of the nat table.
Sorry, no.

--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux