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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>>> _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
