Outgoing redirection with iptables - TCP skips NAT?

Outgoing redirection with iptables - TCP skips NAT?

[Kristian Evensen]

Hello,

I am working on configuring a multihomed machine, and one of my goals
is to redirect some outgoing TCP-traffic originating from this machine
using iptables. Currently, I have got it working with UDP and if I add
the rule to the output-chain of the NAT-table before I start the
connection, it works.

However, sometimes I want to start doing redirection in the middle of
a TCP connection and this does not seem to work. I do not get any
matches to my LOG-target (except for the first SYN packet) and the
packets still go through the old interface. In other words, it somehow
seems like TCP is skipping the NAT's output-chain. Does anyone have
any ideas how to solve this?

The iptables rule I use is:
sudo iptables -A OUTPUT -t nat -p tcp -d 192.168.101.14 --dport 9999
-j DNAT --to 192.168.100.250:9999

The LOG rule is constructed like this:
sudo iptables -A OUTPUT -t nat -p udp -d 192.168.101.14 --dport 9999
-m state --state NEW,ESTABLISHED,RELATED --sport 1024:65535 -j LOG
--log-prefix "INFO,OUTPUT,NAT(tcp): " --log-level debug

Thanks in advance,
Kristian

Re: Outgoing redirection with iptables - TCP skips NAT?

[wlet]

Hi,

I guess this won't work because if you connection is established it will be stored in a TCP State table which is used for filtering and forwarding.
If you connection already exists it makes no sense to check it against all rules from the ruleset.

UDP doesn't have a statetable (cuz it's stateless) and that is the reason why this works.

wlet

Re: Outgoing redirection with iptables - TCP skips NAT?

[Kristian Evensen]

Hi,

> I guess this won't work because if you connection is established it will be stored in a TCP State table which is used for filtering and forwarding.
> If you connection already exists it makes no sense to check it against all rules from the ruleset.
>
> UDP doesn't have a statetable (cuz it's stateless) and that is the reason why this works.

Thank you very much, that explains a lot. Is there any way to force
TCP packets through the NAT-filter without writing a module? I have
found out that it sort of works using conntrack -F and rules, but that
is so ugly that I really wish I hadn't found the solution :) I know
this violates more or less every TCP principle, but the reason I want
to do this is because the receiver is multihomed as well. So my plan
is to intelligently stripe data over the links and do it transparent
to the application.

-Kristian

Re: Outgoing redirection with iptables - TCP skips NAT?

[whiplash]

Kristian Evensen ha scritto:

> found out that it sort of works using conntrack -F and rules

There's no reason to flush the whole table when you can
flush single states by using conntrack -D .

Re: Outgoing redirection with iptables - TCP skips NAT?

[Christoph Paasch]

[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]

Hi,

sorry, but the reasoning is wrong.

UDP has a state in the netfilter connection tracking statetable, but it remains 
in the NEW state (as long as there isn't any reply traffic).

And your rule won't work, because DNAT checks, if the packet you try to change 
is associated to a connection in the NEW or RELATED state.
As the connection is established, DNAT won't work.

Christoph

On Thu March 19 2009 wrote wlet@gmx.net:
> Hi,
>
> I guess this won't work because if you connection is established it will be
> stored in a TCP State table which is used for filtering and forwarding. If
> you connection already exists it makes no sense to check it against all
> rules from the ruleset.
>
> UDP doesn't have a statetable (cuz it's stateless) and that is the reason
> why this works.
>
> wlet
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
Christoph Paasch

École Polytechnique de Louvain
Département d'ingénierie informatique

www.rollerbulls.be
--

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]