Re: [strongSwan] Loss of tunnel service while reauthenticating IKE_SA?

[Ken Nelson]

The make-before-break re-authentication feature is good news.  Very interested 
in trying it out - it there an expected date for the 5.3.0 release?


> On Mar 12, 2015, at 9:32 AM, Martin Willi  wrote:
> 
> Hi Tom,
> 
>> Is there a reason that, when using two Strongswan endpoints, one would 
>> not choose reauth=no?
> 
> Yes. Reauthentication re-evaluates authentication credentials, checks
> the certificate status or rechecks permissions in the AAA backend.
> IKE_SA rekeying, as used with reauth=no, only refreshes key material,
> but does not verify the peer credentials.
> 
>> It seems to me that using reauth=no would result in fewer traffic
>> interruptions, unless I have missed something.
> 
> Yes. However, with the upcoming 5.3.0 release, we will introduce support
> for make-before-break re-authentication, which establishes the new
> tunnel with all CHILD_SAs before closing the old one, basically avoiding
> any interruptions.
> 
> Regards
> Martin
> 
> ___
> Users mailing list
> Users@lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Queries on vulnerability fixes

[Martin Willi]

Hi,

> As per the description of vulnerabilities in above links, the
> vulnerability is only applicable and will lead to crash in pluto IKE
> daemon alone. Charon is not mentioned.

You should apply these fixes even if using charon only, the
libstrongswan code is used by charon. Not sure where this CVE text
exactly comes from; our patch notes [1] mention both pluto and charon.

> We understood that the fix provided for this is @ links 
> http://download.strongswan.org/patches/05_asn1_rdn_patch/strongswan-4.x.x_asn1_rdn.patch
> http://download.strongswan.org/patches/07_asn1_length_patch/strongswan-4.x.x_asn1_length.patch
> 
You shouldn't miss 06_asn1_time_patch [2]. Also, you may have a look at
the security directory [3] to find patches by CVE.

Regards
Martin

[1]http://download.strongswan.org/security/CVE-2009-2185a/strongswan-4.x.x_asn1_rdn.readme
[2]http://download.strongswan.org/patches/06_asn1_time_patch/
[3]http://download.strongswan.org/security/

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Loss of tunnel service while reauthenticating IKE_SA?

[Tom Rymes]

On 03/12/2015 11:32 AM, Martin Willi wrote:


Is there a reason that, when using two Strongswan endpoints, one would
not choose reauth=no?


Yes. Reauthentication re-evaluates authentication credentials, checks
the certificate status or rechecks permissions in the AAA backend.
IKE_SA rekeying, as used with reauth=no, only refreshes key material,
but does not verify the peer credentials.


I see. But if you were worried about re-evaluating the credentials, 
wouldn't you be better served by setting a shorter lifetime for the IKE SA?



It seems to me that using reauth=no would result in fewer traffic
interruptions, unless I have missed something.


Yes. However, with the upcoming 5.3.0 release, we will introduce support
for make-before-break re-authentication, which establishes the new
tunnel with all CHILD_SAs before closing the old one, basically avoiding
any interruptions.


Ah, interesting. I will look forward to this.

Tom

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Loss of tunnel service while reauthenticating IKE_SA?

[Martin Willi]

Hi Tom,

> Is there a reason that, when using two Strongswan endpoints, one would 
> not choose reauth=no?

Yes. Reauthentication re-evaluates authentication credentials, checks
the certificate status or rechecks permissions in the AAA backend.
IKE_SA rekeying, as used with reauth=no, only refreshes key material,
but does not verify the peer credentials.

> It seems to me that using reauth=no would result in fewer traffic
> interruptions, unless I have missed something.

Yes. However, with the upcoming 5.3.0 release, we will introduce support
for make-before-break re-authentication, which establishes the new
tunnel with all CHILD_SAs before closing the old one, basically avoiding
any interruptions.

Regards
Martin

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Loss of tunnel service while reauthenticating IKE_SA?

[Noel Kuntze]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello Tom,

As the default value for the setting is "yes", a strongSwan endpoint that has 
it set to "no"
would have it because somebody set it to that value, so an operator had done 
that.
And yes, "reauth=no" leads to basicly no traffic interruptions.

Mit freundlichen Grüßen/Kind Regards,
Noel Kuntze

GPG Key ID: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658

Am 12.03.2015 um 16:22 schrieb Tom Rymes:
> On 03/12/2015 11:16 AM, Noel Kuntze wrote:
>
>> Hello Ken,
>>
>> It is dependent on the IKE version.
>> Quote from the man page:
>>
>> reauth = yes | no
>>whether rekeying of an IKE_SA  should  also  reauthenticate  
>> the
>>peer.  In  IKEv1,  reauthentication  is always done. In 
>> IKEv2, a
>>value of no rekeys without uninstalling the IPsec SAs,  a  
>> value
>>of yes (the default) creates a new IKE_SA from scratch and 
>> tries
>>to recreate all IPsec SAs.
>>
>> Obviously, setting reauth=no will keep the tunnel up during rekeying of the 
>> IKE SAs.
>> You have to use "reauth=no" on both sides to make it work.
>
> Noel,
>
> Is there a reason that, when using two Strongswan endpoints, one would not 
> choose reauth=no? It seems to me that using reauth=no would result in fewer 
> traffic interruptions, unless I have missed something.
>
> Tom
> ___
> Users mailing list
> Users@lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVAbBcAAoJEDg5KY9j7GZYHZUP/jH70zpMPuOsXkK56mis0l79
dCOFkMnPPopZ+LShK8kRvdB4fyKF4G2EfXq0Iv/9aFtwsz1L0nb3+ESBEB6oannV
E87tSaA98W1g92GQRfrol5Av5PUcAdojboJ/BZbqZ7Ak18VSywLFf9KhbTqyedxF
MfFxXyeo2+J8jpyvN7e+Sdh6ifkSfw4Q/kwD1ZS9gKipRdka1WxmOs0EPsGxxanm
frpGPqmV6Uqpjohcoyxtxs+RgkJorFOGI1kPNqKQXcwxyf3TLvvEOgmv3FxA/5eS
Linqzeb5cWTVhEL5SFpWbknp/KVsf/qcqnopXFnBVRh5P6lUvbHP8fF3bVC8f9mF
fpf9iprbDXKqxQ4ORzkzPGhzzD3Npp4DKNbt4+4YG+gomIXdDjiG2icpDqQz4Ac2
CuUzRuCnBAfWHhToJENXegu0bk8HJbWThdlu1w3ccUJk3b9ViS3qiU0CZIvJ3vWw
sHaMD6Q4Gt5bogqLJDpr9r5g7tbRtP8Q3KE/MgccDjzkB4SIH950yyNi6D4/yBH/
rPpH8JYfHm9VOLh8q7trLifqsbvhsoUtUgljfE2d4HAxNdwz7HbiYd1So5zaQJmU
IT4lnkOOHpZRqKIgEMhKvttVMTCYlJDS5+94d+Aa4i6y+eB49Puh9swkEQVftCJg
GiB00g0/cvtPCsl50/7m
=9q9P
-END PGP SIGNATURE-

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Loss of tunnel service while reauthenticating IKE_SA?

[Tom Rymes]

On 03/12/2015 11:16 AM, Noel Kuntze wrote:


Hello Ken,

It is dependent on the IKE version.
Quote from the man page:

reauth = yes | no
   whether rekeying of an IKE_SA  should  also  reauthenticate  the
   peer.  In  IKEv1,  reauthentication  is always done. In IKEv2, a
   value of no rekeys without uninstalling the IPsec SAs,  a  value
   of yes (the default) creates a new IKE_SA from scratch and tries
   to recreate all IPsec SAs.

Obviously, setting reauth=no will keep the tunnel up during rekeying of the IKE 
SAs.
You have to use "reauth=no" on both sides to make it work.


Noel,

Is there a reason that, when using two Strongswan endpoints, one would 
not choose reauth=no? It seems to me that using reauth=no would result 
in fewer traffic interruptions, unless I have missed something.


Tom
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Loss of tunnel service while reauthenticating IKE_SA?

[Noel Kuntze]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello Ken,

It is dependent on the IKE version.
Quote from the man page:

   reauth = yes | no
  whether rekeying of an IKE_SA  should  also  reauthenticate  the
  peer.  In  IKEv1,  reauthentication  is always done. In IKEv2, a
  value of no rekeys without uninstalling the IPsec SAs,  a  value
  of yes (the default) creates a new IKE_SA from scratch and tries
  to recreate all IPsec SAs.

Obviously, setting reauth=no will keep the tunnel up during rekeying of the IKE 
SAs.
You have to use "reauth=no" on both sides to make it work.

Mit freundlichen Grüßen/Kind Regards,
Noel Kuntze

GPG Key ID: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658

Am 12.03.2015 um 15:31 schrieb Ken Nelson:
> VPN client & server running StrongSwan v5.2.2.  Both OSes Centos 6.6.
>
> An IKEv2 IPsec tunnel has been up for a couple days with the client 
> initiating a ping, once per minute, of the same host behind the VPN gateway.  
> This is the only application level traffic on the tunnel.
>
> Roughly every two hours and 40 minutes, the client initiates the IKE SA 
> reauthentication sequence and some times the ping fails:
>
> 2015/03/12 13:14:20 - host ipa.cz.internal is ok
> ping: unknown host ipa.cz.internal
> 2015/03/12 13:15:20 - host ipa.cz.internal is down
> 2015/03/12 13:16:20 - host ipa.cz.internal is ok
>
>
> The .cz.internal DNS domain is served by a host (10.8.65.164) behind the VPN 
> gateway.  Here’s a snippet from the client log file showing the start of the 
> reauthentication and the removal of the DNS server from resolve.conf.
>
> Mar 12 13:15:10 secgw-client charon: 12[IKE] reauthenticating IKE_SA 
> cz-pdc[16]
> Mar 12 13:15:10 secgw-client charon: 12[IKE] deleting IKE_SA cz-pdc[16] 
> between 10.100.34.179[linux-test]...a.b.c.d[secgw.cz-dev.com 
> ]
> Mar 12 13:15:10 secgw-client charon: 12[IKE] sending DELETE for IKE_SA 
> cz-pdc[16]
> Mar 12 13:15:10 secgw-client charon: 12[ENC] generating INFORMATIONAL request 
> 9 [ D ]
> Mar 12 13:15:10 secgw-client charon: 12[NET] sending packet: from 
> 10.100.34.179[4500] to a.b.c.d[4500] (76 bytes)
> Mar 12 13:15:10 secgw-client charon: 10[NET] received packet: from 
> a.b.c.d[4500] to 10.100.34.179[4500] (76 bytes)
> Mar 12 13:15:10 secgw-client charon: 10[ENC] parsed INFORMATIONAL response 9 
> [ ]
> Mar 12 13:15:10 secgw-client charon: 10[IKE] IKE_SA deleted
> Mar 12 13:15:10 secgw-client vpn: - secgw.cz-dev.com 
>  10.8.64.0/23 == a.b.c.d -- 10.100.34.179 == 
> 10.255.252.1/32
> Mar 12 13:15:10 secgw-client charon: 10[IKE] installing new virtual IP 
> 10.255.252.1
> Mar 12 13:15:10 secgw-client charon: 10[IKE] restarting CHILD_SA cz-pdc
> Mar 12 13:15:10 secgw-client charon: 10[IKE] initiating IKE_SA cz-pdc[17] to 
> a.b.c.d
> Mar 12 13:15:10 secgw-client charon: 10[ENC] generating IKE_SA_INIT request 0 
> [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
> Mar 12 13:15:10 secgw-client charon: 10[NET] sending packet: from 
> 10.100.34.179[500] to a.b.c.d[500] (1420 bytes)
> Mar 12 13:15:10 secgw-client charon: 10[IKE] removing DNS server 10.8.65.164 
> from /etc/resolv.conf
>
>
> And a snippet from the server log file:
>
> Mar 12 13:15:10 secgw charon: 15[NET] received packet: from w.x.y.z[4500] to 
> 10.8.95.244[4500] (76 bytes)
> Mar 12 13:15:10 secgw charon: 15[ENC] parsed INFORMATIONAL request 9 [ D ]
> Mar 12 13:15:10 secgw charon: 15[IKE] received DELETE for IKE_SA 
> remote-access-ikev2-krb[15]
> Mar 12 13:15:10 secgw charon: 15[IKE] deleting IKE_SA 
> remote-access-ikev2-krb[15] between 10.8.95.244[secgw.cz-dev.com 
> ]...w.x.y.z[linux-test]
> Mar 12 13:15:10 secgw charon: 15[IKE] IKE_SA remote-access-ikev2-krb[15] 
> state change: ESTABLISHED => DELETING
> Mar 12 13:15:10 secgw charon: 15[IKE] IKE_SA deleted
>
> The clocks on each machine are synchronized using NTP.  The two hosts take 
> ~11-12 seconds to complete the reauthentication sequence and the continuous 
> ping succeeds.
>
> The continuous ping is pretty tolerant of the network outage and since it’s 
> stateless and only occurs every 60 seconds - it often does not notice the 
> outage.  However, if I ran highly sensitive application like a file transfer, 
> would the entire transfer fail?  Is reauthentication equivalent to 
> terminating and restarting the tunnel?
>
>
>
>
>
> ___
> Users mailing list
> Users@lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVAa21AAoJEDg5KY9j7GZYIs0P/3Q8ZBFLLXu6fKuaN+MA6RGO
/L4gMyAjzzwEcWs8MwB2kzC6oeS8vhabbcalQ973zAmfmn08UPeQnUIUOBjcLwQJ
ZTNohvsNtSwvxZGD1enEgdls8YFd0GtyplBzCupj8YOCyU0hBs4NN4UJ768geoxM
Io1Lt3Wf2w+EKNUeEFxhet+aoXscAdaU9VYWpzoXDKgyqsRa/LomkjP69D8lijLm
4rdLe3n1FZc4WxLkDmN+JscRi1CkMXNN2PyqMcMLLdABkI9/2eqRhaRb7CtezfpL
vy

[strongSwan] Loss of tunnel service while reauthenticating IKE_SA?

[Ken Nelson]

VPN client & server running StrongSwan v5.2.2.  Both OSes Centos 6.6.

An IKEv2 IPsec tunnel has been up for a couple days with the client initiating 
a ping, once per minute, of the same host behind the VPN gateway.  This is the 
only application level traffic on the tunnel.

Roughly every two hours and 40 minutes, the client initiates the IKE SA 
reauthentication sequence and some times the ping fails:

2015/03/12 13:14:20 - host ipa.cz.internal is ok
ping: unknown host ipa.cz.internal
2015/03/12 13:15:20 - host ipa.cz.internal is down
2015/03/12 13:16:20 - host ipa.cz.internal is ok


The .cz.internal DNS domain is served by a host (10.8.65.164) behind the VPN 
gateway.  Here’s a snippet from the client log file showing the start of the 
reauthentication and the removal of the DNS server from resolve.conf.

Mar 12 13:15:10 secgw-client charon: 12[IKE] reauthenticating IKE_SA cz-pdc[16]
Mar 12 13:15:10 secgw-client charon: 12[IKE] deleting IKE_SA cz-pdc[16] between 
10.100.34.179[linux-test]...a.b.c.d[secgw.cz-dev.com]
Mar 12 13:15:10 secgw-client charon: 12[IKE] sending DELETE for IKE_SA 
cz-pdc[16]
Mar 12 13:15:10 secgw-client charon: 12[ENC] generating INFORMATIONAL request 9 
[ D ]
Mar 12 13:15:10 secgw-client charon: 12[NET] sending packet: from 
10.100.34.179[4500] to a.b.c.d[4500] (76 bytes)
Mar 12 13:15:10 secgw-client charon: 10[NET] received packet: from 
a.b.c.d[4500] to 10.100.34.179[4500] (76 bytes)
Mar 12 13:15:10 secgw-client charon: 10[ENC] parsed INFORMATIONAL response 9 [ ]
Mar 12 13:15:10 secgw-client charon: 10[IKE] IKE_SA deleted
Mar 12 13:15:10 secgw-client vpn: - secgw.cz-dev.com 
10.8.64.0/23 == a.b.c.d -- 10.100.34.179 == 10.255.252.1/32
Mar 12 13:15:10 secgw-client charon: 10[IKE] installing new virtual IP 
10.255.252.1
Mar 12 13:15:10 secgw-client charon: 10[IKE] restarting CHILD_SA cz-pdc
Mar 12 13:15:10 secgw-client charon: 10[IKE] initiating IKE_SA cz-pdc[17] to 
a.b.c.d
Mar 12 13:15:10 secgw-client charon: 10[ENC] generating IKE_SA_INIT request 0 [ 
SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
Mar 12 13:15:10 secgw-client charon: 10[NET] sending packet: from 
10.100.34.179[500] to a.b.c.d[500] (1420 bytes)
Mar 12 13:15:10 secgw-client charon: 10[IKE] removing DNS server 10.8.65.164 
from /etc/resolv.conf


And a snippet from the server log file:

Mar 12 13:15:10 secgw charon: 15[NET] received packet: from w.x.y.z[4500] to 
10.8.95.244[4500] (76 bytes)
Mar 12 13:15:10 secgw charon: 15[ENC] parsed INFORMATIONAL request 9 [ D ]
Mar 12 13:15:10 secgw charon: 15[IKE] received DELETE for IKE_SA 
remote-access-ikev2-krb[15]
Mar 12 13:15:10 secgw charon: 15[IKE] deleting IKE_SA 
remote-access-ikev2-krb[15] between 
10.8.95.244[secgw.cz-dev.com]...w.x.y.z[linux-test]
Mar 12 13:15:10 secgw charon: 15[IKE] IKE_SA remote-access-ikev2-krb[15] state 
change: ESTABLISHED => DELETING
Mar 12 13:15:10 secgw charon: 15[IKE] IKE_SA deleted

The clocks on each machine are synchronized using NTP.  The two hosts take 
~11-12 seconds to complete the reauthentication sequence and the continuous 
ping succeeds.

The continuous ping is pretty tolerant of the network outage and since it’s 
stateless and only occurs every 60 seconds - it often does not notice the 
outage.  However, if I ran highly sensitive application like a file transfer, 
would the entire transfer fail?  Is reauthentication equivalent to terminating 
and restarting the tunnel?



___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] High availability failover problem

[unite]

On 2015-03-11 10:35, Martin Willi wrote:

Hi,


Is it essential for both nodes to receive all the ESP packets?


Yes.


Cannot be ESP sequence numbers synchronized through the HA plugin?


No, this is not how the HA plugin works. ESP sequence numbers move very
fast, making a synchronization in userland difficult.

You may try to synchronize sequence numbers by other means, but we 
don't

provide any solution beyond our ClusterIP patches.

Regards
Martin


Thanks for your help, Martin. Now it's clear for me.

--
With kind regards,
Aleksey
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] udp packet size

[Fred]

On 12/03/2015 08:29, Martin Willi wrote:

IKEv2 fragmentation is a protocol extension (RFC 7383), and AFAIK it is
not supported in the Windows client. So you can't use it with these
clients, but have to try to avoid messages larger than your MTU to get
things working on such constrained networks.


I seem to keep running into exactly the same issues as other people at 
more or less the same time.  What a co-incidence! I was looking into 
this late last night; here are my thoughts.


I have Windows Phone 8.1 working nicely against strongSwan over wired 
networks and WiFi.  but over 3G/HSDPA mobile data networks the same 
working connection doesn't work. It fails in the ikev2 auth. A 1500 byte 
packet is sent but is retransmitted many times before finally failing. 
tcpdump shows flags [+] indicating fragmentation (offset is 0). I can 
provide packet dumps on request if helpful. So something in the path 
doesn't like the fragmentation.


I wanted to look into path MTU being the culprit but I wasn't able to 
detect the lowest MTU in the path since the mobile device is firewalled 
by the network operator. People also do block UDP fragments, so I looked 
into trying to preload the certificates to minimise data size in the 
exchange. This didn't work. Presumably the WP always requests the vpn 
cert? Setting sendleftcert=never breaks the connection in any case. So I 
then looked into the fragmentation=yes feature. It didn't work, or 
rather I couldn't get it to work and packet captures showed the messages 
were STILL being fragmented despite me setting strongSwan fragment_size. 
I had a think about how this feature might work, and it dawned on me 
that this feature would have to be supported at both endpoints for 
reassembly at the other end (it was late!).  Reading the relevant 
section in the RFC confirmed this. Obviously there's no Microsoft 
documentation about whether or not this feature is supported in their 
VPN Reconnect client; but it appears not. Shame there's no strongSwan 
app in the Windows Store ;-)




___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] VPN not routing traffic, how to troubleshoot?

[Aaron Roquena]

Bingo! Forwarding was disabled and things were working again with:

# modprobe iptable_nat
# echo 1 > /proc/sys/net/ipv4/ip_forward

Aaron
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] udp packet size

[Martin Willi]

Hi Steffen,

> Strongswan 5.2.2 on linux (centos 6) IKEv2 configuration for windows
> clients I have the following problem:

> My more specific question is why is the outgoing UDP packet size
> greater than the MTU size on the interface?

In an IKE_AUTH response, the large part of the message is probably the
exchanged certificate. You may try to generate a smaller server
certificate (chain) so that this message fits in your MTU.

> I have tried to modify the charon.fragment_size and conn specific
> fragmentation settings and cannot get this modify the behavior.

IKEv2 fragmentation is a protocol extension (RFC 7383), and AFAIK it is
not supported in the Windows client. So you can't use it with these
clients, but have to try to avoid messages larger than your MTU to get
things working on such constrained networks.

Regards
Martin

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users