Thursday, January 28, 2016

Upgrading from Debian 6 Openswan to Debian 8 Strongswan

When upgrading from Debian 6 to Debian 8, then IPSEC softwarestack is changed from Openswan to Strongswan.
The switch itself is not a big thing, but when you still have other Openswan IPSEC partners, you will have to change your Strongswan config a little bit.
Otherwise the two IPSEC implementations won't be able to build the VPN tunnel.

On the Openswan end of the VPN you will see such messages in your auth.log file:

Jan 28 11:58:55 fw pluto[1279]: "vpn01" #746: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW to replace #670 {using isakmp#4 msgid:6c3f1671 proposal=defaults pfsgroup=OAKLEY_GROUP_MODP2048}
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #669: max number of retransmissions (2) reached STATE_QUICK_I1.  No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #669: starting keying attempt 5 of an unlimited number
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #747: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW to replace #669 {using isakmp#4 msgid:23eb99a9 proposal=defaults pfsgroup=OAKLEY_GROUP_MODP2048}
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #4: ignoring informational payload, type NO_PROPOSAL_CHOSEN msgid=00000000
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #4: received and ignored informational message
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #4: ignoring informational payload, type NO_PROPOSAL_CHOSEN msgid=00000000
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #4: received and ignored informational message
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #4: ignoring informational payload, type NO_PROPOSAL_CHOSEN msgid=00000000


On the Strongswan side, you see this in the daemon.log:

Jan 28 12:16:52 vpn01 ipsec[13909]: 09[IKE] no matching proposal found, sending NO_PROPOSAL_CHOSEN
Jan 28 12:16:52
vpn01 ipsec[13909]: 09[ENC] generating INFORMATIONAL_V1 request 2468276578 [ HASH N(NO_PROP) ]

This is dues to some IKE mismatch (The OpenSWAN IKEv2 implementation has does not respect all standards)
You can solve this issue by specifying IKEv1 for the connection in your ipsec.conf on the Strongswan side:

keyexchange=ikev1

This should solve the problem.
Sometimes (Depending the Openswan setttings) you also have to add this to your connection  definition on the Strongswan side:

esp=aes128-sha1-modp2048!