[strongSwan] Difficulties in Replacing ipsec-tools with strongSwan for Cloud Foundry
Marwinski, Dirk
dirk.marwinski at sap.com
Wed Jan 4 09:39:53 CET 2017
Hi,
I am trying to port the Cloud Foundry bosh ipsec release from ipsec-tools
from
https://github.com/SAP/ipsec-release
to strongSwan. The bosh ipsec release is used to secure all network traffic
within a Cloud Foundry landscape using the IPsec transport mode. This is
easier than making sure to secure each connection that may exist between
hosts in the landscape.
In trying to do so I have hit two difficulties which strongSwan that I will
elaborate in detail below. Any comments and hints would be highly
appreciated:
(1) As "right" or remote I need to specify a range or CIDR and not a single
hosts. According to the documentation this should be possible, however it
appears not. I also did not find an example for this in the test suite. I
do suspect that this might a be a bug. Can you confirm this?
(2) The SPD supports a "level" setting. In transport mode strongSwan sets
this to "required" and I did not find a way to change this to "use" which is
also possible. I guess this is would be an enhancement request (which I would
offer to contribute).
I am rather new so please apologize if I do overlook the obvious... It
appears that tunnel mode is by far the dominant use case and there is not
much that I did find on the transport mode. Configurations are at the bottom
of this email for reference.
To (1):
CIDRs or Ranges for Remote Endpoints
Cloud Foundry installations are partitioned in smaller and larger networks.
All possible network addresses are known in advance, however those could be
hundreds or even thousands so it is easier to just use the CIDR, e.g.
10.1.0.0/8 to ensure that all traffic that is going to any host in that
network will be "transport" encrypted. According to the documentation (or
how I interpret it) this should be possible. From
https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection:
Since 5.1.1 connections can be limited to a specific range of hosts. To
do so a range (10.1.0.0-10.2.255.255) or a subnet (10.1.0.0/16) can be
specified, and multiple addresses, ranges and subnets can be separated by
commas. While one can freely combine these items, to initiate the
connection at least one non-range/subnet is required.
When using the CIDR 10.1.0.0/8 above instead of a host name (e.g. 10.1.0.6)
the following entries are made into the SPD (ip xfrm policy list):
src 0.0.0.0/0 dst 0.0.0.0/0 uid 0
dir in action allow index 312 priority 300000 share any flag (0x00000000)
lifetime config:
limit: soft (INF)(bytes), hard (INF)(bytes)
limit: soft (INF)(packets), hard (INF)(packets)
expire add: soft 0(sec), hard 0(sec)
expire use: soft 0(sec), hard 0(sec)
lifetime current:
0(bytes), 0(packets)
add 2017-01-03 16:45:14 use -
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp spi 0x00000000(0) reqid 1(0x00000001) mode transport
level required share any
enc-mask ffffffff auth-mask ffffffff comp-mask ffffffff
src 0.0.0.0/0 dst 0.0.0.0/0 uid 0
dir out action allow index 305 priority 300000 share any flag (0x00000000)
lifetime config:
limit: soft (INF)(bytes), hard (INF)(bytes)
limit: soft (INF)(packets), hard (INF)(packets)
expire add: soft 0(sec), hard 0(sec)
expire use: soft 0(sec), hard 0(sec)
lifetime current:
0(bytes), 0(packets)
add 2017-01-03 16:45:14 use -
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp spi 0x00000000(0) reqid 1(0x00000001) mode transport
level required share any
enc-mask ffffffff auth-mask ffffffff comp-mask ffffffff
With that "all hell breaks loose" as an attempt is made to secure all traffic
anywhere which breaks all network connectivity.
I would have expected something like from "ip xfrm policy":
src 10.1.0.0/8 dst 192.168.1.7 uid 0
[...]
src 192.168.1.7 dst 10.1.0.0/8 uid 0
[...]
These are some glimpses at the log:
Jan 3 16:45:14 05[CFG] conn host-net
Jan 3 16:45:14 05[CFG] left=192.168.1.7
Jan 3 16:45:14 05[CFG] leftid=*
Jan 3 16:45:14 05[CFG] leftcert=cert.crt
Jan 3 16:45:14 05[CFG] right=10.1.0.0/8
Jan 3 16:45:14 05[CFG] rightauth=pubkey
Jan 3 16:45:14 05[CFG] rightid=*
Jan 3 16:45:14 05[CFG] rightca=C=DE, ST=Some-State, L=Walldorf, O=SAP SE
Jan 3 16:45:14 05[CFG] ike=aes128-sha256-modp3072
Jan 3 16:45:14 05[CFG] esp=aes256-sha256-modp4096!
Jan 3 16:45:14 05[CFG] dpddelay=30
Jan 3 16:45:14 05[CFG] dpdtimeout=150
Jan 3 16:45:14 05[CFG] dpdaction=3
Jan 3 16:45:14 05[CFG] mediation=no
Jan 3 16:45:14 05[CFG] keyexchange=ikev2
[...]
Jan 3 16:45:14 10[CFG] received stroke: route 'host-net'
Jan 3 16:45:14 10[CFG] proposing traffic selectors for us:
Jan 3 16:45:14 10[CFG] 0.0.0.0/0
Jan 3 16:45:14 10[CFG] proposing traffic selectors for other:
Jan 3 16:45:14 10[CFG] 0.0.0.0/0
Jan 3 16:45:14 10[CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ
Jan 3 16:45:14 10[KNL] adding policy 0.0.0.0/0 === 0.0.0.0/0 out [priority 300000, refcount 1]
The described approach works fine with the ipsec-tools (setkey to propagate
the SPD and racoon as the IKE daemon) and I am sure the ip xfrm command can
do this as well. I do suspect this to be a bug.
To (2):
level "use" mode
As I found little documentation on this I do suspect (and I have validated
this though try-and-error) that his is a "maybe" mode which means that an
attempt is made to negotiate a secure connection (using IKE) and in case this
fails an unsecured connection is established.
While this sounds rather strange it is very useful to activate IPsec in a
Cloud Foundry environment without causing a downtime of the system (which is
generally not such a good idea in cloud environments). The recommended way
for doing this in a Cloud Foundry environment is to set level to "use",
redeploy the system once (which does not cause a downtime) and set it to
"required" and redeploy it again. Setting it to "required" right away will
cause an indefinite deadlock as all components are deployed in a defined order
and newly deployed components cannot communicate with comoponents which have
not been updated already and vice versa.
Any help on this would be highly appreciated. The above mentioned release
based on ipsec-tools works fine, however there has been some criticism
towards ipsec-tools which I do share:
https://lists.debian.org/debian-devel/2014/04/msg00075.html
Best regards,
Dirk Marwinski
---------------------------
Configurations:
Version:
--------
root at ipsec-bosh-1:/var/vcap/etc# ipsec version
Linux strongSwan U5.5.1/K3.13.0-96-generic
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil, Switzerland
See 'ipsec --copyright' for copyright information.
These are the configurations for hosts in 192.168.0.0/8 and 10.1.0.0/8
(note I am still struggling with certificate authentication but this is not
subject of my mail here):
ipsec.conf (on 192.168.1.7)
-------------------------------------------------------------------------
# ipsec.conf - strongSwan IPsec configuration file
config setup
charondebug = 4
conn %default
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyingtries=1
mobike=no
keyexchange=ikev2
dpdaction=restart
esp=aes256-sha256-modp4096!
ike=aes256-sha256-modp4096!
aggressive=no
type=transport
auto=route
rightauth=pubkey
rightca="C=DE, ST=Some-State, L=Walldorf, O=SAP SE"
leftcert=cert.crt
conn host-net
left=192.168.1.7
right=10.1.0.0/8
#right=10.1.0.6 -- host-host works fine
rightid=*
leftid=*
-------------------------------------------------------------------------
ipsec.conf (on 10.1.0.6)
-------------------------------------------------------------------------
# ipsec.conf - strongSwan IPsec configuration file
config setup
charondebug = 1
conn %default
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyingtries=1
mobike=no
keyexchange=ikev2
dpdaction=restart
esp=aes256-sha256-modp4096!
ike=aes256-sha256-modp4096!
aggressive=no
type=transport
auto=route
leftauth=pubkey
rightauth=pubkey
rightca="C=DE, ST=Some-State, L=Walldorf, O=SAP SE"
conn host-host
left=10.1.0.6
leftcert=cert.crt
right=192.168.1.0/8
#right=192.168.1.7 -- host-host works fine
rightid=*
leftid=*
More information about the Users
mailing list