DNATing without connection tracking - is it possible?

DNATing without connection tracking - is it possible?

Post by Chris De » Fri, 23 Jan 2009 02:45:13



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.

 
 
 

DNATing without connection tracking - is it possible?

Post by Pascal Hambour » Fri, 23 Jan 2009 07:15:21


Hello,

Chris Dew a crit :

Quote:> 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.

Quote:> 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 ?

Quote:> (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.

Quote:> 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.

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

Can you elaborate ?

 
 
 

DNATing without connection tracking - is it possible?

Post by Pascal Hambour » Fri, 23 Jan 2009 07:16:17


Hello,

Chris Dew a crit :

Quote:> 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.

Quote:> 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 ?

Quote:> (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.

Quote:> 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.

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

Can you elaborate ?
 
 
 

DNATing without connection tracking - is it possible?

Post by Chris De » Fri, 23 Jan 2009 19:30:43


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.

 
 
 

DNATing without connection tracking - is it possible?

Post by Pascal Hambour » Fri, 23 Jan 2009 19:53:00


Chris Dew a crit :

Quote:

> 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.

Quote:> 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.

Quote:> - 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 ?
 
 
 

DNATing without connection tracking - is it possible?

Post by Burkhard Ot » Fri, 23 Jan 2009 20:23:46


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

Quote:> 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,http://linux.die.net/man/8/connt...)

cheers

 
 
 

DNATing without connection tracking - is it possible?

Post by Chris De » Fri, 23 Jan 2009 23:05:41


IIRC ipchains REDIRECT was a nice/* 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://www.veryComputer.com/

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.

 
 
 

DNATing without connection tracking - is it possible?

Post by Chris De » Sat, 24 Jan 2009 00:07:47


The link above to a 'raw' patch is completely useless - it does not
add raw support to iptables on the 2.4 kernel.
 
 
 

DNATing without connection tracking - is it possible?

Post by Pascal Hambour » Sat, 24 Jan 2009 00:58:25


Chris Dew a crit :

Quote:> The link above to a 'raw' patch is completely useless - it does not
> add raw support to iptables on the 2.4 kernel.

Obviously not, looking at it. It just adds support for the UNTRACKED
state in the conntrack. I guess it is just a part of the 'raw' patchlet
adapted for Linux 2.4.30. You need to get the complete patchlet from the
patch-o-matic-ng. According to my information, the last snapshot
including 'raw' for Linux 2.4 was patch-o-matic-ng-20050918.tar.bz2. It
is not any more available at netfilter.org, however you may still find
it on other mirror or archive sites. Otherwise, I kept a copy. I haven't
checked whether it applies and works on the latest Linux 2.4 releases.
 
 
 

DNATing without connection tracking - is it possible?

Post by Chris De » Sat, 24 Jan 2009 05:30:23




Quote:> Chris Dew a crit :

> > The link above to a 'raw' patch is completely useless - it does not
> > add raw support to iptables on the 2.4 kernel.

> Obviously not, looking at it. It just adds support for the UNTRACKED
> state in the conntrack. I guess it is just a part of the 'raw' patchlet
> adapted for Linux 2.4.30. You need to get the complete patchlet from the
> patch-o-matic-ng. According to my information, the last snapshot
> including 'raw' for Linux 2.4 was patch-o-matic-ng-20050918.tar.bz2. It
> is not any more available at netfilter.org, however you may still find
> it on other mirror or archive sites. Otherwise, I kept a copy. I haven't
> checked whether it applies and works on the latest Linux 2.4 releases.

Thanks for the info, I've found the patch on a mirror site and I'll
give it a go tomorrow.

Regards,

Chris.

 
 
 

DNATing without connection tracking - is it possible?

Post by Chris De » Tue, 27 Jan 2009 18:06:50


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.



> > 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.

 
 
 

DNATing without connection tracking - is it possible?

Post by Pascal Hambour » Tue, 27 Jan 2009 21:47:27


Chris Dew a crit :

Quote:> 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.

Quote:> 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.

Quote:>  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 ?

Quote:> # 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

 
 
 

1. Tracking -STABLE without 'net connection

Ok, here is my situation. My FreeBSD machine at home does not have an
internet connection, but I would like to track 4-STABLE. However, I do
have access to the net at school, along with a CD-burner for the purpose
of moving large quantities of data back and forth.

From a cursory look through the handbook, it seems that the main
alternative to cvsup is CTM. However, I would prefer doing something more
along the lines of copying large portions of the 4-STABLE source tree to
CD and performing a cvsup (or something similar) off of the disc.

Has anyone had any experience doing something like this (in particular, is
there an easy way to do it)? Am I overlooking some particularly easy way
of accomplishing the same thing? Any suggestions anyone could offer would
be of much use.

-Davis

Shakespeare on television:
"But soft! what light through yon window breaks?
 It speaks, and yet says nothing."
(Romeo and Juliet)

2. Pacific CommWare Turbo Express Port 920 SOLVED

3. DNATing a masqueraded connection

4. Modem pppk lock up

5. Connection tracking and [UNREPLIED] connections

6. FIPS Problems

7. Network without cable connection or without modem.

8. How to upgrade to 2.0 without libc-5.2.18?

9. Tracking spoofed IPs possible?

10. Is it possible to track sendmail's progression?

11. More than 63 sect/track possible?

12. Tracking RedHat updates without a RedHat support contract

13. Is there some way to track page faults without kernel hacking ?