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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.