[strongSwan] Windows 7 seems to drop connection when rekeying main mode SA's
Hans-Kristian Bakke
hkbakke at gmail.com
Wed Jan 11 12:05:29 CET 2012
I think I have found the issue, and I actually think it's my
vpn-server IP...%any on all 3 connections that ruins things for me
again (they also prevents me from using ! because the first one
overrides the later ones)
During the setup when the VPN-server is getting the IKE proposals I
get the following after the first connection:
Jan 11 11:17:34 firewall charon: 10[CFG] <16> looking for an ike
config for 77.106.149.54...82.147.51.146
Jan 11 11:17:34 firewall charon: 10[CFG] <16> candidate:
77.106.149.54...%any, prio 5
Jan 11 11:17:34 firewall charon: 10[CFG] <16> candidate:
77.106.149.54...%any, prio 5
Jan 11 11:17:34 firewall charon: 10[CFG] <16> candidate:
77.106.149.54...%any, prio 5
Jan 11 11:17:34 firewall charon: 10[CFG] <16> found matching ike
config: 77.106.149.54...%any with prio 5
Jan 11 11:17:34 firewall charon: 10[IKE] <16> 82.147.51.146 is
initiating an IKE_SA
Jan 11 11:17:34 firewall charon: 10[IKE] <16> IKE_SA (unnamed)[16]
state change: CREATED => CONNECTING
Jan 11 11:17:34 firewall charon: 10[CFG] <16> selecting proposal:
Jan 11 11:17:34 firewall charon: 10[CFG] <16> no acceptable
ENCRYPTION_ALGORITHM found
Jan 11 11:17:34 firewall charon: 10[CFG] <16> selecting proposal:
Jan 11 11:17:34 firewall charon: 10[CFG] <16> no acceptable
INTEGRITY_ALGORITHM found
Jan 11 11:17:34 firewall charon: 10[CFG] <16> selecting proposal:
Jan 11 11:17:34 firewall charon: 10[CFG] <16> no acceptable
ENCRYPTION_ALGORITHM found
Jan 11 11:17:34 firewall charon: 10[CFG] <16> selecting proposal:
Jan 11 11:17:34 firewall charon: 10[CFG] <16> no acceptable
INTEGRITY_ALGORITHM found
Jan 11 11:17:34 firewall charon: 10[CFG] <16> selecting proposal:
Jan 11 11:17:34 firewall charon: 10[CFG] <16> no acceptable
ENCRYPTION_ALGORITHM found
Jan 11 11:17:34 firewall charon: 10[CFG] <16> selecting proposal:
Jan 11 11:17:34 firewall charon: 10[CFG] <16> no acceptable
INTEGRITY_ALGORITHM found
Jan 11 11:17:34 firewall charon: 10[CFG] <16> selecting proposal:
Jan 11 11:17:34 firewall charon: 10[CFG] <16> proposal matches
Jan 11 11:17:34 firewall charon: 10[CFG] <16> received proposals:
IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024,
IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024,
IKE:3DES_CBC/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024,
IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024,
IKE:3DES_CBC/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024,
IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024
Jan 11 11:17:34 firewall charon: 10[CFG] <16> configured proposals:
IKE:AES_CBC_256/AES_XCBC_96/PRF_AES128_XCBC/ECP_521,
IKE:AES_CBC_128/AES_CBC_192/AES_CBC_256/3DES_CBC/CAMELLIA_CBC_128/CAMELLIA_CBC_192/CAMELLIA_CBC_256/AES_CTR_128/AES_CTR_192/AES_CTR_256/CAMELLIA_CTR_128/CAMELLIA_CTR_192/CAMELLIA_CTR_256/AES_XCBC_96/HMAC_SHA1_96/HMAC_SHA2_256_128/HMAC_MD5_96/HMAC_SHA2_384_192/HMAC_SHA2_512_256/PRF_AES128_XCBC/PRF_HMAC_SHA1/PRF_HMAC_SHA2_256/PRF_HMAC_MD5/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/MODP_2048/MODP_2048_224/MODP_2048_256/MODP_1536/ECP_256/ECP_384/ECP_521/ECP_224/ECP_192/MODP_4096/MODP_8192/MODP_1024/MODP_1024_160
Jan 11 11:17:34 firewall charon: 10[CFG] <16> selected proposal:
IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
....
and it continues until it has gone through all the candidates and found a match.
I also noted that no matter what ike= parameter I use for my rw-win-7
connection it doesn't take. It always goes back to 3des-sha1-modp1024.
But when I reorganized my configuration file and moved my rw-win-7 to
the top of the connection list it suddendly work, so now I can use
aes256-sha384-modp1024.
If I understood the rekey document correctly, Windows 7 is only
accepting rekey attempts on IKE SA if modp1024 is successful on the
first attempt. In my case it has to go through 3 iterations of no
acceptable *_ALGORITHM first.
Could this be the problem?
I therefore suspect that everything works correctly if the left/right
pairs is different for all connections, but in my case they are all
the same.
Is there any recommended way to handle this situation? It obviously
makes a mess out of ike= and esp= handling.
Regards,
Hans-Kristian Bakke
On Wed, Jan 11, 2012 at 09:51, Hans-Kristian Bakke <hkbakke at gmail.com> wrote:
> I have now investigated things further..
>
> CHILD_SAs is rekeyed successfully.
> IKE_SAs however is not. This is what happens when the Strongswan host
> (Debian, strongswan v4.5.2) is initiating a rekey of the IKE SAs.
>
> Jan 11 09:33:29 firewall charon: 09[IKE] <rw-win-7|3> queueing IKE_REKEY task
> Jan 11 09:33:29 firewall charon: 09[IKE] <rw-win-7|3> activating new tasks
> Jan 11 09:33:29 firewall charon: 09[IKE] <rw-win-7|3> activating
> IKE_REKEY task
> Jan 11 09:33:29 firewall charon: 09[IKE] <rw-win-7|3> IKE_SA
> rw-win-7[3] state change: ESTABLISHED => REKEYING
> Jan 11 09:33:29 firewall charon: 09[IKE] <rw-win-7|3> initiating
> IKE_SA rw-win-7[4] to 82.147.51.146
> Jan 11 09:33:29 firewall charon: 09[IKE] <rw-win-7|3> IKE_SA
> rw-win-7[4] state change: CREATED => CONNECTING
> Jan 11 09:33:29 firewall charon: 14[IKE] <rw-win-7|3> received DELETE
> for IKE_SA rw-win-7[3]
> Jan 11 09:33:29 firewall charon: 14[IKE] <rw-win-7|3> deleting IKE_SA
> rw-win-7[3] between 77.106.149.54[C=NO, ST=Oppland, O=marsboer.net, O
> U=VPN server,
> CN=vpn.marsboer.net]...82.147.51.146[C=NO, ST=Oppland, O=marsboer.net,
> OU=Roadwarriors, CN=rw01.marsboer.net]
> Jan 11 09:33:29 firewall charon: 14[IKE] <rw-win-7|3> IKE_SA
> rw-win-7[3] state change: REKEYING => DELETING
> Jan 11 09:33:29 firewall charon: 14[IKE] <rw-win-7|3> IKE_SA deleted
> Jan 11 09:33:29 firewall charon: 14[IKE] <rw-win-7|4> IKE_SA
> rw-win-7[4] state change: CONNECTING => DESTROYING
> Jan 11 09:33:29 firewall charon: 14[IKE] <rw-win-7|3> IKE_SA
> rw-win-7[3] state change: DELETING => DESTROYING
>
> I also tried with and without reauth and it did not change the results.
> Withouth the strongswan host rekeying it seems like the Strongswan IKE
> SA just dies, and then the connection has to be reestablished.
> As soon as I reconnect the link is up again (done automatically after
> 1 minute on my Windows 7 host)
>
> This is the network configuration:
> Win 7 client (DHCP) -> NAT (hotspot fw, pfsense) -> NAT (main
> firewall, Cisco ASA) -> Internet -> VPN server (dyndns)
>
> Neither the DHCP address on the client or VPN server changed during my tests.
> This is the same path that one of my Strongswan servers also uses so
> it should be IKEv2 IPsec capable.
>
>
> This is my current configuration:
>
> # ipsec.conf - strongSwan IPsec configuration file
>
> # basic configuration
> config setup
> charonstart=yes
> plutostart=no
>
> # Add connections here.
> conn %default
> keyexchange=ikev2
> auth=esp
> authby=pubkey
> mobike=yes
> left=%defaultroute
> leftauth=pubkey
> leftcert=vpn-serverCert.pem
> leftfirewall=no
> type=tunnel
> dpdaction=clear
> dpddelay=300s
>
> conn rw-uranus
> leftsubnet=10.10.10.0/24,10.0.1.0/24,10.10.99.0/24,10.0.2.0/24
> right=%any
> rightsourceip=10.0.1.2
> rightid="C=NO, ST=Oppland, O=marsboer.net, OU=Backup server,
> CN=uranus.marsboer.net"
> auto=add
> ike=aes256-aesxcbc-ecp521
> esp=aes256gcm16-ecp521
> reauth=no
>
> conn rw-win-7
> leftsubnet=0.0.0.0/0
> right=%any
> rightsourceip=10.0.1.0/24
> rightid="C=NO, ST=Oppland, O=marsboer.net, OU=Roadwarriors,
> CN=rw01.marsboer.net"
> auto=add
> esp=aes256-sha1
> ikelifetime=90m
> reauth=no
>
> conn rw-europa
> leftsubnet=10.10.10.0/24,10.0.1.0/24,10.10.99.0/24,10.0.2.0/24
> right=%any
> rightsourceip=10.0.1.4
> rightid="C=NO, ST=Oppland, O=marsboer.net, OU=VPN fileserver,
> CN=europa.marsboer.net"
> auto=add
> ike=aes256-aesxcbc-ecp521
> esp=aes256gcm16-ecp521
> reauth=no
>
> Regards,
>
> Hans-Kristian Bakke
>
>
>
> On Tue, Jan 10, 2012 at 17:16, Hans-Kristian Bakke <hkbakke at gmail.com> wrote:
>> And one more thing:
>> The "Rekey"-document explains that the CHILD_SA rekey timer should be
>> more than 58m 46s if behind NAT and rekey active. This is the case in
>> my situation.
>> However, the configuration examples does not do anything to mitigate this.
>>
>> When the connection is newly started I can see that Strongswan wants
>> to rekey CHILD_SA in about 48m (or around that).
>>
>> Does this mean that I have to set the "lifetime" parameter for the
>> connection for i.e 90m (the default is 1h)
>>
>>
>> Mvh
>>
>> Hans-Kristian Bakke
>> Mob: 91 76 17 38
>>
>>
>>
>> On Tue, Jan 10, 2012 at 17:11, Hans-Kristian Bakke <hkbakke at gmail.com> wrote:
>>> Thank you for your response
>>>
>>> I have read that document and have more or less based my config on it.
>>> I have a couple of questions though:
>>>
>>> rekey is not mentioned in the X.509 example but is disabled in the
>>> EAP-MSCHAP example. I have now reactivated rekey in my configuration
>>> to test.
>>>
>>> I have set reauth to no because it made my strongswan to strongswan
>>> tunnel drop the connection for a short moment. It is not mentioned in
>>> the Windows 7 configuration.
>>> Will having it enabled (like in the config examples) cause drop outs
>>> during IKE SA renegotiations like I get using only strongswan?
>>>
>>> I now have rekey = on and reauth = on (default) to be as identical to
>>> the example configuration as possible.
>>> I will try using ! if it doesn't work, but in my case it will cause
>>> issues because it will override the ike/esp parameters in my other
>>> connections (older mailing list post, something to do with me having
>>> %any as right in all my connections if I remember correctly)
>>>
>>> When it happens again I will look at the logs. Do you want a
>>> particular log level or will the Debian default charon syslog do?
>>>
>>> Regards,
>>>
>>> Hans-Kristian Bakke
>>>
>>>
>>>
>>> On Tue, Jan 10, 2012 at 15:32, Martin Willi <martin at strongswan.org> wrote:
>>>> Hi,
>>>>
>>>>> After disabling rekeying for Windows 7 connection I got rid of most of
>>>>> the reconnects caused by rekeying the SAs, but I still have one
>>>>> annoying connection interruption left.
>>>>
>>>> When following the rules from [1], rekeying initiated by strongSwan
>>>> works fine here.
>>>>
>>>>> But for some reason IP Security Monitor on Windows 7 reports 10800s as
>>>>> main mode SA lifetime. Even if I change ikelifetime on the Strongswan
>>>>> server to i.e 8 or 12h it is still 3h.
>>>>
>>>> I don't know if you can trust the IP Security Monitor, as it is mainly
>>>> for IKEv1. Not sure if these 10800s are correct. Further, lifetimes are
>>>> never negotiated in IKEv2, you can't change the behavior of Windows by
>>>> defining an ikelifetime on strongSwan. It only changes the behavior of
>>>> rekeying initiated locally.
>>>>
>>>>> Now, the problem isn't really the 3h interval, it's that all the
>>>>> connections drop for a while until reconnect.
>>>>
>>>> Would be helpful to know exactly _what_ is happening every three hours.
>>>> Does Windows trigger a rekey? Does it drop the CHILD_SA, close the
>>>> IKE_SA? A strongSwan log output would be helpful.
>>>>
>>>>> ike=aes256-sha1-modp1024
>>>>> esp=aes256-sha1
>>>>
>>>> I'd try to limit the proposal list to exactly these by appending a '!'.
>>>> I'm not aware of any problems with our lengthy default proposal set, but
>>>> just in case.
>>>>
>>>> Regards
>>>> Martin
>>>>
>>>> [1]http://wiki.strongswan.org/projects/strongswan/wiki/Windows7#Rekeying-behavior
>>>>
More information about the Users
mailing list