DNATing without connection tracking - is it possible?

I'm using kernel 2.4.37 and iptables 1.3.8.

I have a complex firewall requirement - what I need is to do DNAT
without it creating an entry in the connection tracking table. Is
there a module or command which does this?

Alternatively, is there an iptables module which allows just the
destination port of packets to be changed, without anything being
written to connection tracking?

(DNAT has a feature/bug: if you establish a DNAT connection in
response to an iptables rule which depends on the *interface* of the
incoming packet, the connection which is created will have no concept
of the interface.

Thus, if a packet is DNATted (as a result of an iptables rule matching
its source interface of eth0), packets with identical addresses and
ports will also be DNATted, even if they *didn't* come in from eth0!

This breaks an HA system which used to work with ipchains.)

Thanks,

Chris.

Hello,

Chris Dew a écrit :
> I'm using kernel 2.4.37 and iptables 1.3.8.
>
> I have a complex firewall requirement - what I need is to do DNAT
> without it creating an entry in the connection tracking table. Is
> there a module or command which does this?

Linux 2.4 has some stateless NAT aka "routing NAT", used with the 'ip'
command from iproute. However it is considered broken. Linux 2.6.20 and
above has a new stateless NAT capability, used with tc from iproute.

> Alternatively, is there an iptables module which allows just the
> destination port of packets to be changed, without anything being
> written to connection tracking?

I don't know any. You may have better luck asking the netfilter list.
Question : how would you deal with the reply packets ?

> (DNAT has a feature/bug: if you establish a DNAT connection in
> response to an iptables rule which depends on the *interface* of the
> incoming packet, the connection which is created will have no concept
> of the interface.

It's not a bug, it's a feature. And it's a feature of the connection
tracking so it's not specific to DNAT, it's common to all stateful
netfilter targets and matches, including all other NAT targets.

> Thus, if a packet is DNATted (as a result of an iptables rule matching
> its source interface of eth0), packets with identical addresses and
> ports will also be DNATted, even if they *didn't* come in from eth0!

Right, and I support this behaviour. A connection is not defined by the
input/output interface. However you may use the NOTRACK target to have
the conntrack ignore packets you don't want NATed.

> This breaks an HA system which used to work with ipchains.)

Can you elaborate ?

Hello,

Chris Dew a écrit :
> I'm using kernel 2.4.37 and iptables 1.3.8.
>
> I have a complex firewall requirement - what I need is to do DNAT
> without it creating an entry in the connection tracking table. Is
> there a module or command which does this?

Linux 2.4 has some stateless NAT aka "routing NAT", used with the 'ip'
command from iproute. However it is considered broken. Linux 2.6.24 and
above has a new stateless NAT capability, used with tc from iproute.

> Alternatively, is there an iptables module which allows just the
> destination port of packets to be changed, without anything being
> written to connection tracking?

I don't know any. You may have better luck asking the netfilter list.
Question : how would you deal with the reply packets ?

> (DNAT has a feature/bug: if you establish a DNAT connection in
> response to an iptables rule which depends on the *interface* of the
> incoming packet, the connection which is created will have no concept
> of the interface.

It's not a bug, it's a feature. And it's a feature of the connection
tracking so it's not specific to DNAT, it's common to all stateful
netfilter targets and matches, including all other NAT targets.

> Thus, if a packet is DNATted (as a result of an iptables rule matching
> its source interface of eth0), packets with identical addresses and
> ports will also be DNATted, even if they *didn't* come in from eth0!

Right, and I support this behaviour. A connection is not defined by the
input/output interface. However you may use the NOTRACK target to have
the conntrack ignore packets you don't want NATed.

> This breaks an HA system which used to work with ipchains.)

Can you elaborate ?

Thanks for your response.

I'm attempting to abuse DNAT as a 'destination port' packet mangler -
to allow a legacy HA solution to continue to work. The traffic is one
way only. NOTRACK would have done the job, if we were using the 2.6
kernel.

The problematic behaviour of the third-party HA programme is that it
requires incoming UDP packets with a destination port of X to be
REDIRECTED into port Y *if* they come in on interface eth0:0 - but
*without* changing their destination port or address. Packets which
come in via tun0 (i.e. have been generated by HA on this box) must
*not* be redirected, as they need to be answered by the service on
port X, as if they had come directly from the client. (i.e. the reply
will go onto the wire, via eth0, due to routing.) This used to work
with ipchains, as it did not rewrite the packet's destination address
and port. Kernel 2.6 stop the writing of packets with arbitrary
source addresses onto an interface. (There are many other reasons not
to change the kernel version.)

I am currently working on a shim library to alter the behaviour of the
service - this will fix the problem. I can make HA send the packets
to a high port number (on which the service can also listen), I can
then cause the service to reply from it's normal port X.

Thanks,

Chris.

Chris Dew a écrit :
>
> NOTRACK would have done the job, if we were using the 2.6 kernel.

Can you afford to patch the kernel ? There was a patchlet adding the raw
table and the NOTRACK target for 2.4 kernels in old patch-o-matic-ng.

> The problematic behaviour of the third-party HA programme is that it
> requires incoming UDP packets with a destination port of X to be
> REDIRECTED into port Y *if* they come in on interface eth0:0

There is no such interface. eth0:0 is just a label for an IPv4 alias on
eth0, the real interface.

> - but *without* changing their destination port or address.

Huh ? What does "redirect port X into Y" mean if not change the
destination port X into Y ?

Am Thu, 22 Jan 2009 02:30:43 -0800 schrieb Chris Dew:

> Thanks for your response.
>
> I'm attempting to abuse DNAT as a 'destination port' packet mangler -
> to allow a legacy HA solution to continue to work. The traffic is one
> way only. NOTRACK would have done the job, if we were using the 2.6
> kernel.
>
> The problematic behaviour of the third-party HA programme is that it
> requires incoming UDP packets with a destination port of X to be
> REDIRECTED into port Y *if* they come in on interface eth0:0 - but
> *without* changing their destination port or address. Packets which
> come in via tun0 (i.e. have been generated by HA on this box) must
> *not* be redirected, as they need to be answered by the service on
> port X, as if they had come directly from the client. (i.e. the reply
> will go onto the wire, via eth0, due to routing.) This used to work
> with ipchains, as it did not rewrite the packet's destination address
> and port. Kernel 2.6 stop the writing of packets with arbitrary
> source addresses onto an interface. (There are many other reasons not
> to change the kernel version.)

You may looking for conntrackd to get happy again...
(http://conntrack-tools.netfilter.org...n/8/conntrackd)

cheers

IIRC ipchains REDIRECT was a nice/nasty kludge - it gave the packet
directly to whatever service was listening on port Y *without*
rewriting the packet - it definitely didn't start any overly-
promiscuous connection tracking.

I've found a patch for 2.4.30 - it seems to apply cleanly to 2.4.37 -
I'm building it now. http://lists.netfilter.org/pipermail...il/019420.html

Yes, I understand that eth0:0 is an alias - I should have said 'if
they come in on eth0 with a destination address of eth0:0's address'.

Thanks,

Chris.

Chris Dew <(E-Mail Removed)> wrote:
> I'm using kernel 2.4.37 and iptables 1.3.8.
>
> I have a complex firewall requirement - what I need is to do DNAT
> without it creating an entry in the connection tracking table. Is
> there a module or command which does this?

The ip tool from the iproute suite can do stateless natting.

http://linux-ip.net/html/nat-stateless.html

--
Bruce

I unfortunately do not know how to turn cheese into gold.

Thanks, but ip says it's deprecated and it doesn't like the syntax.
As far as I can google, everyone seems to be saying use iptables
instead. (Unfortunately iptables with kernel 2.4.x can't do stateless
nat. Adding the raw table, to the 2.4 kernel, via patch-o-matic makes
all NOTRACK responses appear to come from port 1 ?!?)

# ip rule add nat 205.254.211.17 via 192.168.1.115
Warning: route NAT is deprecated
Error: argument "via" is wrong: Failed to parse rule type

Regards,

Chris.


On 23 Jan, 15:35, Bruce Richardson <itsbr...@uklinux.net> wrote:
> Chris Dew <cms...@googlemail.com> wrote:
> > I'm using kernel 2.4.37 and iptables 1.3.8.
>
> > I have a complex firewall requirement - what I need is to do DNAT
> > without it creating an entry in the connection tracking table. *Is
> > there a module or command which does this?
>
> The ip tool from the iproute suite can do stateless natting.
>
> http://linux-ip.net/html/nat-stateless.html
>
> --
> Bruce
>
> I unfortunately do not know how to turn cheese into gold.

Chris Dew a écrit :
> Thanks, but ip says it's deprecated and it doesn't like the syntax.

Actually it should still "work" as usual (i.e. with the known level of
brokenness) on 2.4 and older 2.6 kernels.

> As far as I can google, everyone seems to be saying use iptables
> instead. (Unfortunately iptables with kernel 2.4.x can't do stateless
> nat.

AFAIK, iptables cannot do stateless NAT regardless of the kernel version.

> Adding the raw table, to the 2.4 kernel, via patch-o-matic makes
> all NOTRACK responses appear to come from port 1 ?!?)

Could you elaborate a bit, providing traces ?

> # ip rule add nat 205.254.211.17 via 192.168.1.115
> Warning: route NAT is deprecated
> Error: argument "via" is wrong: Failed to parse rule type

Wrong syntax, indeed. Either you want to do source NAT with :

ip rule add nat 205.254.211.17 from 192.168.1.115

or you want to do destination NAT with :

ip route add nat 205.254.211.17 via 192.168.1.115