[strongSwan] Connections with marks and iptables

Martin Willi martin at strongswan.org
Wed Nov 26 14:51:31 CET 2014


Hi Noel,

> Judging from this flow chart [1] , the packets have to be marked
> correctly before XFRM LOOKUP is hit on any side.

One could argue that XFRM decapsulation won't need a mark to select the
SA, as the SPI uniquely identifies the inbound SA. This is, however, not
how XFRM processes marks on inbound traffic.

strongSwan sets the mark both on the inbound policy and the SA, and to
match traffic, the mark must match as well. This means you'll need to
tag packets accordingly on the input path.

On the output path it is rather obvious that a mark is needed, as two
identical policies with different marks both would match otherwise.
Setting the mark explicitly allows you to select the correct outgoing
policy and the associated SA.

Some years ago I've made a similar chart [2] to the very fine one you
have linked. It is a little simpler and more related to IPsec, but gives
a good overview over Netfilter hooks and IPsec processing.

> For marks to work correctly, you need to:
> *Mark esp packets or espinudp packets in *mangle PREROUTING or *mangle INPUT.
> *Mark traffic that is just forwarded on the box in *mangle POSTROUTING
> *Mark traffic that originates from the box in *mangle OUTPUT

I think this is correct. There are certainly different approaches, and
tagging packets in FORWARDING might work as well for outgoing traffic.
Also it is possible to involve Netfilter policy matching (-m policy),
but one has to take care to not match on such policies to select the
same policy with a mark.

Also I've done some experiments regarding redundant IPsec policies using
marks; that code might be interesting in one or another form for your
work [3]. Of course just using updown with iptables can work as well,
you won't notice SPI changes during rekeying with that approach, though.

In that code, I install all SAs with a unique mark. For conflicting
(transport mode) policies, the connmark plugin stores the mark for
client-initiated conntrack connections on the connection. On the return
path the conntrack mark is restored to select the outgoing SA by the
same mark. Basically this allows you to have conflicting policies, and
make sure conntrack connections get bound to a CHILD_SA. Mostly useful
for L2TP/IPsec, where two clients behind the same NAT use identical SAs
to protect the L2TP conversation.

Regards
Martin

[2]http://download.strongswan.org/misc/netfilter.pdf
[3]http://git.strongswan.org/?p=strongswan.git;a=shortlog;h=refs/heads/connmark



More information about the Users mailing list