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 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
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.
Anstalt des öffentlichen Rechts