[strongSwan] StrongSwan looses connection when reauthenticating

Tobias Brunner tobias at strongswan.org
Fri Aug 30 09:56:08 CEST 2013


Hi Uwe,

> All my initiators are behind NAT without a Port forwarding, so this
> would make sense.

No port forwarding is required if the client originally initiated the
connection.  The NAT mapping should still be alive during the short time
the client will not send NAT keep-alives during a reauthentication.  But
that does not seem to be the problem anyway.

> Here's the Log entry that's generated on the Gateway when reauthenticaing.
> 
> Aug 29 19:52:53 03[NET] received packet: from yy.yy.yy.yy[4500] to xx.xx.xx.xx[4500] (76 bytes)
> Aug 29 19:52:53 03[ENC] parsed INFORMATIONAL request 26 [ D ]
> Aug 29 19:52:53 03[IKE] received DELETE for IKE_SA vpn-initiator-vpn-responder[1]
> Aug 29 19:52:53 03[IKE] deleting IKE_SA vpn-initiator-vpn-responder[1] between xx.xx.xx.xx[vpn-responder]...yy.yy.yy.yy[vpn-initiator]
> ...
> Aug 29 19:52:53 01[NET] received packet: from yy.yy.yy.yy[4500] to xx.xx.xx.xx[4500] (304 bytes)
> Aug 29 19:52:53 01[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
> Aug 29 19:52:53 01[IKE] yy.yy.yy.yy is initiating an IKE_SA
> ...
> Aug 29 19:52:53 01[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(MULT_AUTH) ]
> Aug 29 19:52:53 01[NET] sending packet: from xx.xx.xx.xx[4500] to yy.yy.yy.yy[4500] (337 bytes)
> ...
> Aug 29 19:52:53 11[IKE] IKE_SA vpn-initiator-vpn-responder[2] established between xx.xx.xx.xx[vpn-responder]...yy.yy.yy.yy[vpn-initiator]
> Aug 29 19:52:53 11[IKE] CHILD_SA vpn-initiator-vpn-responder{2} established with SPIs c49c3457_i cbea0c57_o and TS 192.168.255.0/24 === 192.168.245.0/24
> Aug 29 19:52:53 11[ENC] generating IKE_AUTH response 1 [ IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) ]
> Aug 29 19:52:53 11[NET] sending packet: from xx.xx.xx.xx[4500] to yy.yy.yy.yy[4500] (220 bytes)

The reauthentication is clearly initiated by the client.  The
IKE_SA_INIT response is sent to the same address/port and that works
fine.  Therefore, it seems strange that the IKE_AUTH response should not
be received by the client.  What exactly is logged on the client at the
same time?

Regards,
Tobias




More information about the Users mailing list