[Top] [All Lists]

Re: Problem with IPSEC tunnel mode

To: hadi@xxxxxxxxxx
Subject: Re: Problem with IPSEC tunnel mode
From: Wolfgang Walter <>
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: <> <> <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?


> > spdadd 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.

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

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