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
next prev parent 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