Re: Freeswan in Debian, or: Why I am such a bad maintainer
- To: "Dominique Kaiser" <email@example.com>
- Cc: "Wichert Akkerman" <firstname.lastname@example.org>, "Lupe Christoph " <email@example.com>, "Marc Haber " <firstname.lastname@example.org>, "Rene Mayrhofer " <email@example.com>, "Bastian Blank " <firstname.lastname@example.org>, "Dominique Kaiser " <email@example.com>, "Giacomo Mulas " <firstname.lastname@example.org>, "Steven Augart " <email@example.com>, "Anthony DeRobertis " <firstname.lastname@example.org>, "Andrew Pimlott " <email@example.com>, firstname.lastname@example.org, "Alexander Hvostov " <email@example.com>, "Daniel Pocock " <firstname.lastname@example.org>, "Russell Stuart " <email@example.com>, firstname.lastname@example.org, "Christoph Martin " <email@example.com>, "Alexei Ustyuzhaninov " <firstname.lastname@example.org>, "Jason Spence " <email@example.com>, "Mike Fedyk " <firstname.lastname@example.org>, "Luca Fornasari " <email@example.com>, "Torsten Knodt " <firstname.lastname@example.org>, "Christian Perrier " <email@example.com>, "Luk Claes " <firstname.lastname@example.org>, email@example.com, "Nate Carlson" <firstname.lastname@example.org>
- Subject: Re: Freeswan in Debian, or: Why I am such a bad maintainer
- From: "Daniel Pocock" <email@example.com>
- Date: Tue, 29 Jun 2004 09:27:21 +0100 (BST)
- Message-id: <firstname.lastname@example.org>
- In-reply-to: <40E07B74.email@example.com>
- References: <40E00DDA.firstname.lastname@example.org> <20040628130629.GB9561@wiggy.net> <20040628142423.GO6752@torres.ka0.zugschlus.de> <20040628143046.GH9561@wiggy.net> <20040628165547.GT29463@lupe-christoph.de> <20040628193306.GN9561@wiggy.net> <40E07B74.email@example.com>
Here is a very simple example:
- the method works with manual keying or any IKE daemon
- any packets from IPsec peers will be fully trusted and not be screened
further by netfilter
Step 1: Identify packets in mangle table
iptables --table mangle -A PREROUTING -p esp -j MARK --set-mark 1
Step 2: Allow packets in filter table
iptables --table filter --insert INPUT --match mark --mark 1 -j ACCEPT
When packets traverse the PREROUTING chain of the 'mangle' table, they are
still encrypted. At this point, they can be marked. The firewall mark
remains with the packet even after the packet is decrypted. When it
reaches the INPUT (or possibly FORWARD) chain of the 'filter' table, the
packet still bears the mark.
This example assumes that you completely trust any packets from any hosts
you have chosen to accept IPsec packets from.
You could make the rules tighter to only allow IPsec packets from specific
hosts, networks or interfaces.
> And again we arrive at the lacking docu...
> - Why is it more flexible ?
> - How is it different ?
> - How would I do this "dummy interface" with 26 IPSEC and OpenSwan ?
> - Why doesn't OpenSwan do this by default when using 26 ?
> - How would I / Can I use tcpdump with this setup ?
> - Is this possible with a stock 2.6 kernel ?
> - and so on...
> ( I don't expect an answer here - I know some of the answers but not all..
> this is more to demonstrate what's missing in my opinion)
> - keep in mind that most people are NOT interested at all if some of
> the above is in the sole "problem domain" of OpenSwan, of 2.6 kernel
> or if it is a mixture of both - they want it to work smoothly and in an
> intuitive way.
> Just my two cents,
> Wichert Akkerman wrote:
>>Previously Lupe Christoph wrote:
>>>Such as having virtual interfaces to hang firewall rules from,
>>>preferably one per tunnel?
>>You should be able to do that using dummy interfaces. Just keep in
>>mind that ipsec is no longer done through an interface but via a
>>route transform, which is a very different and more flexible approach.