[Top] [All Lists]

Re: Problem with IPSEC tunnel mode

To: hadi@xxxxxxxxxx
Subject: Re: Problem with IPSEC tunnel mode
From: Wolfgang Walter <>
Date: Fri, 22 Apr 2005 15:22:49 +0200
Cc: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>, netdev@xxxxxxxxxxx
In-reply-to: <1114172084.7679.15.camel@localhost.localdomain>
Organization: Studentenwerk München
References: <> <> <1114172084.7679.15.camel@localhost.localdomain>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: KMail/1.7.2
Am Freitag, 22. April 2005 14:14 schrieb jamal:
> On Fri, 2005-22-04 at 13:42 +0200, Wolfgang Walter wrote:
> > Am Freitag, 22. April 2005 02:18 schrieb jamal:
> [..]
> > > So i was wondering whether they OUT shouldnt be just a duplicate of
> > > FWD (instead FWD seems to be the dup of IN). Look at that sample i
> > > posted - all his policies look like that. What gives? Why are the IN
> > > and FWD exactly the same? bug in racoon/setkey?
> >
> > No. XFRM_POLICY_IN is only checked for incoming packets which are
> > delivered locally.
> For encrypted packets

I think for all packets otherwise it would not make sense to have allow and 
block rules.

I'm not sure how packets of tunnels ending at a host are treated exactly. 
Probably the tunnel-packet itself is checked against XFRM_POLICY_IN because 
its destination is the host itself. Then it gets decrypted if an entry 
appropriate in the sad in (dst,spi) exists. The inner packet gets extracted 
and decrypted and is then rerouted.

I think it is like that because

* you see those packets twice in PREROUTING (mangle) i.e. for an esp-tunnel: 
first as esp-packet than the inner decrypted packet. If the inner packet is 
to be routed, XFRM_POLICY_FWD is relevant, otherwise XFRM_POLICY_IN.

But maybe XFRM_POLICY_IN is bypassed for ipsec-packets.

I didn't try out transport-mode.

> > XFRM_POLICY_FWD is checked for incoming packets which are routed.
> For non-encrypted packets to be forwarded.

Again: for all packets.

Packets to be routed which are still encrypted here are ipsec-packets which 
are not destinated or originating from this host. Of course they may came in 
via a tunnel ending at this host:


If a communicates with d via esp (tunnel or transportmode) and b and c tunnel 
all packets between network N1 and N2 via ipsec then, on c, a ipsec packet 
from a to d would come in via the tunnel packed into another ipsec packet, is 
extracted from the tunnel packet and is routed to d if XFRM_POLICY_FWD allows 
esp packets from a to d and XFRM_POLICY_OUT allows unencrypted communication 
between c and d for esp-packets from a to d.

> > That our XFRM_POLICY_IN matches XFRM_POLICY_FWD is more for convenience:
> > if a subnet is connected directly to a router we want to treat the
> > interface address of the router itself the same way. Instead of
> > constructing special rules which exactly match the interface address we
> > simply use the same rule as for forwarding.
> Ok, so it was design intent then.
> > XFRM_POLICY_OUT ist checked for every outgoing packet, be it locally
> > generated be it routed (which is different from netfilter).
> >
> > This asymmetry is a little bit inconsequent. Probably one should really
> > would mainly be a copy of XFRM_POLICY_FWD_OUT then, I think.
> I did notice racoon or even setkey (version 0.5) for some rules (need to
> investigate) would install two policy rules when i installed only one i.e
> racoon will install one in OUT and other in FWD direction.
> Example script and setkey -DP output attached. In this case i install
> two rules, but for one of them an extra rule is installed. Actually the
> pattern is quiet repeatable as you add more rules. This may also be what
> is happening to you maybe?

spdadd any -P in ipsec

installs both in and fwd rules (in RFC-mode). 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. 

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

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

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