[RFC] matching tproxied packets

[RFC] matching tproxied packets

[Balazs Scheidler]

Hi,

Suppose you have a TCP session, which is transparently redirected to a local
proxy. With the current state of the tproxy framework one need to add two
rules to iptables:

- one to the tproxy table to actually redirect a session
- one to the filter table to let the NATed traffic enter the local stack (in
  INPUT)

I'd like to make tproxies easier to administer, so I'm thinking about a
simple way of matching tproxied packets, which can be ACCEPTed from the
INPUT chain.

Possible solutions:

* use a new state (called TPROXY), which would be applied to all TPROXYed
  packets (might interact badly with nat/conntrack).
* have the tproxy framework mark all packets with an fwmark, and let the
  packets in based on the value of fwmark
* have a separate match (called tproxy), which matches tproxied sessions
  based on some value stored in the associated conntrack entry

which one do you prefer?

-- 
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1

Re: [RFC] matching tproxied packets

[Henrik Nordstrom]

Balazs Scheidler wrote:

> * use a new state (called TPROXY), which would be applied to all TPROXYed
>   packets (might interact badly with nat/conntrack).

It will in no doubt interact badly with connection tracking (and therefore 
NAT).

> * have the tproxy framework mark all packets with an fwmark, and let the
>   packets in based on the value of fwmark

Will interact badly with fwmark based routing.

> * have a separate match (called tproxy), which matches tproxied sessions
>   based on some value stored in the associated conntrack entry

Defenitely my preference, but I might be biased as I make heavy use of 
connection tracking and fwmark based routing in combination.

Regards
Henrik

Re: [RFC] matching tproxied packets

[Balazs Scheidler]

On Tue, Jun 04, 2002 at 05:14:47PM +0200, Henrik Nordstrom wrote:
> Balazs Scheidler wrote:
> 
> > * use a new state (called TPROXY), which would be applied to all TPROXYed
> >   packets (might interact badly with nat/conntrack).
> 
> It will in no doubt interact badly with connection tracking (and therefore 
> NAT).

ok.

> 
> > * have the tproxy framework mark all packets with an fwmark, and let the
> >   packets in based on the value of fwmark
> 
> Will interact badly with fwmark based routing.

of course the mark value would be controlled by the user, and not assigned
automatically.

> > * have a separate match (called tproxy), which matches tproxied sessions
> >   based on some value stored in the associated conntrack entry
> 
> Defenitely my preference, but I might be biased as I make heavy use of 
> connection tracking and fwmark based routing in combination.

This was my conclusion as well. So I'll go for this solution.

-- 
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1

Re: [RFC] matching tproxied packets

[Henrik Nordstrom]

Balazs Scheidler wrote:

> > Will interact badly with fwmark based routing.
>
> of course the mark value would be controlled by the user, and not assigned
> automatically.

As routing rules cannot mask fwmark, anything that touches the fwmark value 
for whatever purpose will affect your fwmark based routing.

The main purpose of fwmark is to communicate state between netfilter and other 
kernel parts such as routing, not as a storage within netfilter.

But sure, if all other uses of fmark supported masked operations then I would 
probably not object..

> > > * have a separate match (called tproxy), which matches tproxied
> > > sessions based on some value stored in the associated conntrack entry
> >
> > Defenitely my preference, but I might be biased as I make heavy use of
> > connection tracking and fwmark based routing in combination.
>
> This was my conclusion as well. So I'll go for this solution.

Good ;-)

Regards
Henrik

Re: [RFC] matching tproxied packets

[Jozsef Kadlecsik]

On Tue, 4 Jun 2002, Balazs Scheidler wrote:

> I'd like to make tproxies easier to administer, so I'm thinking about a
> simple way of matching tproxied packets, which can be ACCEPTed from the
> INPUT chain.
>
> Possible solutions:
>
> * use a new state (called TPROXY), which would be applied to all TPROXYed
>   packets (might interact badly with nat/conntrack).
> * have the tproxy framework mark all packets with an fwmark, and let the
>   packets in based on the value of fwmark
> * have a separate match (called tproxy), which matches tproxied sessions
>   based on some value stored in the associated conntrack entry
>
> which one do you prefer?

The latter seems to me the best solution.

Regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
WWW-Home: http://www.kfki.hu/~kadlec
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: [RFC] matching tproxied packets

[Balazs Scheidler]

On Wed, Jun 05, 2002 at 08:53:25AM +0200, Jozsef Kadlecsik wrote:
> On Tue, 4 Jun 2002, Balazs Scheidler wrote:
> > Possible solutions:
> >
> > * use a new state (called TPROXY), which would be applied to all TPROXYed
> >   packets (might interact badly with nat/conntrack).
> > * have the tproxy framework mark all packets with an fwmark, and let the
> >   packets in based on the value of fwmark
> > * have a separate match (called tproxy), which matches tproxied sessions
> >   based on some value stored in the associated conntrack entry
> >
> > which one do you prefer?
> 
> The latter seems to me the best solution.

ok, should I simply add fields somewhere in struct ip_conntrack, or there's
a bitfield I can add a flag to? 

Looking at the struct I can't see a place general enough, so I can add a new
field just to hold a single bit, or a general "flags" field, which can be
used by other matches later.

-- 
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1

Re: [RFC] matching tproxied packets

[Jozsef Kadlecsik]

On Wed, 5 Jun 2002, Balazs Scheidler wrote:

> ok, should I simply add fields somewhere in struct ip_conntrack, or there's
> a bitfield I can add a flag to?

There is no such bitfield you could use at the moment.

> Looking at the struct I can't see a place general enough, so I can add a new
> field just to hold a single bit, or a general "flags" field, which can be
> used by other matches later.

This is a good question. Probably it is better to add a (general) 'flags'
field. But I have no idea for what else we could use it :-)

Regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
WWW-Home: http://www.kfki.hu/~kadlec
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: [RFC] matching tproxied packets

[Balazs Scheidler]

On Wed, Jun 05, 2002 at 01:02:44PM +0200, Jozsef Kadlecsik wrote:
> On Wed, 5 Jun 2002, Balazs Scheidler wrote:
> 
> > ok, should I simply add fields somewhere in struct ip_conntrack, or there's
> > a bitfield I can add a flag to?
> 
> There is no such bitfield you could use at the moment.
> 
> > Looking at the struct I can't see a place general enough, so I can add a new
> > field just to hold a single bit, or a general "flags" field, which can be
> > used by other matches later.
> 
> This is a good question. Probably it is better to add a (general) 'flags'
> field. But I have no idea for what else we could use it :-)

As I added a flags argument to ip_nat_setup_info() (currently with a single
bit specifying that NAT helpers are to be bypassed), this flags could be
stored in ct->nat.flags

-- 
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1

Re: [RFC] matching tproxied packets

[Henrik Nordstrom]

Jozsef Kadlecsik wrote:

> This is a good question. Probably it is better to add a (general) 'flags'
> field. But I have no idea for what else we could use it :-)

My opinion: Just add a bitfield. If other needs to add other small fields in 
the future they can add it next to yours. The compiler will pack them nicely.

Hmm.. btw, isn't there plenty of space in the ->status field? From what I can 
tell only 3 out of 32 bits is defined in this field. Should be possible to 
shrink it to a char or short, giving room for several more flag fields 
without increasing the size of a conntrack entry.. 

Regards
Henrik

Re: [RFC] matching tproxied packets

[Harald Welte]

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

On Tue, Jun 04, 2002 at 04:50:36PM +0200, Balazs Scheidler wrote:
> Hi,
> 
> Suppose you have a TCP session, which is transparently redirected to a local
> proxy. With the current state of the tproxy framework one need to add two
> rules to iptables:
> 
> - one to the tproxy table to actually redirect a session
> - one to the filter table to let the NATed traffic enter the local stack (in
>   INPUT)
> 
> I'd like to make tproxies easier to administer, so I'm thinking about a
> simple way of matching tproxied packets, which can be ACCEPTed from the
> INPUT chain.
> 
> Possible solutions:
> 
> * use a new state (called TPROXY), which would be applied to all TPROXYed
>   packets (might interact badly with nat/conntrack).

yes, and it is not really a state.

> * have the tproxy framework mark all packets with an fwmark, and let the
>   packets in based on the value of fwmark

fwmark should only be used as configured by the administrator. 

> * have a separate match (called tproxy), which matches tproxied sessions
>   based on some value stored in the associated conntrack entry

this is the preferred solution from my point of view.

> Bazsi

-- 
Live long and prosper
- Harald Welte / laforge@gnumonks.org               http://www.gnumonks.org/
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M+ 
V-- PS++ PE-- Y++ PGP++ t+ 5-- !X !R tv-- b+++ !DI !D G+ e* h--- r++ y+(*)

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]