From: Andrew McGregor <andrew@indranet.co.nz>
To: Felipe Alfaro Solana <felipe_alfaro@linuxmail.org>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: [OT] Connection tracking for IPSec
Date: Thu, 21 Aug 2003 10:12:40 +1200 [thread overview]
Message-ID: <1710000.1061417560@ijir> (raw)
In-Reply-To: <1061388988.3804.8.camel@teapot.felipe-alfaro.com>
--On Wednesday, August 20, 2003 04:16:28 PM +0200 Felipe Alfaro Solana
<felipe_alfaro@linuxmail.org> wrote:
> Well, I'm using IPSec on two machines and both of them are end hosts.
> They are *not* working as routers. My netfilter rules are:
Ah. OK. You want to do that *inside* the tunnels.
> Chain INPUT (policy DROP)
> target prot opt source destination
> ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
> ACCEPT all -- localhost.localdomain anywhere
>
> Chain FORWARD (policy DROP)
> target prot opt source destination
>
> Chain OUTPUT (policy ACCEPT)
> target prot opt source destination
>
> The problem is that if I enable IPSec on both machines by using manual,
> preshared keys, no traffic will pass through both firewalls, as I need
> to open up protocols 50 and 51 (AH and ESP).
Which makes sense so far.
> The problem here is that opening up protocols 50 and 51, makes *any*
> IPSec-protected traffic to pass the firewall, but I still want that any
> traffic (IPSec-protected or not) be applied the connection-track
> filters. For normal (no IPSec) traffic, an incoming packet is only
> accepted if it belongs to a connection that was initiated locally. For
> IPSec traffic, I just want the same. I don't want any kind of
> IPSec-protected traffic to be able to pass through the firewall, only
> traffic that belongs to a connection that was initiated locally on the
> machine receiving it.
It doesn't make sense for this configuration to fail in this way, I agree.
Essentially, the ESP and AH transforms should be a magic netfilter rule, so
you can insert them in a netfilter chain and do this sort of thing. If
they aren't, we should at least have the input and output chains traversed
by packets both before and after the transforms.
The issue exists, I'm convinced. Dang, I'm going to run into it too one
day soon. Another thing that needs looking at, in case noone else fixes it
first.
> End note: an incoming packet should be accepted by the firewall if and
> only if there is a corresponding connection (let it be TCP, UDP or ICMP)
> that was first initiated locally on that machine. For example, for any
> incoming TCP packet to traverse the firewall, first there must have been
> a packet with the SYN flag that travelled in the opposite direction. I
> want this to work for normal traffic (it does work now) and for
> IPSec-protected traffic.
>
> Did I explain it clearly?
Yes, you did.
> Thanks again!
You're welcome,
Andrew
next prev parent reply other threads:[~2003-08-20 22:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-20 11:22 [OT] Connection tracking for IPSec Felipe Alfaro Solana
2003-08-20 12:11 ` Christophe Saout
2003-08-20 14:22 ` Felipe Alfaro Solana
2003-08-20 14:53 ` Christophe Saout
2003-08-20 15:18 ` Felipe Alfaro Solana
2003-08-20 17:36 ` Jose Luis Domingo Lopez
2003-08-20 12:49 ` Andrew McGregor
2003-08-20 14:16 ` Felipe Alfaro Solana
2003-08-20 22:12 ` Andrew McGregor [this message]
2003-08-21 4:37 ` Rick Kennell
2003-08-20 14:43 ` Wiktor Wodecki
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=1710000.1061417560@ijir \
--to=andrew@indranet.co.nz \
--cc=felipe_alfaro@linuxmail.org \
--cc=linux-kernel@vger.kernel.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