Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Valentijn Sessink <valentyn+netfilter-users@nospam.openoffice.nl>
To: Marc Haber <mh+netfilter@zugschlus.de>
Cc: netfilter@lists.netfilter.org
Subject: Re: [despammed] port based filtering and IPsec 2.6
Date: Thu, 22 Jan 2004 13:43:23 +0100	[thread overview]
Message-ID: <20040122124323.GA12974@openoffice.nl> (raw)
In-Reply-To: <20040121214643.GA1308@torres.ka0.zugschlus.de>

Hello Marc,

At Wed, Jan 21, 2004 at 10:46:43PM +0100, Marc Haber wrote:
> > Why is that error prone? If your concern is putting out unencrypted packets
> > to certain networks, you can just use -p esp.
> My concern is that I'd need to maintain the list of networks that
> should be reached only via ipsec twice: Once in the ipsec setup, and
> once in the packet filter. With a dedicated interface, I'd only have
> to maintain it in the ipsec setup with the packet filter automatically
> following with rules on --out-int ipsecfoo.

That wouldn't help you with egress-filtering. You'd still need a rule to
prevent unencrypted packets going out to your eth0 interface.

> > It is no more or less complicated to say "-i ipsec0" or "-m mark --mark 1".
> But the interface comes automatically, while one would need to worry
> about putting the mark on the packet.

Easy enough: put a mark on *all* outgoing packets, then filter ESP packets
with a mark in the POSTROUTING table.

> This works "fine" for incoming packets, but gets ugly for outgoing
> packets.

OK, I think I understand what you mean, and I think I've found a solution
here, too. Your concern is that once a packet is in OUTPUT, it could be gone
if there's no post-encryption stage. Luckily, I found out there is one.
 On output, the output packets go unencrypted in the OUTPUT table,
then go encrypted through POSTROUTING, so you can filter unwanted
un-encrypted packets there.

Suppose you have something like
filter bla bla bla $foo $portnumberfoo -o ethX
filter bla bla bla $bar $portnumberbar -o ipsec0

What you "conceptually" say is that for some port/IPsec combinations you
would do Something, and for some port/unencrypted combinations you would do
SomethingElse

Suppose you want to convert this to 2.6 IPsec. You would setup a tunnel and
make rules to mark the combinations:

mark --set-mark 1 -A OUTPUT bla bla bla $foo $portnumberfoo
mark --set-mark 2 -A OUTPUT bla bla bla $bar $portnumberbar

Then use this mark to filter in the POSTROUTING chain to do Something or
SomethingElse.

> You mean a setup like "send everything to a.b.c.d/e through the ipsec
> tunnel, except for traffic to a.b.c.d/e TCP port 22"? Right, that's
> not possible with FreeS/WAN. Can 2.6 ipsec do that?

FreeS/WAN can do that, too, I think, but you'd need policy routing for that.
Yes, 2.6 IPsec can do that by design.

> Not at all. Looks like two non-native speakers misunderstanding each
> other.

Grin ;-)
Unsere Amerikanische Freunde werden kein Deutsch verstehen. En Nederlands is
misschien ook voor jou wat lastig.

> Well, most systems make a tunnel look like a dedicated connection on a
> "virtual network interface". This makes sense, and is more natural to
> handle, IMO, than having to fiddle with marks in a number space that
> might already be populated for traffic shaping or policy routing.

I now understand. Yes, the concept is different and there is not enough
documentation about the table traversing of the packets. I did some testing
to find this out, but still have no 100% idea of the route packets take. A
nice ASCII drawing could really help here ;-)

Best regards,

Valentijn
-- 
http://www.openoffice.nl/   Open Office - Linux Office Solutions
Valentijn Sessink  valentyn+sessink@nospam.openoffice.nl


  reply	other threads:[~2004-01-22 12:43 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-14 16:26 port based filtering and IPsec 2.6 Valentijn Sessink
2004-01-17 13:45 ` [despammed] " Andreas Kretschmer
2004-01-17 17:47   ` netfilter.lists.samba.org
2004-01-17 18:29     ` Antony Stone
2004-01-18  9:14       ` Marc Haber
2004-01-18  9:34         ` Antony Stone
2004-01-19  7:43           ` Marc Haber
2004-01-21 15:39     ` [despammed] " Valentijn Sessink
2004-01-21 15:37   ` Valentijn Sessink
2004-01-21 15:44     ` Marc Haber
2004-01-21 16:31       ` Valentijn Sessink
2004-01-21 21:46         ` Marc Haber
2004-01-22 12:43           ` Valentijn Sessink [this message]
2004-02-17 15:02             ` Marc Haber
2004-02-17 15:16               ` Valentijn Sessink

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040122124323.GA12974@openoffice.nl \
    --to=valentyn+netfilter-users@nospam.openoffice.nl \
    --cc=mh+netfilter@zugschlus.de \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox