Martin, Here are my log files when I got another occurrence of the hang. ‘reauth=no’ for both client and server. The clocks are synced on the boxes.
Unfortunately, the logs don’t seem to provide much help. At 16:44:43, I
executed ‘ps -ef’ on the server.
It’s now 17:06:41 and I still don’t see all the output.
SERVER:
Oct 22 16:44:07 vpn-server charon: 01[IKE] sending keep alive to
AA.AAA.AA.A[57135]
Oct 22 16:44:07 vpn-server charon: 10[NET] sending packet: from 10.0.0.6[4500]
to AA.AAA.AA.A[57135]
Oct 22 16:44:27 vpn-server charon: 02[IKE] sending keep alive to
AA.AAA.AA.A[57135]
Oct 22 16:44:27 vpn-server charon: 10[NET] sending packet: from 10.0.0.6[4500]
to AA.AAA.AA.A[57135]
Oct 22 16:44:47 vpn-server charon: 12[IKE] sending keep alive to
AA.AAA.AA.A[57135]
Oct 22 16:44:47 vpn-server charon: 10[NET] sending packet: from 10.0.0.6[4500]
to AA.AAA.AA.A[57135]
Oct 22 16:45:31 vpn-server charon: 06[IKE] sending keep alive to
AA.AAA.AA.A[57135]
CLIENT:
Oct 22 16:44:25 vpn-client charon: 13[IKE] sending keep alive to
BB.BBB.BBB.BB[4500]
Oct 22 16:44:25 vpn-client charon: 10[NET] sending packet: from
CCC.CC.CCC.CCC[4500] to BB.BBB.BBB.BB[4500]
Oct 22 16:44:29 vpn-client charon: 11[IKE] sending keep alive to
DD.DDD.DDD.DDD[4500]
Oct 22 16:44:29 vpn-client charon: 10[NET] sending packet: from
CCC.CC.CCC.CCC[4500] to DD.DDD.DDD.DDD[4500]
Oct 22 16:44:45 vpn-client charon: 03[IKE] sending keep alive to
BB.BBB.BBB.BB[4500]
Oct 22 16:44:45 vpn-client charon: 10[NET] sending packet: from
CCC.CC.CCC.CCC[4500] to BB.BBB.BBB.BB[4500]
Oct 22 16:44:49 vpn-client charon: 15[IKE] sending keep alive to
DD.DDD.DDD.DDD[4500]
Oct 22 16:44:49 vpn-client charon: 10[NET] sending packet: from
CCC.CC.CCC.CCC[4500] to DD.DDD.DDD.DDD[4500]
Oct 22 16:45:05 vpn-client charon: 06[IKE] sending keep alive to
BB.BBB.BBB.BB[4500]
Oct 22 16:45:05 vpn-client charon: 10[NET] sending packet: from
CCC.CC.CCC.CCC[4500] to BB.BBB.BBB.BB[4500]
Oct 22 16:45:09 vpn-client charon: 14[IKE] sending keep alive to
DD.DDD.DDD.DDD[4500]
Oct 22 16:45:09 vpn-client charon: 10[NET] sending packet: from
CCC.CC.CCC.CCC[4500] to DD.DDD.DDD.DDD[4500]
SERVER CONFIG:
config setup
# strictcrlpolicy=yes
# uniqueids = no
charondebug="ike 3,cfg 3, dmn 3, ike 3, net 3"
# Add connections here.
# Sample VPN connections
conn %default
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyingtries=1
keyexchange=ikev2
reauth=no
conn rw
left=10.0.0.6
leftid=bastion-host-us-west-1b
leftcert=vpnHostCert.pem
leftsubnet=10.0.0.0/16
leftfirewall=yes
right=%any
rightsourceip=10.100.255.0/28
auto=add
CLIENT CONFIG:
# ipsec.conf - strongSwan IPsec configuration file
# basic configuration
config setup
# strictcrlpolicy=yes
# uniqueids = no
charondebug="ike 3,cfg 3, dmn 3, ike 3, net 3"
# Add connections here.
conn %default
keyexchange=ikev2
left=%any
leftsourceip=%config
[email protected]
leftfirewall=yes
leftcert=JEmersonCert.pem
reauth=no
auto=start
conn vpn1
right=DD.DDD.DDD.DDD
rightsubnet=10.0.0.0/28
rightid=vpn-server-1b
rightcert=vpnHostCert-1b.pem
conn vpn2
right=BB.BBB.BBB.BB
rightsubnet=10.0.0.16/28
rightid=vpn-server-1c
rightcert=vpnHostCert-1c.pem
> On Oct 20, 2014, at 12:14 AM, Martin Willi <[email protected]> wrote:
>
> Hi,
>
>> I have modified both sides of the VPN with ‘reauth=no’ and the problem
>> persists.
>
>> Oct 15 19:51:40 CloudOpsVpns charon: 12[IKE] IKE_SA vpn1[23] established
>> between AAA.AA.AAA.AAA[[email protected]]...BB.BBB.BBB.BBB[host-us-west-1b]
>> Oct 15 19:51:40 CloudOpsVpns charon: 12[IKE] scheduling rekeying in 9787s
>> Oct 15 19:51:40 CloudOpsVpns charon: 12[IKE] maximum IKE_SA lifetime 10327s
>> Oct 15 19:51:40 CloudOpsVpns charon: 12[IKE] installing new virtual IP
>> 10.100.255.2
>> Oct 15 19:51:40 CloudOpsVpns charon: 12[IKE] CHILD_SA vpn1{1} established
>> with SPIs cb5d4d03_i c25d94db_o and TS 10.100.255.2/32 === 10.0.0.0/28
>> Oct 15 19:51:40 CloudOpsVpns charon: 12[IKE] received AUTH_LIFETIME of
>> 3381s, scheduling reauthentication in 2841s
>
> In this log I see a re-authentication procedure. After establishing the
> IKE_SA, the local host schedules re-authentication because it received
> an AUTH_LIFETIME notify from the responder. So it looks like
> re-authentication is still enabled on the peer.
>
> Regards
> Martin
>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
