From: Alexander Samad <alex@samad.com.au>
To: netfilter@lists.netfilter.org
Subject: Re: Ipsec/l2tp
Date: Sun, 4 Jul 2004 08:58:22 +1000 [thread overview]
Message-ID: <20040703225822.GF6126@samad.com.au> (raw)
In-Reply-To: <opsaj8azll5vdmd8@smtp.fastwebnet.it>
[-- Attachment #1: Type: text/plain, Size: 2104 bytes --]
On Sat, Jul 03, 2004 at 01:46:01PM +0200, Primero wrote:
>
> >
> >I hope someone else here can now fill in some useful details for you,
> >given
> >that you're using 2.6.6
> >
> >Regards,
> >
> >Antony.
> >
>
> I'm not an expert, but AFAIK and because it works using this way i think
> that in 2.6 the process is very similar.
>
> In 2.6 ipsec imlementation there is no Virtual interface, like ipsec0 or
> everything else, but the packets both encrypted and unencrypted come from
> the same interface , in expample eth0. They traverse netfilter two times,
> like in 2.4 , they get the first time to the INPUT chain, if accepted they
> traverse netfilter again in the normal process.
>
> The reason i mark my packets at the STEP 1 when they come in encrypted is
> because i needed a way to identify packets that arrived ENCRYPTED, get
> decrypted and acceppted by ipsec and that are traversing the netfilter for
> the second time.
> This way i can be sure that i handle only packets that have been accepted
> by ipsec and i can feel good :)
> for example, i use ipsec fot my WIFI lan and i have this kind of rules:
>
> 1) MANGLE/PREROUTING for packets arriving in esp protocol
>
> iptables -t mangle -a PREROUTING -s $Y_WIFI_HOSTS -i $MY_WIFI_INTERFACE -p
> esp -j MARK --set-mark 10
>
> 2) INPUT for packets arriving in esp protocol
>
> iptables -A INPUT -p esp -j ACCEPT
>
> now IPSEC will authenticate and eventually accept the packets
>
> 3) INPUT and FORWARD for previously athenticated packets
>
> iptables -A FORWARD -m --mark 10 -j MY_FORWARD_CHAIN
> iptables -A INPUT -m --mark 10 -j MY_INPUT_CHAIN
Hi
I believe there is a patch in pom-ng called policy that let you match a
packet based on which ipsec policy it used.
Another methog I use is using the updown script option and adding remove
firewall rules on the fly, on seconds thoughts that is not as good as
above though.
Alex
>
>
>
> bye
>
>
>
> --
> Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
>
>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
prev parent reply other threads:[~2004-07-03 22:58 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-03 10:25 Ipsec/l2tp Eray Aslan
2004-07-03 11:13 ` Ipsec/l2tp Antony Stone
2004-07-03 11:46 ` Ipsec/l2tp Primero
2004-07-03 22:58 ` Alexander Samad [this message]
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=20040703225822.GF6126@samad.com.au \
--to=alex@samad.com.au \
--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