Issue #260
strongswan 5.0.1 with apple's racoon (mountain lion) and PSK does not work after renegotiation of phase 1
Description
I am trying the following scenario:
server: Centos 6.3 with strongswan 5.0.1
client: Mac OSX Mountain Lion with built-in racoon VPN client
auth: PSK + Xauth
ipsec.conf:
config setup
conn %default
ikelifetime=24h
keylife=20m
rekeymargin=3m
keyingtries=1
keyexchange=ikev1
rekey = no
left=109.168.103.185
leftsubnet=192.168.8.0/24
auto=add
conn rw
leftid=@my.gateway.hostname
leftauth=psk
leftprotoport=%any
right=%any
rightsourceip=%vpnclients
rightauth=psk
rightauth2=xauth
rightprotoport=%any
auto=add
dpddelay=40
dpdtimeout=130
dpdaction=clear
strongswan.conf:
charon {
threads = 16
cisco_unity = yes
interfaces_use = eth0
plugins {
sql {
database = sqlite:///usr/local/etc/ipsec.d/ipsec.db
}
attr-sql {
database = sqlite:///usr/local/etc/ipsec.d/ipsec.db
}
}
}
pluto {
dns1 = 192.168.8.41
load = sha1 sha2 md5 aes des hmac gmp random nonce xauth-generic attr kernel-netlink socket-default stroke updown attr-sql
}
libhydra {
plugins {
attr-sql {
database = sqlite:///usr/local/etc/ipsec.d/ipsec.db
}
}
}
Everything works fine when initially negotiating connection. The mac prompts for xauth password, gets an IP address from the pool, and also the route, everything works like a charm, until racoon on the mac tries to renegotiate the SA.
Child SA negotiation works fine, but when racoon wants to renegotiate the main SA weird things happen.
In theory I could avoid this hassle by setting the SA lifetime to 24 hours or something like that, but unfortunately
the lifetime in Apple's racoon client is hardcoded to 1 hour. Someone published an hack to convince racoon to use a longer
lifetime but for some reason it is just ignored on my macbook... so I am stuck with a lifetime of 1 hour and every 50 minutes
the phase 1 negotiation is restarted on client side, and this breaks the VPN.
When racoon restarts the phase 1 negotiation it also repeats the xauth authentication and I am prompted with the xauth
password request again. Even if I input the password again, however, no more traffic goes through the VPN.
Some more info.
racoon.conf on macosx:
path include "/etc/racoon" ;
log debug;
# "padding" defines some parameter of padding. You should not touch these.
padding
{
maximum_length 20; # maximum padding length.
randomize off; # enable randomize length.
strict_check off; # enable strict check.
exclusive_tail off; # extract last one octet.
}
# Specification of default various timer.
timer
{
# These value can be changed per remote node.
counter 10; # maximum trying count to send.
interval 3 sec; # interval to resend (retransmit)
persend 1; # the number of packets per a send.
# timer for waiting to complete each phase.
phase1 30 sec;
phase2 30 sec;
# Auto exit delay timer - for use when controlled by VPN socket
auto_exit_delay 3 sec;
}
remote ::1 [8000]
{
#exchange_mode main,aggressive;
exchange_mode aggressive,main;
doi ipsec_doi;
situation identity_only;
my_identifier user_fqdn "macuser@localhost";
peers_identifier user_fqdn "macuser@localhost";
#certificate_type x509 "mycert" "mypriv";
nonce_size 16;
lifetime time 1 min; # sec,min,hour
proposal {
encryption_algorithm aes;
hash_algorithm sha1;
authentication_method pre_shared_key ;
dh_group 2 ;
}
}
sainfo address ::1 icmp6 address ::1 icmp6
{
pfs_group 1;
lifetime time 60 sec;
encryption_algorithm 3des, aes ;
authentication_algorithm hmac_sha1, hmac_md5 ;
compression_algorithm deflate ;
}
include "/var/run/racoon/*.conf" ;
the generated file in the above folder for my gateway:
remote x.x.x.x {
doi ipsec_doi;
situation identity_only;
exchange_mode main;
verify_identifier off;
shared_secret keychain "FC6D8EA9-5021-4041-9DC8-FB5C6B0B634A.SS";
nonce_size 16;
dpd_delay 20;
dpd_retry 5;
dpd_maxfail 5;
dpd_algorithm dpd_blackhole_detect;
initial_contact on;
support_proxy on;
proposal_check obey;
xauth_login "mylogin";
mode_cfg on;
proposal {
authentication_method xauth_psk_client;
hash_algorithm sha1;
encryption_algorithm aes 256;
lifetime time 3600 sec;
dh_group 2;
}
proposal {
authentication_method xauth_psk_client;
hash_algorithm sha1;
encryption_algorithm aes;
lifetime time 3600 sec;
dh_group 2;
}
proposal {
authentication_method xauth_psk_client;
hash_algorithm md5;
encryption_algorithm aes 256;
lifetime time 3600 sec;
dh_group 2;
}
proposal {
authentication_method xauth_psk_client;
hash_algorithm md5;
encryption_algorithm aes;
lifetime time 3600 sec;
dh_group 2;
}
proposal {
authentication_method xauth_psk_client;
hash_algorithm sha1;
encryption_algorithm 3des;
lifetime time 3600 sec;
dh_group 2;
}
proposal {
authentication_method xauth_psk_client;
hash_algorithm md5;
encryption_algorithm 3des;
lifetime time 3600 sec;
dh_group 2;
}
proposal {
authentication_method xauth_psk_client;
hash_algorithm sha1;
encryption_algorithm des;
lifetime time 3600 sec;
dh_group 2;
}
proposal {
authentication_method xauth_psk_client;
hash_algorithm md5;
encryption_algorithm des;
lifetime time 3600 sec;
dh_group 2;
}
}
When the connection is up and working, strongswan statusall:
Status of IKE charon daemon (strongSwan 5.0.1, Linux 2.6.32-279.14.1.el6.x86_64, x86_64):
uptime: 75 minutes, since Dec 07 09:28:11 2012
malloc: sbrk 450560, mmap 0, used 367744, free 82816
worker threads: 8 of 16 idle, 7/1/0/0 working, job queue: 0/0/0/0, scheduled: 4
loaded plugins: charon sqlite aes des sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs8 pgp dnskey pem fips-prf gmp xcbc cmac hmac attr attr-sql kernel-netlink resolve socket-default stroke sql updown xauth-generic unity
Listening IP addresses:
x.x.x.x
Connections:
rw: x.x.x.x5...%any IKEv1, dpddelay=40s
rw: local: [my.gateway.fqdn] uses pre-shared key authentication
rw: remote: uses pre-shared key authentication
rw: remote: uses XAuth authentication: any
rw: child: 192.168.8.0/24 === dynamic TUNNEL, dpdaction=clear
Security Associations (1 up, 0 connecting):
rw[3]: ESTABLISHED 2 minutes ago, x.x.x.x[my.gateway.fqdn]...2.225.141.140[192.168.2.105]
rw[3]: Remote XAuth identity: myid
rw[3]: IKEv1 SPIs: 4be963d5fcc1f25f_i 703fcb9599724566_r*, rekeying disabled
rw[3]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
rw{2}: INSTALLED, TUNNEL, ESP in UDP SPIs: c86fbcb6_i 0a6424b3_o
rw{2}: AES_CBC_256/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying disabled
rw{2}: 192.168.8.0/24 === 192.168.100.2/32
when VPN is working, racoon side:
192.168.2.105 x.x.x.x
esp mode=tunnel spi=3362766006(0xc86fbcb6) reqid=16471(0x00004057)
E: aes-cbc 7e25f168 aaab7ef1 97cdfc9e e3236ee6 226ccfc8 65541b18 f83632ba d0c795d1
A: hmac-sha1 8464d3df 84ba2218 4262a601 0aac0905 0bb1073d
seq=0x00000000 replay=4 flags=0x00000006 state=mature
created: Dec 7 10:41:08 2012 current: Dec 7 11:01:44 2012
diff: 1236(s) hard: 3600(s) soft: 2880(s)
last: hard: 0(s) soft: 0(s)
current: 0(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 0 hard: 0 soft: 0
sadb_seq=1 pid=7850 refcnt=2
x.x.x.x 192.168.2.105
esp mode=tunnel spi=174335155(0x0a6424b3) reqid=16472(0x00004058)
E: aes-cbc 38101561 83e27ddc d7690dc7 4765744d 19d56957 cdbfca39 fdd0d3bf eb5cc824
A: hmac-sha1 0bc6c89b 9a0fa690 8fe91a36 2bf55985 f339c674
seq=0x00000000 replay=4 flags=0x00000006 state=mature
created: Dec 7 10:41:08 2012 current: Dec 7 11:01:44 2012
diff: 1236(s) hard: 3600(s) soft: 2880(s)
last: hard: 0(s) soft: 0(s)
current: 0(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 0 hard: 0 soft: 0
sadb_seq=0 pid=7850 refcnt=2
logs on strongswan side, about 50 minutes after successful VPN establishment:
Dec 6 21:26:23 it charon: 11[IKE] sending DPD request Dec 6 21:26:23 it charon: 11[ENC] generating INFORMATIONAL_V1 request 3267501863 [ HASH N(DPD) ] Dec 6 21:26:23 it charon: 11[NET] sending packet: from x.x.x.x[4500] to 2.225.141.140[4500] Dec 6 21:26:23 it charon: 13[NET] received packet: from 2.225.141.140[4500] to x.x.x.x[4500] Dec 6 21:26:23 it charon: 13[ENC] parsed INFORMATIONAL_V1 request 4064578958 [ HASH N(DPD_ACK) ] Dec 6 21:26:46 it charon: 15[NET] received packet: from 2.225.141.140[4500] to x.x.x.x[4500] Dec 6 21:26:46 it charon: 15[ENC] parsed ID_PROT request 0 [ SA V V V V V V V V V V V V V V ] Dec 6 21:26:46 it charon: 15[IKE] received NAT-T (RFC 3947) vendor ID Dec 6 21:26:46 it charon: 15[IKE] received draft-ietf-ipsec-nat-t-ike vendor ID Dec 6 21:26:46 it charon: 15[IKE] received draft-ietf-ipsec-nat-t-ike-08 vendor ID Dec 6 21:26:46 it charon: 15[IKE] received draft-ietf-ipsec-nat-t-ike-07 vendor ID Dec 6 21:26:46 it charon: 15[IKE] received draft-ietf-ipsec-nat-t-ike-06 vendor ID Dec 6 21:26:46 it charon: 15[IKE] received draft-ietf-ipsec-nat-t-ike-05 vendor ID Dec 6 21:26:46 it charon: 15[IKE] received draft-ietf-ipsec-nat-t-ike-04 vendor ID Dec 6 21:26:46 it charon: 15[IKE] received draft-ietf-ipsec-nat-t-ike-03 vendor ID Dec 6 21:26:46 it charon: 15[IKE] received draft-ietf-ipsec-nat-t-ike-02 vendor ID Dec 6 21:26:46 it charon: 15[IKE] received draft-ietf-ipsec-nat-t-ike-02\n vendor ID Dec 6 21:26:46 it charon: 15[IKE] received XAuth vendor ID Dec 6 21:26:46 it charon: 15[IKE] received Cisco Unity vendor ID Dec 6 21:26:46 it charon: 15[ENC] received unknown vendor ID: 40:48:b7:d5:6e:bc:e8:85:25:e7:de:7f:00:d6:c2:d3:80:00:00:00 Dec 6 21:26:46 it charon: 15[IKE] received DPD vendor ID Dec 6 21:26:46 it charon: 15[IKE] 2.225.141.140 is initiating a Main Mode IKE_SA Dec 6 21:26:46 it charon: 15[ENC] generating ID_PROT response 0 [ SA V V V V ] Dec 6 21:26:46 it charon: 15[NET] sending packet: from x.x.x.x[4500] to 2.225.141.140[4500] Dec 6 21:26:46 it charon: 16[NET] received packet: from 2.225.141.140[4500] to x.x.x.x[4500] Dec 6 21:26:46 it charon: 16[ENC] parsed ID_PROT request 0 [ KE No NAT-D NAT-D ] Dec 6 21:26:46 it charon: 16[IKE] remote host is behind NAT Dec 6 21:26:46 it charon: 16[ENC] generating ID_PROT response 0 [ KE No NAT-D NAT-D ] Dec 6 21:26:46 it charon: 16[NET] sending packet: from x.x.x.x[4500] to 2.225.141.140[4500] Dec 6 21:26:46 it charon: 03[NET] received packet: from 2.225.141.140[4500] to x.x.x.x[4500] Dec 6 21:26:46 it charon: 03[ENC] parsed ID_PROT request 0 [ ID HASH ] Dec 6 21:26:46 it charon: 03[CFG] looking for XAuthInitPSK peer configs matching x.x.x.x...2.225.141.140[192.168.2.105] Dec 6 21:26:46 it charon: 03[CFG] selected peer config "rw" Dec 6 21:26:46 it charon: 03[ENC] generating ID_PROT response 0 [ ID HASH ] Dec 6 21:26:46 it charon: 03[NET] sending packet: from x.x.x.x[4500] to 2.225.141.140[4500] Dec 6 21:26:46 it charon: 03[ENC] generating TRANSACTION request 44664428 [ HASH CP ] Dec 6 21:26:46 it charon: 03[NET] sending packet: from x.x.x.x[4500] to 2.225.141.140[4500] Dec 6 21:26:50 it charon: 02[IKE] sending retransmit 1 of request message ID 44664428, seq 1 Dec 6 21:26:50 it charon: 02[NET] sending packet: from x.x.x.x[4500] to 2.225.141.140[4500] Dec 6 21:26:51 it charon: 01[NET] received packet: from 2.225.141.140[4500] to x.x.x.x[4500] Dec 6 21:26:51 it charon: 01[ENC] parsed INFORMATIONAL_V1 request 3116209513 [ HASH D ] Dec 6 21:26:51 it charon: 01[IKE] received DELETE for IKE_SA rw[1] Dec 6 21:26:51 it charon: 01[IKE] deleting IKE_SA rw[1] between x.x.x.x[my.gateway.fqdn]...2.225.141.140[192.168.2.105] Dec 6 21:26:54 it charon: 12[NET] received packet: from 2.225.141.140[4500] to x.x.x.x[4500] Dec 6 21:26:54 it charon: 12[ENC] parsed TRANSACTION response 44664428 [ HASH CP ] Dec 6 21:26:54 it charon: 12[IKE] XAuth authentication of 'myid' successful Dec 6 21:26:54 it charon: 12[ENC] generating TRANSACTION request 3158087928 [ HASH CP ] Dec 6 21:26:54 it charon: 12[NET] sending packet: from x.x.x.x[4500] to 2.225.141.140[4500] Dec 6 21:26:54 it charon: 11[NET] received packet: from 2.225.141.140[4500] to x.x.x.x[4500] Dec 6 21:26:54 it charon: 11[ENC] parsed TRANSACTION response 3158087928 [ HASH CP ] Dec 6 21:26:54 it charon: 11[IKE] IKE_SA rw[2] established between x.x.x.x[my.gateway.fqdn]...2.225.141.140[192.168.2.105] Dec 6 21:27:26 it charon: 01[NET] received packet: from 2.225.141.140[4500] to x.x.x.x[4500] Dec 6 21:27:26 it charon: 01[ENC] parsed INFORMATIONAL_V1 request 2293057995 [ HASH N(DPD) ] Dec 6 21:27:26 it charon: 01[ENC] generating INFORMATIONAL_V1 request 3253914055 [ HASH N(DPD_ACK) ] Dec 6 21:27:26 it charon: 01[NET] sending packet: from x.x.x.x[4500] to 2.225.141.140[4500]
logs on racoon side at the same time:
Dec 6 21:26:23 myid.local racoon[4261]: IKE Packet: transmit success. (Information message). Dec 6 21:26:23 myid.local racoon[4261]: IKEv1 Information-Notice: transmit success. (R-U-THERE? ACK). Dec 6 21:26:23 myid.local racoon[4261]: IKE Packet: receive success. (Information message). Dec 6 21:26:46 myid.local racoon[4261]: IPSec Phase1 started (Initiated by me). Dec 6 21:26:46 myid.local racoon[4261]: IKE Packet: transmit success. (Initiator, Main-Mode message 1). Dec 6 21:26:46 myid.local racoon[4261]: IKE Packet: receive success. (Initiator, Main-Mode message 2). Dec 6 21:26:46 myid.local racoon[4261]: IKE Packet: transmit success. (Initiator, Main-Mode message 3). Dec 6 21:26:46 myid.local racoon[4261]: IKE Packet: receive success. (Initiator, Main-Mode message 4). Dec 6 21:26:46 myid.local racoon[4261]: IKE Packet: transmit success. (Initiator, Main-Mode message 5). Dec 6 21:26:46 myid.local racoon[4261]: IKEv1 Phase1 AUTH: success. (Initiator, Main-Mode Message 6). Dec 6 21:26:46 myid.local racoon[4261]: IKE Packet: receive success. (Initiator, Main-Mode message 6). Dec 6 21:26:46 myid.local racoon[4261]: IKEv1 Phase1 Initiator: success. (Initiator, Main-Mode). Dec 6 21:26:46 myid.local racoon[4261]: IPSec Phase1 established (Initiated by me). Dec 6 21:26:46 myid.local racoon[4261]: IPSec Extended Authentication requested. Dec 6 21:26:51 myid.local racoon[4261]: IKE Packet: transmit success. (Information message). Dec 6 21:26:51 myid.local racoon[4261]: IKEv1 Information-Notice: transmit success. (Delete ISAKMP-SA). Dec 6 21:26:54 myid.local racoon[4261]: IKE Packet: transmit success. (Mode-Config message). Dec 6 21:26:54 myid.local racoon[4261]: IPSec Extended Authentication sent. Dec 6 21:26:54 myid.local racoon[4261]: IKEv1 XAUTH: success. (XAUTH Status is OK). Dec 6 21:26:54 myid.local racoon[4261]: IPSec Extended Authentication Passed. Dec 6 21:26:54 myid.local racoon[4261]: IKE Packet: transmit success. (Mode-Config message). Dec 6 21:27:26 myid.local racoon[4261]: IKE Packet: transmit success. (Information message). Dec 6 21:27:26 myid.local racoon[4261]: IKEv1 Information-Notice: transmit success. (R-U-THERE?). Dec 6 21:27:26 myid.local racoon[4261]: IKEv1 Dead-Peer-Detection: request transmitted. (Initiator DPD Request). Dec 6 21:27:26 myid.local racoon[4261]: IKEv1 Dead-Peer-Detection: response received. (Initiator DPD Response). Dec 6 21:27:26 myid.local racoon[4261]: IKE Packet: receive success. (Information message).
After phase 1 renegotiation (VPN still up but no traffic flowing:
strongswan statusall
Status of IKE charon daemon (strongSwan 5.0.1, Linux 2.6.32-279.14.1.el6.x86_64, x86_64):
uptime: 2 hours, since Dec 07 09:28:11 2012
malloc: sbrk 450560, mmap 0, used 367200, free 83360
worker threads: 8 of 16 idle, 7/1/0/0 working, job queue: 0/0/0/0, scheduled: 6
loaded plugins: charon sqlite aes des sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs8 pgp dnskey pem fips-prf gmp xcbc cmac hmac attr attr-sql kernel-netlink resolve socket-default stroke sql updown xauth-generic unity
Listening IP addresses:
x.x.x.x
Connections:
rw: x.x.x.x...%any IKEv1, dpddelay=40s
rw: local: [my.gateway.fqdn] uses pre-shared key authentication
rw: remote: uses pre-shared key authentication
rw: remote: uses XAuth authentication: any
rw: child: 192.168.8.0/24 === dynamic TUNNEL, dpdaction=clear
Security Associations (1 up, 0 connecting):
rw[4]: ESTABLISHED 21 seconds ago, 109.168.103.185[it.leopardus.com]...2.225.141.140[192.168.2.105]
rw[4]: Remote XAuth identity: myid
rw[4]: IKEv1 SPIs: 6a141bc46e3209be_i 15a6214f140cfbc9_r*, rekeying disabled
rw[4]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
racoon ss ipsec returns: no SAD entries.
One issue I see here is the fact xauth is requested again, also password is stored and not asked
when first establishing the VPN but after renegotiation it is asked again (weird but maybe a client problem)...
I am no IPSEC expert so it could be that I am missing something obvious here, but for the life of me I cannot
see what's wrong with this setup...
Thanks in advance for your help on this matter!
Rick
History
#1 Updated by Tobias Brunner almost 13 years ago
- Description updated (diff)
- Status changed from New to Feedback
Hm, it looks like racoon deletes the old IKE_SA too early during reauthentication (phase 1 rekeying). For charon an IKE_SA is not established until the authentication with XAuth is finished. So when racoon sends a delete for the old IKE_SA right after main mode, charon deletes the old IKE_SA and with it the existing CHILD_SAs (phase 2/quick mode SAs). But even if racoon would wait till after the XAuth exchange has finished the same problem might still occur because the adoption of existing CHILD_SAs by the new IKE_SA happens asynchronously. So the old IKE_SA might still get deleted before the CHILD_SAs get adopted by the new IKE_SA (this is not very likely, though).
The problem is that for charon a CHILD_SA always belongs to an IKE_SA. According to draft-jenkins-ipsec-rekeying, section 3 our behavior might be a bit too strict:
Further, it means that phase 1 SA and phase 2
SA lifetimes are unbound; that is, there are no requirements that a
phase 1 SA exist between two peers that have phase 2 SAs.
However, some applications may consider it advantageous to attempt
to keep a valid phase 1 SA up between peers at all times. This would
require overlapping of phase 1 SAs, and re-keying of old SAs before
they expire. However, these implementations must be aware that peers
may not be trying to do this, and in fact may be trying to reduce
unused resource requirements by deleting the phase 1 SA.
But it really simplifies the implementation (in particular because IKEv2 follows this model). But as written in that Internet Draft, no RFC actually mandates one behavior over the other (don't we like IKEv1 for stuff like this).
Since changing our behavior (i.e. decoupling IKE from CHILD SAs) would be a major change (that I'm not sure we actually want to do), you should probably try again to increasing the rekeying time by patching the racoon config (I suppose that's what the hack you mentioned is about).
I'm not sure if racoon's behavior changed or if that was a problem all along. But what's actually quite strange is that even for racoon the CHILD_SAs are gone, otherwsise setkey would not report no SAD entries. And since the DELETE notify is sent right after racoon receives the XAuth request (is that always the case?) it might be that it doesn't really expect an XAuth exchange during reauthentication, and receiving one causes it to delete the existing IKE_SA (it could also be a timing issue since both peers start their individual next exchange independently). So we could perhaps introduce an option to allow reauthentication without another XAuth exchange and only initiate one if we don't find an established IKE_SA with matching phase 1 identities, IP addresses and ports. I'm not sure how feasible that is, though, and if it would fix the problem.
Another thing you could try is to reduce the IKE lifetime on the gateway so that the phase 1 rekeying is initiated by it and not by the client. For instance, by setting ikelifetime=30m. (Could be, though, that the client doesn't like that at all).
#2 Updated by Rick Pizzi almost 13 years ago
I tried to set a shorter lifetime on the strongswan side but that just did not work.
racoon did not reply to the renegotiation at all if I recall correctly.
I think the main problem could be what you wrote above "it might be that racoon doesn't really expect an XAuth exchange during reauthentication". Would be nice to have the option on charon side to allowreauth without involving xauth exchange, perhaps that would be not to hard to implement?
Thanks again
Rick
#3 Updated by Rick Pizzi almost 13 years ago
An addendum.
I have tried once again with a fixed racoon config (the tweak I found on the web).
racoon tweaked config I have used:
remote x.x.x.x {
doi ipsec_doi;
situation identity_only;
exchange_mode main;
verify_identifier off;
shared_secret keychain "FC6D8EA9-5021-4041-9DC8-FB5C6B0B634A.SS";
nonce_size 16;
dpd_delay 0;
initial_contact on;
support_proxy on;
proposal_check claim;
xauth_login "myid";
mode_cfg on;
proposal {
authentication_method xauth_psk_client;
hash_algorithm sha1;
encryption_algorithm aes 256;
lifetime time 24 hour;
dh_group 2;
}
}
As I said, this tweak seem to be ignored by racoon on my macbook, because
strongswan on server side reports:
Dec 7 15:15:04 it charon: 12[IKE] received 3600s lifetime, configured 0s
The damn fixed 1h lifetime is still sent despite what I have put in the racoon.conf above.
Anyway, during this last test something different happened, not sure why.
Phase 1 renegotiation did NOT happen. The VPN stayed up for more than 2 hours!!
And look at this :
Status of IKE charon daemon (strongSwan 5.0.1, Linux 2.6.32-279.14.1.el6.x86_64, x86_64):
uptime: 2 hours, since Dec 07 12:52:26 2012
malloc: sbrk 450560, mmap 0, used 361264, free 89296
worker threads: 8 of 16 idle, 7/1/0/0 working, job queue: 0/0/0/0, scheduled: 5
loaded plugins: charon sqlite aes des sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs8 pgp dnskey pem fips-prf gmp xcbc cmac hmac attr attr-sql kernel-netlink resolve socket-default stroke sql updown xauth-generic unity
Listening IP addresses:
x.x.x.x
Connections:
rw: x.x.x.x...%any IKEv1, dpddelay=40s
rw: local: [my.gateway.fqdn] uses pre-shared key authentication
rw: remote: uses pre-shared key authentication
rw: remote: uses XAuth authentication: any
rw: child: 192.168.8.0/24 === dynamic TUNNEL, dpdaction=clear
Security Associations (1 up, 0 connecting):
rw[2]: ESTABLISHED 2 hours ago, x.x.x.x[my.gateway.fqdn]...2.225.141.140[192.168.2.105]
rw[2]: Remote XAuth identity: calvados
rw[2]: IKEv1 SPIs: 0654b3edb2e04df5_i 00cf699ff7ca9c20_r*, rekeying disabled
rw[2]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
rw{1}: REKEYING, TUNNEL, expires in 2 days
rw{1}: 192.168.8.0/24 === 192.168.100.2/32
rw{1}: REKEYING, TUNNEL, expires in 2 days
rw{1}: 192.168.8.0/24 === 192.168.100.2/32
rw{1}: INSTALLED, TUNNEL, ESP in UDP SPIs: c7288c35_i 04c4bc24_o
rw{1}: AES_CBC_256/HMAC_SHA1_96, 4102 bytes_i (202s ago), 23122 bytes_o (201s ago), rekeying disabled
rw{1}: 192.168.8.0/24 === 192.168.100.2/32
What's the meaning of "REKEYING, TUNNEL" and where did that 2 days expiration time came from?
I am confused now. Only difference I have in this test is the fact that I forced the proposal like this:
conn %default
ikelifetime=24h
keylife=20m
rekeymargin=3m
keyingtries=1
keyexchange=ikev1
rekey = no
left=x.x.x.x
leftsubnet=192.168.8.0/24
esp=aes256-sha1!
ike=aes256-sha1-modp1024!
Any idea?
Thanks
Rick
#4 Updated by Rick Pizzi almost 13 years ago
Just happened again in the current test.
The "TUNNEL, REKEYING, expiration 2 days" shows up in statusall output right after the CHILD_SA is rekeyed (the client initiates the rekey here):
Dec 7 16:03:05 myid racoon[9252]: IPSec Phase2 started (Initiated by me). Dec 7 16:03:05 myid racoon[9252]: IKE Packet: transmit success. (Initiator, Quick-Mode message 1). Dec 7 16:03:05 myid racoon[9252]: IKE Packet: receive success. (Initiator, Quick-Mode message 2). Dec 7 16:03:05 myid racoon[9252]: IKE Packet: transmit success. (Initiator, Quick-Mode message 3). Dec 7 16:03:05 myid racoon[9252]: IKEv1 Phase2 Initiator: success. (Initiator, Quick-Mode). Dec 7 16:03:05 myid racoon[9252]: IPSec Phase2 established (Initiated by me).
Dec 7 16:03:05 it charon: 01[NET] received packet: from 2.225.141.140[4500] to x.x.x.x[4500]
Dec 7 16:03:05 it charon: 01[ENC] parsed QUICK_MODE request 3413436061 [ HASH SA No ID ID ]
Dec 7 16:03:05 it charon: 01[IKE] received 3600s lifetime, configured 0s
Dec 7 16:03:05 it charon: 01[IKE] detected rekeying of CHILD_SA rw{1}
Dec 7 16:03:05 it charon: 01[ENC] generating QUICK_MODE response 3413436061 [ HASH SA No ID ID ]
Dec 7 16:03:05 it charon: 01[NET] sending packet: from x.x.x.x[4500] to 2.225.141.140[4500]
Dec 7 16:03:05 it charon: 11[NET] received packet: from 2.225.141.140[4500] to x.x.x.x[4500]
Dec 7 16:03:05 it charon: 11[ENC] parsed QUICK_MODE request 3413436061 [ HASH ]
Dec 7 16:03:05 it charon: 11[IKE] CHILD_SA rw{1} established with SPIs ced5b30b_i 0ada64f5_o and TS 192.168.8.0/24 === 192.168.100.2/32
- strongswan statusall
Status of IKE charon daemon (strongSwan 5.0.1, Linux 2.6.32-279.14.1.el6.x86_64, x86_64):
uptime: 49 minutes, since Dec 07 15:14:32 2012
malloc: sbrk 450560, mmap 0, used 357856, free 92704
worker threads: 8 of 16 idle, 7/1/0/0 working, job queue: 0/0/0/0, scheduled: 3
loaded plugins: charon sqlite aes des sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs8 pgp dnskey pem fips-prf gmp xcbc cmac hmac attr attr-sql kernel-netlink resolve socket-default stroke sql updown xauth-generic unity
Listening IP addresses:
x.x.x.x
Connections:
rw: 109.168.103.185...%any IKEv1, dpddelay=40s
rw: local: [my.gateway.fqdn] uses pre-shared key authentication
rw: remote: uses pre-shared key authentication
rw: remote: uses XAuth authentication: any
rw: child: 192.168.8.0/24 === dynamic TUNNEL, dpdaction=clear
Security Associations (1 up, 0 connecting):
rw[1]: ESTABLISHED 48 minutes ago, x.x.x.x[my.gateway.fqdn]...2.225.141.140[192.168.2.105]
rw[1]: Remote XAuth identity: calvados
rw[1]: IKEv1 SPIs: 3eb975f87e3f78ee_i caf219b1ef52fb55_r*, rekeying disabled
rw[1]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
rw{1}: REKEYING, TUNNEL, expires in 2 days
rw{1}: 192.168.8.0/24 === 192.168.100.2/32
rw{1}: INSTALLED, TUNNEL, ESP in UDP SPIs: ced5b30b_i 0ada64f5_o
rw{1}: AES_CBC_256/HMAC_SHA1_96, 168 bytes_i (6s ago), 168 bytes_o (6s ago), rekeying disabled
rw{1}: 192.168.8.0/24 === 192.168.100.2/32
One new "REKEYING, TUNNEL" entry appears every Phase2 rekeying.
Here's the racoon status now:
192.168.2.105 x.x.x.x
esp mode=tunnel spi=3470111499(0xced5b30b) reqid=16487(0x00004067)
E: aes-cbc 539917b0 a64930ab bc9d45c4 560f31c9 d8a09c0b 184e8d1b 2752daa9 c0493954
A: hmac-sha1 eeb09cd3 88aa12e0 913d7d7e d3c7362e 02271a97
seq=0x00000004 replay=4 flags=0x00000006 state=mature
created: Dec 7 16:03:05 2012 current: Dec 7 16:12:35 2012
diff: 570(s) hard: 3600(s) soft: 2880(s)
last: Dec 7 16:04:16 2012 hard: 0(s) soft: 0(s)
current: 640(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 4 hard: 0 soft: 0
sadb_seq=3 pid=9252 refcnt=2
192.168.2.105 x.x.x.x
esp mode=tunnel spi=3387310611(0xc9e64213) reqid=16487(0x00004067)
E: aes-cbc 579f61d0 894d6940 c57bd35b 92734456 d800470d 4c34a871 bf57c3b7 6fff4ff7
A: hmac-sha1 54b69cc2 0e8c62db 7afa3230 788e88ff 4da08f9b
seq=0x00000004 replay=4 flags=0x00000006 state=dying
created: Dec 7 15:15:04 2012 current: Dec 7 16:12:35 2012
diff: 3451(s) hard: 3600(s) soft: 2880(s)
last: Dec 7 15:42:39 2012 hard: 0(s) soft: 0(s)
current: 640(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 4 hard: 0 soft: 0
sadb_seq=2 pid=9252 refcnt=2
x.x.x.x 192.168.2.105
esp mode=tunnel spi=182084853(0x0ada64f5) reqid=16488(0x00004068)
E: aes-cbc 617206b0 387b98fa 92696cd0 af851807 cbb92d51 54571ad0 297a6d71 37b67cde
A: hmac-sha1 31633214 a1373330 d8ac74ed 0e5100a0 101a33a9
seq=0x00000004 replay=4 flags=0x00000006 state=mature
created: Dec 7 16:03:05 2012 current: Dec 7 16:12:35 2012
diff: 570(s) hard: 3600(s) soft: 2880(s)
last: Dec 7 16:04:16 2012 hard: 0(s) soft: 0(s)
current: 336(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 4 hard: 0 soft: 0
sadb_seq=1 pid=9252 refcnt=2
x.x.x.x 192.168.2.105
esp mode=tunnel spi=126575563(0x078b63cb) reqid=16488(0x00004068)
E: aes-cbc 455bded6 358a566d 6c9742d4 42f85927 3e4278b0 d5a14155 4fbbb57e d9b75026
A: hmac-sha1 9448eb7f 076ef990 a7ae9c24 296b1195 104047d6
seq=0x00000004 replay=4 flags=0x00000006 state=dying
created: Dec 7 15:15:04 2012 current: Dec 7 16:12:35 2012
diff: 3451(s) hard: 3600(s) soft: 2880(s)
last: Dec 7 15:42:39 2012 hard: 0(s) soft: 0(s)
current: 336(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 4 hard: 0 soft: 0
sadb_seq=0 pid=9252 refcnt=2
We have 4 SA are now with two of them in "dying" state!!
When diff > hard (3600 seconds) the two dying SA are removed from the output.
strongswan statusall remains the same...
The VPN is working now. I'm puzzled...
Thanks again,
Rick
#5 Updated by Rick Pizzi almost 13 years ago
OK, the VPN has been up for over 10 hours now.
Current settings:
racoon:
remote x.x.x.x {
doi ipsec_doi;
situation identity_only;
exchange_mode main;
verify_identifier off;
shared_secret keychain "FC6D8EA9-5021-4041-9DC8-FB5C6B0B634A.SS";
nonce_size 16;
dpd_delay 0;
initial_contact on;
support_proxy on;
proposal_check claim;
xauth_login "myid";
mode_cfg on;
proposal {
authentication_method xauth_psk_client;
hash_algorithm sha1;
encryption_algorithm aes 256;
lifetime time 24 hour;
dh_group 2;
}
}
charon:
ikelifetime=24h
keylife=60m
rekeymargin=3m
keyingtries=1
keyexchange=ikev1
rekey = yes
left=x.x.x.x
leftsubnet=192.168.8.0/24
esp=aes256-sha1!
ike=aes256-sha1-modp1024!
auto=add
So basically, if I let racoon and charon agree on a proposal, shortly after the first CHILD_SA rekey racoon
tries to renegotiate phase 1 and everything breaks.
With the above config this does NOT happen!!! Honestly do not understand why, especially considering
that the proposal that is agreed upon by the peers when proposal negotiation is enabled is the same I have forced in the above config.
Any clues?
Furthermore, I have found that enabling rekeying on charon side with a lifetime slightly larger than
the "soft" lifetime that racoon imposes will get rid of the SA in the "REKEYING, TUNNEL" state after
a dozen minutes (instead of 2+ days, still do not understand where that came from).
Since the rekeying on racoon side will always happen before the one on charon side, the rekeying will
be always initiated by racoon and therefore rekeying on server side will never happen (this would otherwise
break the VPN as I described earlier).
Thanks
Rick
#6 Updated by Andreas Steffen over 12 years ago
- Tracker changed from Bug to Issue
- Status changed from Feedback to Closed
- Assignee set to Tobias Brunner