netdev
[Top] [All Lists]

Re: Problem with IPSEC tunnel mode

To: hadi@xxxxxxxxxx
Subject: Re: Problem with IPSEC tunnel mode
From: Wolfgang Walter <wolfgang.walter@xxxxxxxxxxxxxxxxxxxx>
Date: Sat, 23 Apr 2005 23:03:35 +0200
Cc: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>, netdev@xxxxxxxxxxx
In-reply-to: <1114278545.7669.75.camel@localhost.localdomain>
Organization: Studentenwerk München
References: <E1DObFc-0000je-00@gondolin.me.apana.org.au> <200504221522.49403.wolfgang.walter@studentenwerk.mhn.de> <1114278545.7669.75.camel@localhost.localdomain>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: KMail/1.7.2
Am Samstag, 23. April 2005 19:49 schrieb jamal:
> On Fri, 2005-22-04 at 15:22 +0200, Wolfgang Walter wrote:
> So to allow pass-through of esp packets from a<->d at c, you will have
> to essentially create special policy rules (at FWD and OUT) to basically
> just allow if src/dst = a/d, correct?

Yes.

>
> > spdadd 192.168.2.100 192.168.3.10 any -P in ipsec
> >            esp/transport//require
> >            ah/transport//require;
> >
> > installs both in and fwd rules (in RFC-mode).
>
> What is "RFC mode"?

The RFCs for ipsec talk about the SPD. This database must be consulted for 
every packet entering or leaving. Its defined as an ordered database. A rules 
has direction, selectors (i.e. src, dst, next layer protocoll, src-port, 
dst-port, icmp-type) and processing info (BYPASS = not handled by ipsec, 
DISCARD = drop the packet, PROTECT = handled by ipsec).

So setkey in RFC mode sets in anf fwd rules as RFC-in = linux-in + linux-fwd.

>
> > Use option -k for only setting  in rules (RFC only knows IN and OUT
> > rules). This behaviour was added to
> > ipsec-tools. As far as I know earlier kernels had a bug and didn't check
> > fwd ruleset so that setkey and racoon worked by accident under linux.
> >
> >
> > racoon now behaves like pluto: it inserts always in and fwd rules. Its
> > easier than to check if a in or fwd rule or both is needed.
>
> I think i am still lost on the desire to have the FWD database. Unless
> we are trying to use SPD for firewalling?

SPD is indeed also a sort of firewall. You can use it to construct i.e. a 
vpn-gateway and forbid any non-vpn-traffic entering or leaving.

How the SPD is implemented is of course not specified. I think KLIPS use a 
mixing of routing and netfilter and "ipsec-netdevices" to realise the SPD.

My personal view is that 2.6 native SPD is better. Its easier to understand 
and protect i.e. vpn-gateways.

Using selectors other than src, dst in the SPD is tricky, by the way, because 
of fragments. Say a rule selects packets from a to b with protocol tcp and 
dst-port 80 to be sent through a tunnel you must have an extra rule (and 
tunnel) for the fragments (and all fragments are tunneled then).

Maybe more complex selectors should be realised by netfilter, a module which 
can mark packets. And SPD uses that mark. Then statefull policies are 
possible, i.e.

I don't know if linux handles ICMP traffic well, often one must check the 
payload against the SPD. I had no time yet to do some tests.

>
> > And no, we do not use setkey any more but ip xfrm (though setkey displays
> > more information, i.e. it tells you if a policy is socket-specific).
>
> Should be fixable in ip xfrm ..
>
> >  Reason is
> > that neither setkey  nor racoon can handle large rule sets. And for most
> > fwd rules we also set an in rule (as pluto does).
>
> Do you know why pfkey doesnt scale? Herbert?

It seems to deliver the whole message at once. If one increase the 
socket-buffer (must change racoon and setkey source, at least with version 
0.3.3) enough one gets complete dumps, ie. But sometimes there seems to be 
still problems - i.e. if you send a lot of messages. Maybe the kernel can not 
create these large messages because it cannot allocate enough memory in that 
moment or racoon cannot read fast enough.

Greetings,
-- 
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
Leopoldstraße 15
80802 München


<Prev in Thread] Current Thread [Next in Thread>