[strongSwan] Connections with marks and iptables

[Noel Kuntze]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello Martin,

Thank you for your response.
I wrote this email so this at least was documented _somewhere_ publicly.
The test scenarios for marks [1] [2]  don't show what iptables rules were used.
It would be quite nice to have this documented on the wiki somewhere, so people
can easily find it.
I looked at your branch in the repo and it looks quite interesting.
Does your connmark approach check for marks that are used in any iptables rule or policy based
routing already?


Mit freundlichen Grüßen/Regards,
Noel Kuntze

GPG Key ID: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658

Am 26.11.2014 um 14:51 schrieb Martin Willi:
> 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
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJUdhzYAAoJEDg5KY9j7GZYGg0P/jMruvVaFnQoPDhGrQVje2CZ
+YsqUGlaoI1FiSCT4dmlrv6t7lCwwhswYA3rLOGP0l3y4QMFHGqVnQGlNVFjFo++
+t+/sdiT7+HwhUGdcArWUboa3PgVKHEcJ81wYdQeSJMnTakrSxsJU7XmnRR69gZc
AJKGIDtPlHTfX3cu7fy6r5FmOYzzoe8UNPupD8XRSB0r0Y7DGCOPx1uvjwWKlabF
7etqJeem7jt2AcWVwD3ygzDhcPMuMIxz72pgTuZ2Ac32RB4GgP6f6C7dYWJ2eQ0G
O2lAuHWhHNJYcPLukNadmWKh26Eja1qKqVD+CSCWLOaZJzGCbzM2f2GEbnmxQHXn
AStkKCxtw1fwm0d4FmS/eNvsiNjcdP+mClMtJU5VQ/6KlTbigEr9xhhOa91EJcLS
V/G5VCcA+szRbVbkTNiht1V5wpdNMgaHWm+jPVAveIqxxkAVGqr9NzyrHKTd2/nB
oDnH9Yg2smU1/vq7dAf6k9xdKaStbVj4bR/YQGQ3GUbjzK6tz1YVvD3fYjzdlwL4
gkVeKYHfVsfmNZekSlDT1Xwl0YFM+o38AiLyBvw5sWMRYudw3fpEt3hRXyAPoSU3
GsabQkT833LxH5+h1MYansIqSAIFWEN/z7P1lDIQF9W0bXnYbkgMoN54tJWt0SzR
jhLPkLhazcKQyg1xmXsQ
=+iWd
-----END PGP SIGNATURE-----