[strongSwan] several questions and problems ;)

Andreas Steffen andreas.steffen at strongswan.org
Sun Oct 3 13:11:40 CEST 2010


On 10/03/2010 02:51 AM, Christoph Anton Mitterer wrote:
> Hi.
>
> I want to do about the following:
> I have several servers in different networks (typically all with static
> IPs). These should set up encrypted and authenticated connections between
> each others (best using their global IPs).
> So AFAIU this boils down to a host-to-host scenario using ESP in tunnel
> mode.
> Also, it's very important that any non-encrypted/signed (thus any non-ESP)
> packets between such a host pair is not possible (incomming and outgoing).
> And the server should automatically set up the connections, constantly
> check whether it's still up, and forever try to re-establish it in case of
> failures.
>
> I've read all the documentation and came to the following config-files.
> I guess strongswan.conf is rather irrelevant for all this.
> ipsec.conf for hostA looks like this:
> (with comments and questions inline)
> config setup
> 	#pluto/IKEv1 and charon/IKEv2
> 	##dumpdir =
> 	#strictcrlpolicy = ifuri
> 	##cachecrls = no
> 	##uniqueids = yes
> 	
> 	
> 	#pluto/IKEv1
> 	plutostart = no
> 	
> 	##crlcheckinterval = 0s
> 	##keep_alive = 20s
> 	##nat_traversal = no
> 	##nocrsend = no
> 	
> 	##pkcs11keepstate = no
> 	##pkcs11proxy = no
> 	
> 	##plutodebug = none
> 	plutostderrlog = /var/log/pluto
> 	
> 	
> 	#charon/IKEv1
> 	##charonstart = yes
>
>
>
>
> #default settings
> conn %default
> 	auto = route
> 	
> 	keyexchange = ikev2
> 	ike = aes256gcm128-sha512-modp2048
> 	
> 	auth = esp
> 	#ah =
> 	esp = aes256gcm128-sha512-modp2048
> 	
> 	type = tunnel
> 	
> 	pfs = yes
> 	reauth = yes
> 	rekey = yes
> 	rekeyfuzz = 100%
> 	
> 	##compress = no
> 	##mobike = yes
> 	
> 	##forceencaps = no
> 	##installpolicy = yes
> 	##modeconfig = pull
> 	##xauth = client
> 	##mediation = no
> 	
> 	keyingtries = %forever
> 	ikelifetime = 3h
> 	#marginbytes =
> 	#marginpackets =
> 	margintime = 9m
> 	#lifebytes =
> 	#lifepackets =
> 	lifetime = 1h
> 	#inactivity =
> 	
> 	dpdaction = restart
> 	dpddelay = 30s
> 	dpdtimeout = 240s
> 	
> 	#mark =
> 	#mark_in =
> 	#mark_out =
> 	
> 	#pluto/IKEv1
> 	#pfsgroup =
> 	#authby = pubkey
> 	
> 	
> 	leftallowany = no
> 	rightallowany = no
> 	
> 	##leftikeport = 500
> 	##rightikeport = 500
> 	
> 	##leftsendcert = ifasked
>
>
> conn hostB
> 	auto = start
> 	
> 	left = %defaultroute
> 	leftcert = hostB.pem
> 	
> 	right = hostB.com
> 	rightid = "/CN=hostB"
> 	
> 	leftauth = pubkey
> 	rightauth = pubkey
> 	
> 	#leftfirewall = no
> 	#lefthostaccess = no
> 	#leftupdown = no
> ###########################################################################################
>
>
> 1) Does this sound reasonable for my setup from above, or have I made any
> stupid mistakes? Or bad decisions regarding security.
>
I recommend to use the '!' strict flag in the ike= and esp= cipher suite
definitions, thus restricting both the proposed and accepted algorithms
to those explicitly listed in the ike= and esp= statements.

>
> 2) The auto = start, dpdaction = restart and keyingtries = %forever
> settings make that even if one host goes down (temporarily) the other tries
> to re-setup the connection "forever", right? Those lifetime/margin settings
> are however just for how long it takes until new keys are exchanged, right?
>
Yes, that's correct.

>
> 3) Both hosts have auto = start... it seems now, that two connections are
> established then:
> # ipsec statusall
> Status of IKEv2 charon daemon (strongSwan 4.4.1):
>    uptime: 75 seconds, since Oct 03 02:09:18 2010
>    malloc: sbrk 380928, mmap 0, used 265392, free 115536
>    worker threads: 7 idle of 16, job queue load: 0, scheduled events: 7
>    loaded plugins: curl ldap aes des sha1 sha2 md5 random x509 pubkey pkcs1
> pgp dnskey pem openssl fips-prf xcbc hmac agent gmp attr resolve
> kernel-netlink socket-raw farp stroke updown eap-identity eap-aka eap-md5
> eap-gtc eap-mschapv2 dhcp
> Listening IP addresses:
>    84.16.235.61
>    84.16.242.145
>    84.16.226.65
>    84.16.242.146
> Connections:
> kronecker.scientia.net:  84.16.235.61...77.37.6.134, dpddelay=30s
> kronecker.scientia.net:   local:  [C=DE, ST=Freistaat Bayern,
> O=scientia.net, OU=Communications and Networking, CN=hilbert.scientia.net]
> uses public key authentication
> kronecker.scientia.net:    cert:  "C=DE, ST=Freistaat Bayern,
> O=scientia.net, OU=Communications and Networking, CN=hilbert.scientia.net"
> kronecker.scientia.net:   remote: [C=DE, ST=Freistaat Bayern,
> O=scientia.net, OU=Communications and Networking,
> CN=kronecker.scientia.net] uses public key authentication
> kronecker.scientia.net:   child:  dynamic === dynamic , dpdaction=restart
> Security Associations:
> kronecker.scientia.net[1]: ESTABLISHED 75 seconds ago, 84.16.235.61[C=DE,
> ST=Freistaat Bayern, O=scientia.net, OU=Communications and Networking,
> CN=hilbert.scientia.net]...77.37.6.134[C=DE, ST=Freistaat Bayern,
> O=scientia.net, OU=Communications and Networking,
> CN=kronecker.scientia.net]
> kronecker.scientia.net[1]: IKE SPIs: 1f588cc1c7326179_i*
> 205be6cc1c8e22c4_r, public key reauthentication in 2 hours
> kronecker.scientia.net[1]: IKE proposal:
> AES_CBC_128/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1024
> kronecker.scientia.net[2]: ESTABLISHED 70 seconds ago, 84.16.235.61[C=DE,
> ST=Freistaat Bayern, O=scientia.net, OU=Communications and Networking,
> CN=hilbert.scientia.net]...77.37.6.134[C=DE, ST=Freistaat Bayern,
> O=scientia.net, OU=Communications and Networking,
> CN=kronecker.scientia.net]
> kronecker.scientia.net[2]: IKE SPIs: e7f578c1348b6880_i
> 66130957c36ca5c8_r*, public key reauthentication in 2 hours
> kronecker.scientia.net[2]: IKE proposal:
> AES_CBC_128/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1024
>
> Why?
>
IKEv2 allows multiple concurrent IKE and IPsec SAs. If you want
only one IKE SA then I recommend to use auto=start on one side
and auto=add on the other side.

>
> 4) My logs makes me several concerns:
> Oct  3 02:09:17 hilbert charon: 00[DMN] Starting IKEv2 charon daemon
> (strongSwan 4.4.1)
> Oct  3 02:09:17 hilbert charon: 00[LIB] plugin 'test-vectors' failed to
> load: /usr/lib/ipsec/plugins/libstrongswan-test-vectors.so: cannot open
> shared object file: No such file or directory
> Oct  3 02:09:17 hilbert charon: 00[LIB] plugin 'revocation' failed to
> load: /usr/lib/ipsec/plugins/libstrongswan-revocation.so: cannot open
> shared object file: No such file or directory
> Oct  3 02:09:17 hilbert charon: 00[CFG] attr-sql plugin: database URI not
> set
> Oct  3 02:09:17 hilbert charon: 00[LIB] plugin 'attr-sql': failed to load
> - attr_sql_plugin_create returned NULL
> Oct  3 02:09:17 hilbert charon: 00[KNL] listening on interfaces:
> Oct  3 02:09:17 hilbert charon: 00[KNL]   eth0
> Oct  3 02:09:17 hilbert charon: 00[KNL]     84.16.235.61
> Oct  3 02:09:17 hilbert charon: 00[KNL]     84.16.242.145
> Oct  3 02:09:17 hilbert charon: 00[KNL]     84.16.226.65
> Oct  3 02:09:17 hilbert charon: 00[KNL]     84.16.242.146
> Oct  3 02:09:17 hilbert charon: 00[KNL]     fe80::80a7:3aff:fe36:3827
> Oct  3 02:09:17 hilbert charon: 00[CFG] loading ca certificates from
> '/etc/ipsec.d/cacerts'
> Oct  3 02:09:17 hilbert charon: 00[CFG]   loaded ca certificate "C=DE,
> ST=Freistaat Bayern, L=M?nchen, O=scientia.net, OU=Communications and
> Networking, CN=scientia.net Communications and Networking Temporary CA,
> E=root at scientia.net" from '/etc/ipsec.d/cacerts/scientia.net'
> Oct  3 02:09:17 hilbert charon: 00[CFG] loading aa certificates from
> '/etc/ipsec.d/aacerts'
> Oct  3 02:09:17 hilbert charon: 00[CFG] loading ocsp signer certificates
> from '/etc/ipsec.d/ocspcerts'
> Oct  3 02:09:17 hilbert charon: 00[CFG] loading attribute certificates
> from '/etc/ipsec.d/acerts'
> Oct  3 02:09:17 hilbert charon: 00[CFG] loading crls from
> '/etc/ipsec.d/crls'
> Oct  3 02:09:17 hilbert charon: 00[CFG] loading secrets from
> '/etc/ipsec.secrets'
> Oct  3 02:09:17 hilbert charon: 00[CFG]   loaded RSA private key from
> '/etc/ipsec.d/private/hilbert.scientia.net'
> Oct  3 02:09:17 hilbert charon: 00[CFG] sql plugin: database URI not set
> Oct  3 02:09:17 hilbert charon: 00[LIB] plugin 'sql': failed to load -
> sql_plugin_create returned NULL
> Oct  3 02:09:17 hilbert charon: 00[CFG] no valid RADIUS server
> configuration found
> Oct  3 02:09:17 hilbert charon: 00[LIB] plugin 'eap-radius': failed to
> load - eap_radius_plugin_create returned NULL
> Oct  3 02:09:17 hilbert charon: 00[CFG] mediation database URI not
> defined, skipped
> Oct  3 02:09:17 hilbert charon: 00[LIB] plugin 'medsrv': failed to load -
> medsrv_plugin_create returned NULL
> Oct  3 02:09:17 hilbert charon: 00[CFG] mediation client database URI not
> defined, skipped
> Oct  3 02:09:17 hilbert charon: 00[LIB] plugin 'medcli': failed to load -
> medcli_plugin_create returned NULL
> Oct  3 02:09:17 hilbert charon: 00[LIB] plugin 'nm' failed to load:
> /usr/lib/ipsec/plugins/libstrongswan-nm.so: cannot open shared object file:
> No such file or directory
> Oct  3 02:09:17 hilbert charon: 00[CFG] HA config misses local/remote
> address
> Oct  3 02:09:17 hilbert charon: 00[LIB] plugin 'ha': failed to load -
> ha_plugin_create returned NULL
> Oct  3 02:09:17 hilbert charon: 00[DMN] loaded plugins: curl ldap aes des
> sha1 sha2 md5 random x509 pubkey pkcs1 pgp dnskey pem openssl fips-prf xcbc
> hmac agent gmp attr resolve kernel-netlink socket-raw farp stroke updown
> eap-identity eap-aka eap-md5 eap-gtc eap-mschapv2 dhcp
>
> =>  many failed plugins which I don't wanna use (I guess ^^),... but this
> might be some Debian problems?
>
The Debian package enables a lot of plugins that are not properly
initialized. Therefore the loading fails and all these error messages
appear in the strongSwan log. This looks rather ugly but does not do
any actual harm, except if you actually want to use some of these
plugins (e.g. attr-sql for SQL-based virtual IP pools).

er threads
> Oct  3 02:09:17 hilbert charon: 08[CFG] received stroke: add connection
> 'kronecker.scientia.net'
> Oct  3 02:09:17 hilbert charon: 08[CFG]   loaded certificate "C=DE,
> ST=Freistaat Bayern, O=scientia.net, OU=Communications and Networking,
> CN=hilbert.scientia.net" from 'hilbert.scientia.net'
> Oct  3 02:09:17 hilbert charon: 08[CFG]   id '84.16.235.61' not confirmed
> by certificate, defaulting to 'C=DE, ST=Freistaat Bayern, O=scientia.net,
> OU=Communications and Networking, CN=hilbert.scientia.net'
> Oct  3 02:09:17 hilbert charon: 08[CFG] added configuration
> 'kronecker.scientia.net'
> Oct  3 02:09:17 hilbert charon: 11[CFG] received stroke: initiate
> 'kronecker.scientia.net'
> Oct  3 02:09:17 hilbert charon: 11[IKE] initiating IKE_SA
> kronecker.scientia.net[1] to 77.37.6.134
> Oct  3 02:09:17 hilbert charon: 11[ENC] generating IKE_SA_INIT request 0 [
> SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
> Oct  3 02:09:17 hilbert charon: 11[NET] sending packet: from
> 84.16.235.61[500] to 77.37.6.134[500]
> Oct  3 02:09:17 hilbert charon: 15[NET] received packet: from
> 77.37.6.134[500] to 84.16.235.61[500]
> Oct  3 02:09:17 hilbert charon: 15[ENC] parsed IKE_SA_INIT response 0 [ SA
> KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(MULT_AUTH) ]
> Oct  3 02:09:17 hilbert charon: 15[IKE] received cert request for "C=DE,
> ST=Freistaat Bayern, L=M?nchen, O=scientia.net, OU=Communications and
> Networking, CN=scientia.net Communications and Networking Temporary CA,
> E=root at scientia.net"
> Oct  3 02:09:17 hilbert charon: 15[IKE] sending cert request for "C=DE,
> ST=Freistaat Bayern, L=M?nchen, O=scientia.net, OU=Communications and
> Networking, CN=scientia.net Communications and Networking Temporary CA,
> E=root at scientia.net"
> Oct  3 02:09:17 hilbert charon: 15[IKE] authentication of 'C=DE,
> ST=Freistaat Bayern, O=scientia.net, OU=Communications and Networking,
> CN=hilbert.scientia.net' (myself) with RSA signature successful
> Oct  3 02:09:17 hilbert charon: 15[IKE] sending end entity cert "C=DE,
> ST=Freistaat Bayern, O=scientia.net, OU=Communications and Networking,
> CN=hilbert.scientia.net"
> Oct  3 02:09:17 hilbert charon: 15[IKE] establishing CHILD_SA
> kronecker.scientia.net
> Oct  3 02:09:17 hilbert charon: 15[ENC] generating IKE_AUTH request 1 [
> IDi CERT CERTREQ IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR)
> N(ADD_4_ADDR) N(ADD_4_ADDR) N(MULT_AUTH) N(EAP_ONLY) ]
>
> =>  Why does it say "(EAP_ONLY)" I thought I'd do only authentication based
> on certificate?
>
The EAP_ONLY notify message just advertises the potential capability to
support the RFC 5998 EAP-only protocol.

>
> Oct  3 02:09:17 hilbert charon: 15[NET] sending packet: from
> 84.16.235.61[4500] to 77.37.6.134[4500]
> Oct  3 02:09:18 hilbert charon: 16[NET] received packet: from
> 77.37.6.134[4500] to 84.16.235.61[4500]
> Oct  3 02:09:18 hilbert charon: 16[ENC] parsed IKE_AUTH response 1 [ IDr
> CERT AUTH N(AUTH_LFT) N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR)
> N(ADD_4_ADDR) N(NO_PROP) ]
> Oct  3 02:09:18 hilbert charon: 16[IKE] received end entity cert "C=DE,
> ST=Freistaat Bayern, O=scientia.net, OU=Communications and Networking,
> CN=kronecker.scientia.net"
> Oct  3 02:09:18 hilbert charon: 16[CFG]   using certificate "C=DE,
> ST=Freistaat Bayern, O=scientia.net, OU=Communications and Networking,
> CN=kronecker.scientia.net"
> Oct  3 02:09:18 hilbert charon: 16[CFG]   using trusted ca certificate
> "C=DE, ST=Freistaat Bayern, L=M?nchen, O=scientia.net, OU=Communications
> and Networking, CN=scientia.net Communications and Networking Temporary CA,
> E=root at scientia.net"
> Oct  3 02:09:18 hilbert charon: 16[CFG]   reached self-signed root ca with
> a path length of 0
> Oct  3 02:09:18 hilbert charon: 16[IKE] authentication of 'C=DE,
> ST=Freistaat Bayern, O=scientia.net, OU=Communications and Networking,
> CN=kronecker.scientia.net' with RSA signature successful
> Oct  3 02:09:18 hilbert charon: 16[IKE] IKE_SA kronecker.scientia.net[1]
> established between 84.16.235.61[C=DE, ST=Freistaat Bayern, O=scientia.net,
> OU=Communications and Networking,
> CN=hilbert.scientia.net]...77.37.6.134[C=DE, ST=Freistaat Bayern,
> O=scientia.net, OU=Communications and Networking,
> CN=kronecker.scientia.net]
> Oct  3 02:09:18 hilbert charon: 16[IKE] scheduling reauthentication in
> 9992s
> Oct  3 02:09:18 hilbert charon: 16[IKE] maximum IKE_SA lifetime 10532s
> Oct  3 02:09:18 hilbert charon: 16[IKE] received NO_PROPOSAL_CHOSEN
> notify, no CHILD_SA built
> Oct  3 02:09:18 hilbert charon: 16[IKE] received AUTH_LIFETIME of 9893s,
> scheduling reauthentication in 9353s
> Oct  3 02:09:18 hilbert charon: 16[IKE] peer supports MOBIKE
> Oct  3 02:09:22 hilbert charon: 08[NET] received packet: from
> 77.37.6.134[500] to 84.16.235.61[500]
> Oct  3 02:09:22 hilbert charon: 08[ENC] parsed IKE_SA_INIT request 0 [ SA
> KE No N(NATD_S_IP) N(NATD_D_IP) ]
> Oct  3 02:09:22 hilbert charon: 08[IKE] 77.37.6.134 is initiating an
> IKE_SA
> Oct  3 02:09:22 hilbert charon: 08[IKE] sending cert request for "C=DE,
> ST=Freistaat Bayern, L=M?nchen, O=scientia.net, OU=Communications and
> Networking, CN=scientia.net Communications and Networking Temporary CA,
> E=root at scientia.net"
> Oct  3 02:09:22 hilbert charon: 08[ENC] generating IKE_SA_INIT response 0
> [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(MULT_AUTH) ]
>
> =>  Do these NAT* messages mean, that the NAT-case was detected (which
> should not be the case I guess?
>
No, these NAT messages are IP address hashes used to detect
NAT situations. They are always sent by default.

>
> Oct  3 02:09:22 hilbert charon: 08[NET] sending packet: from
> 84.16.235.61[500] to 77.37.6.134[500]
> Oct  3 02:09:23 hilbert charon: 11[NET] received packet: from
> 77.37.6.134[4500] to 84.16.235.61[4500]
> Oct  3 02:09:23 hilbert charon: 11[ENC] parsed IKE_AUTH request 1 [ IDi
> CERT CERTREQ IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR)
> N(ADD_4_ADDR) N(MULT_AUTH) N(EAP_ONLY) ]
> Oct  3 02:09:23 hilbert charon: 11[IKE] received cert request for "C=DE,
> ST=Freistaat Bayern, L=M?nchen, O=scientia.net, OU=Communications and
> Networking, CN=scientia.net Communications and Networking Temporary CA,
> E=root at scientia.net"
> Oct  3 02:09:23 hilbert charon: 11[IKE] received end entity cert "C=DE,
> ST=Freistaat Bayern, O=scientia.net, OU=Communications and Networking,
> CN=kronecker.scientia.net"
> Oct  3 02:09:23 hilbert charon: 11[CFG] looking for peer configs matching
> 84.16.235.61[C=DE, ST=Freistaat Bayern, O=scientia.net, OU=Communications
> and Networking, CN=hilbert.scientia.net]...77.37.6.134[C=DE, ST=Freistaat
> Bayern, O=scientia.net, OU=Communications and Networking,
> CN=kronecker.scientia.net]
> Oct  3 02:09:23 hilbert charon: 11[CFG] selected peer config
> 'kronecker.scientia.net'
> Oct  3 02:09:23 hilbert charon: 11[CFG]   using certificate "C=DE,
> ST=Freistaat Bayern, O=scientia.net, OU=Communications and Networking,
> CN=kronecker.scientia.net"
> Oct  3 02:09:23 hilbert charon: 11[CFG]   using trusted ca certificate
> "C=DE, ST=Freistaat Bayern, L=M?nchen, O=scientia.net, OU=Communications
> and Networking, CN=scientia.net Communications and Networking Temporary CA,
> E=root at scientia.net"
> Oct  3 02:09:23 hilbert charon: 11[CFG]   reached self-signed root ca with
> a path length of 0
> Oct  3 02:09:23 hilbert charon: 11[IKE] authentication of 'C=DE,
> ST=Freistaat Bayern, O=scientia.net, OU=Communications and Networking,
> CN=kronecker.scientia.net' with RSA signature successful
> Oct  3 02:09:23 hilbert charon: 11[IKE] peer supports MOBIKE
> Oct  3 02:09:23 hilbert charon: 11[IKE] authentication of 'C=DE,
> ST=Freistaat Bayern, O=scientia.net, OU=Communications and Networking,
> CN=hilbert.scientia.net' (myself) with RSA signature successful
> Oct  3 02:09:23 hilbert charon: 11[IKE] IKE_SA kronecker.scientia.net[2]
> established between 84.16.235.61[C=DE, ST=Freistaat Bayern, O=scientia.net,
> OU=Communications and Networking,
> CN=hilbert.scientia.net]...77.37.6.134[C=DE, ST=Freistaat Bayern,
> O=scientia.net, OU=Communications and Networking,
> CN=kronecker.scientia.net]
> Oct  3 02:09:23 hilbert charon: 11[IKE] scheduling reauthentication in
> 10073s
> Oct  3 02:09:23 hilbert charon: 11[IKE] maximum IKE_SA lifetime 10613s
> Oct  3 02:09:23 hilbert charon: 11[IKE] sending end entity cert "C=DE,
> ST=Freistaat Bayern, O=scientia.net, OU=Communications and Networking,
> CN=hilbert.scientia.net"
>
>
> Oct  3 02:09:23 hilbert charon: 11[KNL] received netlink error: Function
> not implemented (38)
> Oct  3 02:09:23 hilbert charon: 11[KNL] unable to add SAD entry with SPI
> c298c943
> Oct  3 02:09:23 hilbert charon: 11[KNL] received netlink error: Function
> not implemented (38)
> Oct  3 02:09:23 hilbert charon: 11[KNL] unable to add SAD entry with SPI
> c283d3bc
> Oct  3 02:09:23 hilbert charon: 11[IKE] unable to install inbound and
> outbound IPsec SA (SAD) in kernel
> Oct  3 02:09:23 hilbert charon: 11[KNL] received netlink error: No such
> process (3)
> Oct  3 02:09:23 hilbert charon: 11[KNL] unable to delete SAD entry with
> SPI c283d3bc
>
> =>  This sounds bad? Any ideas?
>
Which Linux kernel are you using? SHA_256_128, SHA_384_192 and
SHA_512_256 were introduced with the 2.6.33 kernel. Earlier kernels only
support a non-standard SHA_256_96 integrity algorithm.

> Oct  3 02:09:23 hilbert charon: 11[ENC] generating IKE_AUTH response 1 [
> IDr CERT AUTH N(AUTH_LFT) N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR)
> N(ADD_4_ADDR) N(NO_PROP) ]
> Oct  3 02:09:23 hilbert charon: 11[NET] sending packet: from
> 84.16.235.61[4500] to 77.37.6.134[4500]
> Oct  3 02:09:47 hilbert charon: 01[NET] received packet: from
> 77.37.6.134[4500] to 84.16.235.61[4500]
> Oct  3 02:09:47 hilbert charon: 01[ENC] parsed INFORMATIONAL request 0 [ ]
> Oct  3 02:09:47 hilbert charon: 01[ENC] generating INFORMATIONAL response
> 0 [ ]
> Oct  3 02:09:47 hilbert charon: 01[NET] sending packet: from
> 84.16.235.61[4500] to 77.37.6.134[4500]
> Oct  3 02:09:53 hilbert charon: 14[IKE] sending DPD request
> Oct  3 02:09:53 hilbert charon: 14[ENC] generating INFORMATIONAL request 0
> [ ]
> Oct  3 02:09:53 hilbert charon: 14[NET] sending packet: from
> 84.16.235.61[4500] to 77.37.6.134[4500]
> Oct  3 02:09:53 hilbert charon: 08[NET] received packet: from
> 77.37.6.134[4500] to 84.16.235.61[4500]
> Oct  3 02:09:53 hilbert charon: 08[ENC] parsed INFORMATIONAL response 0 [
> ]
>
> =>  Guess the connection is now established, isn't it?
>
No, the CHILD_SA was not established.

>
> 5) What's the best way to solve this:
> hostA and hostB each have multiple (actually 4) IP addresses, and I want
> to configure secured connections between all possible cominations of them?
>
>
> 6) AFAIU with the in kernel IPsec stack, there are no virtual interfaces
> or manual routes beeing added, right? At least my
> 84.16.235.0/24 dev eth0  proto kernel  scope link  src 84.16.235.61
> 84.16.226.0/24 dev eth0  proto kernel  scope link  src 84.16.226.65
> 84.16.242.0/24 dev eth0  proto kernel  scope link  src 84.16.242.145
> default via 84.16.235.1 dev eth0
>
With IPsec you can have only one active IPsec tunnel between two hosts.
The RFC 4555 MOBIKE protocol will automatically switch to another
interface pair if the active connection goes down.

> shows me just my "normal" routes.
>
>
> 7) With this setup, is it already guaranteed that e.g. if hostB's
> strongswan crashes, hostA never sends unsecured packages to hostB? I mean
> because hostA then tries to re-establish that connection (which might not
> work however) but then, no packages are sent?
>
The strongSwan daemon is not supposed to crash. And even if it does, the
IPsec policies will still exist. In order to make sure that no
unencrypted packets leave the host you can define a default block policy
using the ip xfrm policy add command.

>
> Thanks so far :)
>
> Cheers,
> Chris.

Regards

Andreas

======================================================================
Andreas Steffen                         andreas.steffen at strongswan.org
strongSwan - the Linux VPN Solution!                www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[ITA-HSR]==




More information about the Users mailing list