Re: [strongSwan] Tunnel stability issues after upgrade from 4.5.2 to 5.5.1

[Justin Pryzby]

On Wed, Mar 07, 2018 at 10:52:54AM +0100, Martijn Grendelman wrote:
> I have been running StrongSwan on Debian Wheezy (with StrongSwan 4.5.2)
> for a long time.
[...]

> Last week, I upgraded the system to Debian Stretch (with StrongSwan
> 5.5.1), and since then, a number of tunnels (but not all of them) have
> stability issues. The issue appears to be that CHILD_SA's are not
> established when needed,

Maybe you know that in 5.0, IKEv1 was integrated into charon and separate pluto
daemon was retired:
https://www.strongswan.org/blog/2012/07/02/strongswan-5.0.0-released.html
https://wiki.strongswan.org/projects/strongswan/wiki/CharonPlutoIKEv1
https://www.strongswan.org/blog/2012/06/20/bye-bye-pluto.html
https://wiki.strongswan.org/projects/strongswan/wiki/500

Just wondering: are all the tunnels with issues have multiple child SAs (or,
the tunnels without issues all have only one child SA).

I recently reported an issue here, also related to a migration/update from 4.5,
and started to suspect that multiple child SAs may be involved..
https://wiki.strongswan.org/issues/2535

Note, I believe swanctl.conf allows configuring child SAs to use separate IKEs
- avoiding the non-configurable behavior in starter+ipsec.conf: "added child to
  existing configuration".  However that doesn't work for everyone(us) due to
unique policy on remote peers.

Justin

Re: [strongSwan] Tunnel stability issues after upgrade from 4.5.2 to 5.5.1

[Martijn Grendelman]

Hi Tom,

Thank you, I will give that a try. I also updated StrongSwan to v5.6.2.
Let's see if it helps!

Best regards,
Martijn.

Op 7-3-2018 om 16:35 schreef Tom Rymes:
> Martin,
>
> I can't help with the more technical portions of your query, but I can
> confirm that using auto=route has proven to be more reliable than
> auto=start, as a dropped tunnel seems more likely to be brought back
> up automatically.
>
> I had asked specifically about that setting a few years ago, and this
> is the advice I received:
>
> https://lists.strongswan.org/pipermail/users/2015-July/008552.html
>
> Tom
>
> On Mar 7, 2018, at 1:53 AM, Martijn Grendelman
> > wrote:
>
>> Hi,
>>
>> I have been running StrongSwan on Debian Wheezy (with StrongSwan 4.5.2)
>> for a long time. We have about 70 ESP tunnels with 19 different
>> endpoints, most of them IKEv1. The setup has been rock solid for years,
>> with tunnel outages being extremely rare, and almost always the remote
>> side's fault.
>>
>> Last week, I upgraded the system to Debian Stretch (with StrongSwan
>> 5.5.1), and since then, a number of tunnels (but not all of them) have
>> stability issues. The issue appears to be that CHILD_SA's are not
>> established when needed, or they disappear after some time. I haven't
>> really discovered a pattern, and I'm a bit overwhelmed by Charon's
>> logging output at higher levels. The problems are restricted to IKEv1
>> connections, IKEv2 connections seem unaffected. There don't seem to be
>> any issues establishing IKE SAs.
>>
>> Since I didn't make any changes to the configuration in the course of
>> the upgrade, I can imagine that my config is not up to the standards of
>> version 5. I pasted relevant parts of my config below. Are there things
>> that can be improved?
>>
>> I am sorry I can't be more concrete. I am mostly looking for pointers on
>> how to solve the issues.
>>
>> If I want to know why a CHILD_SA is not established, what logging
>> settings should I use? I'd like some pointers to what kind of messages
>> to look for, and at what level from which subsystem they would be
>> logged. Currently, I have this:
>>
>>     /var/log/charon.log {
>>     time_format = %b %e %T
>>     ike_name = yes
>>     append = yes
>>     default = 1
>>     cfg = 4
>>     net = 0
>>     flush_line = yes
>>     }
>>
>> The problem is, that with 70 tunnels, raising the default log level
>> higher than 1 leads to A LOT of logging (GBs / day) which quickly
>> becomes hard to digest.
>>
>> Here are my 'default' config and some config samples for connections
>> that suffer from these problems. The example describes two tunnels to
>> the same endpoint. Only 'leftsubnet' differs. In total, there are 16
>> tunnels to this endpoint, all sharing the same IKE SA. They only differ
>> in left- and rightsubnet. Does this make sense?
>>
>> conn %default
>>     ikelifetime=8h
>>     keylife=1h
>>     rekeymargin=9m
>>     authby=secret
>>     keyexchange=ikev2
>>     mobike=no
>>     auto=start
>>     leftfirewall=no
>>     lefthostaccess=no
>>     closeaction=restart
>>     dpdaction=restart
>>     keyingtries=%forever
>>
>> conn hq_uk_b4a
>>     left=
>>     leftsubnet=172.17.1.0/24
>>     right=
>>     rightsubnet=10.53.13.0/24
>>     ike=aes256-sha1-modp1024
>>     esp=aes256-sha1-modp1024
>>     keyexchange=ikev1
>>     ikelifetime=8h
>>
>> conn hq_uk_b4b
>>     left=
>>     leftsubnet=172.17.5.0/24
>>     right=
>>     rightsubnet=10.53.13.0/24
>>     ike=aes256-sha1-modp1024
>>     esp=aes256-sha1-modp1024
>>     keyexchange=ikev1
>>     ikelifetime=8h
>>
>> Hoping for some useful pointers...
>>
>> Best regards,
>> Martijn Grendelman.
>>

-- 
Met vriendelijke groet,
Kind regards,
Martijn 
Martijn Grendelman  Infrastructure Architect  
T: +31 (0)40 264 94 44   

ISAAC 
Marconilaan 16   5621 AA Eindhoven   The Netherlands
T: +31 (0)40 290 89 79   www.isaac.nl 

Dit e-mail bericht is alleen bestemd voor de geadresseerde(n). Indien
dit bericht niet voor u is bedoeld wordt u verzocht de afzender hiervan
op de hoogte te stellen door het bericht te retourneren en de inhoud
niet te gebruiken. Aan dit bericht kunnen geen rechten worden ontleend.

Re: [strongSwan] Tunnel stability issues after upgrade from 4.5.2 to 5.5.1

[Tom Rymes]

Martin,

I can't help with the more technical portions of your query, but I can confirm 
that using auto=route has proven to be more reliable than auto=start, as a 
dropped tunnel seems more likely to be brought back up automatically.

I had asked specifically about that setting a few years ago, and this is the 
advice I received:

https://lists.strongswan.org/pipermail/users/2015-July/008552.html

Tom

> On Mar 7, 2018, at 1:53 AM, Martijn Grendelman  
> wrote:
> 
> Hi,
> 
> I have been running StrongSwan on Debian Wheezy (with StrongSwan 4.5.2)
> for a long time. We have about 70 ESP tunnels with 19 different
> endpoints, most of them IKEv1. The setup has been rock solid for years,
> with tunnel outages being extremely rare, and almost always the remote
> side's fault.
> 
> Last week, I upgraded the system to Debian Stretch (with StrongSwan
> 5.5.1), and since then, a number of tunnels (but not all of them) have
> stability issues. The issue appears to be that CHILD_SA's are not
> established when needed, or they disappear after some time. I haven't
> really discovered a pattern, and I'm a bit overwhelmed by Charon's
> logging output at higher levels. The problems are restricted to IKEv1
> connections, IKEv2 connections seem unaffected. There don't seem to be
> any issues establishing IKE SAs.
> 
> Since I didn't make any changes to the configuration in the course of
> the upgrade, I can imagine that my config is not up to the standards of
> version 5. I pasted relevant parts of my config below. Are there things
> that can be improved?
> 
> I am sorry I can't be more concrete. I am mostly looking for pointers on
> how to solve the issues.
> 
> If I want to know why a CHILD_SA is not established, what logging
> settings should I use? I'd like some pointers to what kind of messages
> to look for, and at what level from which subsystem they would be
> logged. Currently, I have this:
> 
> /var/log/charon.log {
> time_format = %b %e %T
> ike_name = yes
> append = yes
> default = 1
> cfg = 4
> net = 0
> flush_line = yes
> }
> 
> The problem is, that with 70 tunnels, raising the default log level
> higher than 1 leads to A LOT of logging (GBs / day) which quickly
> becomes hard to digest.
> 
> Here are my 'default' config and some config samples for connections
> that suffer from these problems. The example describes two tunnels to
> the same endpoint. Only 'leftsubnet' differs. In total, there are 16
> tunnels to this endpoint, all sharing the same IKE SA. They only differ
> in left- and rightsubnet. Does this make sense?
> 
> conn %default
> ikelifetime=8h
> keylife=1h
> rekeymargin=9m
> authby=secret
> keyexchange=ikev2
> mobike=no
> auto=start
> leftfirewall=no
> lefthostaccess=no
> closeaction=restart
> dpdaction=restart
> keyingtries=%forever
> 
> conn hq_uk_b4a
> left=
> leftsubnet=172.17.1.0/24
> right=
> rightsubnet=10.53.13.0/24
> ike=aes256-sha1-modp1024
> esp=aes256-sha1-modp1024
> keyexchange=ikev1
> ikelifetime=8h
> 
> conn hq_uk_b4b
> left=
> leftsubnet=172.17.5.0/24
> right=
> rightsubnet=10.53.13.0/24
> ike=aes256-sha1-modp1024
> esp=aes256-sha1-modp1024
> keyexchange=ikev1
> ikelifetime=8h
> 
> Hoping for some useful pointers...
> 
> Best regards,
> Martijn Grendelman.
> 

[strongSwan] best practice for IKEv2 lifetimes

[Waldemar Brodkorb]

Hi,

We are using Strongswan 5.5.1 on Debian 9 with IKEv2.
The other sides are Cisco ISR 2900 routers. The connection works
fine, but sometimes we have a disconnect and the tunnels on the
Cisco side marked as down. After /etc/init.d/ipsec restart
everything works again.

In the early days when I started using IPsec this always meant to
be a difference in the lifetime configured for IKE SA or IPsec SA.

I am new to IKEv2 and started investigating the problem, the RFC7296
clearly states: "A difference between IKEv1 and IKEv2 is that in
IKEv1 SA lifetimes were negotiated.  In IKEv2, each end of the SA is
responsible for enforcing its own lifetime policy on the SA and
rekeying the SA when necessary.  If the two ends have different
lifetime policies, the end with the shorter lifetime will end up
always being the one to request the rekeying."

What is best practice to define a lifetime? 
Should it be defined on the Cisco side or on the Strongswan side?
Or on both sides different to avoid simultaneous rekeying?
Strongswan has some options for jittering the lifetime, but I think
Cisco side does not have it.
What if I want IKE SA rekeying after 24 hours and IPsec SA rekeying
after 1 hours?

We use ipsec.conf, our template looks like this for now:
config setup
  # Enable debug logs:
#charondebug="ike 2, cfg 2"
charonstart=yes
conn %default
ikelifetime=1440m
keylife=60m
ike=aes256-sha512-modp4096
esp=aes256-sha512
rekeymargin=3m
keyingtries=1
mobike=no
keyexchange=ikev2
authby=rsasig

conn host-vpn1
leftcert=<%= @fqdn %>.pem
left=%any
right=<%= @router1 %>
rightid=%any
type=transport
auto=add

conn host-vpn2
leftcert=<%= @fqdn %>.pem
left=%any
right=<%= @router2 %>
rightid=%any
type=transport
auto=add

Should I better add "reauth = no" to avoid short connection outage and
just explicitely enable "rekey = yes" and "rekeyfuzz = 100%" to avoid
rekeying of both tunnels in the same timeframe?

best regards
 Waldemar

Re: [strongSwan] One to Many VPN (Host-Host)

[Info]

Any input would be appreciated.


On 03/05/2018 05:25 PM, Info wrote:
>
> On 03/05/2018 12:13 PM, Info wrote:
>>
>> I'm looking to VPN every machine in a LAN.  I infer that this would
>> be something like a host-to-host config.
>>
>> I'll use swanctl/vici and x509 certs.
>>
>> I can't identify any configurations that seem right for this at
>>
>> https://www.strongswan.org/testing/testresults/swanctl/
>>
>> Maybe? 
>> https://www.strongswan.org/testing/testresults/swanctl/ip-pool/index.html
>>
>>
>> Also, there is a machine outside on the Internet which I'd like to
>> join the party transparently.  It's a mail server, so somehow I'd
>> like its mail traffic to not be VPNed, but everything else to be.  I
>> guess this might be a roadwarrior with some kind of split for the
>> mail ports.
>>
>
> So my best idea, since IPSec is point-to-point, is to set up a 'hub
> and spoke' config.  IOW designate one machine as the hub and its
> remote_addrs are IPs of the multiple other members of the LAN which
> will be in the VPN.  Or maybe just the CIDR/24 of the LAN.  And all
> the other members would point to the hub with their remote_addrs.  The
> hub would be a juicy target for attack though, and forwarding must be on.
>
> Of course the traffic selectors would be the CIDR/24 of the LAN,
> although I haven't figured out how to include a remote machine in the
> ts since its IP could change.  Maybe I could use its resolvable domain
> name, and DNAT it in through the firewall to the hub.  But this
> doesn't solve the problem of phones and tablets which change outside
> IPs and don't have resolvable domain names.
>
> And what would 'remote' id= be in the hub?  %any?
>
>

Re: [strongSwan] dhcp plugin using CN or FQDN as the client host name?

[Harald Dunkel]

On 03/06/18 10:42, Tobias Brunner wrote:

Hi Harald,


Question is, how can I tell charon's dhcp plugin to forward either
the FQDN or the CN from the DN entry in the dhcp request?


You can't, the plugin simply uses the client's (IKE or EAP) identity, so
it's up to the client to use the identity you want to see on the server.



OK, so how can I tell charon-nm?


You currently can't.



That hurts alot. Hope you don't mind that I created an
enhancement request for this:

https://wiki.strongswan.org/issues/2581


Regards
Harri

Re: [strongSwan] ssh and http through IPSec

[Sujoy]

Hi Jafar,

I am not getting any output during "*ip route list table 220*" the 
tunnel is established. And it is not allowing any type of traffic any 
idea what should be the issue.



[root@VPNTEST ~]# ipsec statusall
Status of IKE charon daemon (strongSwan 5.3.3, Linux 
3.10.0-693.11.6.el7.x86_64, x86_64):

  uptime: 8 minutes, since Mar 07 17:00:51 2018
  malloc: sbrk 2568192, mmap 0, used 403312, free 2164880
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, 
scheduled: 3
  loaded plugins: charon aes des rc2 sha1 sha2 md5 random nonce x509 
revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey 
pem openssl fips-prf gmp xcbc cmac hmac curl attr kernel-netlink resolve 
socket-default stroke updown xauth-generic

Listening IP addresses:
  172.25.1.23
Connections:
  tunnel:  %any...%any  IKEv2, dpddelay=30s
  tunnel:   local:  uses pre-shared key authentication
  tunnel:   remote: uses pre-shared key authentication
  tunnel:   child:  0.0.0.0/0 === 0.0.0.0/0 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):
  tunnel[2]: ESTABLISHED 27 seconds ago, 
172.25.1.23[X.X.X.X]...106.216.163.71[192.168.10.40]
  tunnel[2]: IKEv2 SPIs: f8417e08c414c0ee_i a8648d0d206c_r*, 
rekeying disabled
  tunnel[2]: IKE proposal: 
AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
  tunnel{3}:  INSTALLED, TUNNEL, reqid 3, ESP in UDP SPIs: 
c06d3ac1_i cd4c518b_o
  tunnel{3}:  AES_CBC_256/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, 
rekeying disabled

  tunnel{3}:   X.X.X.X/32 === 192.168.10.40/32
[root@VPNTEST ~]#
[root@VPNTEST ~]#
[root@VPNTEST ~]# ip route list table 220
[root@VPNTEST ~]#


[root@VPNTEST ~]# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source   destination
ACCEPT udp  --  anywhere anywhere udp dpt:isakmp
ACCEPT udp  --  anywhere anywhere udp 
dpt:ipsec-nat-t

ACCEPT esp  --  anywhere anywhere

Chain FORWARD (policy ACCEPT)
target prot opt source   destination

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination
[root@VPNTEST ~]#



Thanks

On Tuesday 06 March 2018 10:46 AM, Sujoy wrote:

Hi Jafar,

  Thanks for the information. The ping is stopped as soon as the 
tunnel is established to the right IP of the client. I cannot 
ping/ssh/http(wget/curl) to the IPsec VPN server. It is the same IP 
address where the tunnel terminates.



Server configuration

config setup
    charondebug="ike 3, net 3, mgr 3, esp 3, chd 3, dmn 3, cfg 3, 
knl 3"

    strictcrlpolicy=no
    uniqueids=no
conn %default
conn tunnel #
   left=%any
   leftsubnet=0.0.0.0/0
   right=%any
   rightsubnet=0.0.0.0/0
   ike=aes256-sha1-modp2048
   esp=aes256-sha1
   keyingtries=1
   keylife=20
   dpddelay=30s
   dpdtimeout=150s
   dpdaction=restart
   authby=psk
   auto=start
   keyexchange=ikev2
   type=tunnel
   mobike=no

Client output

root@Device_BD2009:~# ipsec statusall
no files found matching '/etc/strongswan.d/*.conf'
Status of IKE charon daemon (strongSwan 5.3.3, Linux 3.10.49, mips):
  uptime: 25 seconds, since Mar 06 13:00:41 2018
  malloc: sbrk 196608, mmap 0, used 163488, free 33120
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, 
scheduled: 17
  loaded plugins: charon aes des rc2 sha1 sha2 md5 random nonce x509 
revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey 
sshkey pem openssl fips-prf gmp xcbc cmac hmac curl attr 
kernel-netlink resolve socket-default stroke updown eap-identity 
eap-md5 xauth-generic

Listening IP addresses:
  192.168.20.100
  192.168.10.1
  fd70:5f2:3744::1
Connections:
  tunnel:  %any...X.X.X.X  IKEv2, dpddelay=30s
  tunnel:   local:  uses pre-shared key authentication
  tunnel:   remote: [X.X.X.X] uses pre-shared key authentication
  tunnel:   child:  dynamic === X.X.X.X/X TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):
  tunnel[1]: ESTABLISHED 23 seconds ago, 
192.168.20.100[192.168.20.100]...X.X.X.X[X.X.X.X]
  tunnel[1]: IKEv2 SPIs: 221d0271a9235270_i* 485e938bf49b2110_r, 
pre-shared key reauthentication in 2 hours
  tunnel[1]: IKE proposal: 
AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
  tunnel{21}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: 
c25c0775_i c559455b_o
  tunnel{21}:  AES_CBC_256/HMAC_SHA1_96, 0 bytes_i, 84 bytes_o (1 
pkt, 0s ago), rekeying active

  tunnel{21}:   192.168.20.100/32 === X.X.X.X/32


Thanks

On Monday 05 March 2018 09:58 PM, Jafar Al-Gharaibeh wrote:

Hi Sujoy,

  Can you ping the the server's IP address that you want to ssh to ?
  Is that the same IP address where the tunnel terminates: the 
"right" address on the client side ?


--Jafar


On 3/5/2018 12:31 AM, Sujoy wrote:

Hi Christopher,


 Thanks for the response. I want to access the CentOS IPSec server 
which 

[strongSwan] Tunnel stability issues after upgrade from 4.5.2 to 5.5.1

[Martijn Grendelman]

Hi,

I have been running StrongSwan on Debian Wheezy (with StrongSwan 4.5.2)
for a long time. We have about 70 ESP tunnels with 19 different
endpoints, most of them IKEv1. The setup has been rock solid for years,
with tunnel outages being extremely rare, and almost always the remote
side's fault.

Last week, I upgraded the system to Debian Stretch (with StrongSwan
5.5.1), and since then, a number of tunnels (but not all of them) have
stability issues. The issue appears to be that CHILD_SA's are not
established when needed, or they disappear after some time. I haven't
really discovered a pattern, and I'm a bit overwhelmed by Charon's
logging output at higher levels. The problems are restricted to IKEv1
connections, IKEv2 connections seem unaffected. There don't seem to be
any issues establishing IKE SAs.

Since I didn't make any changes to the configuration in the course of
the upgrade, I can imagine that my config is not up to the standards of
version 5. I pasted relevant parts of my config below. Are there things
that can be improved?

I am sorry I can't be more concrete. I am mostly looking for pointers on
how to solve the issues.

If I want to know why a CHILD_SA is not established, what logging
settings should I use? I'd like some pointers to what kind of messages
to look for, and at what level from which subsystem they would be
logged. Currently, I have this:

    /var/log/charon.log {
    time_format = %b %e %T
    ike_name = yes
    append = yes
    default = 1
    cfg = 4
    net = 0
    flush_line = yes
    }

The problem is, that with 70 tunnels, raising the default log level
higher than 1 leads to A LOT of logging (GBs / day) which quickly
becomes hard to digest.

Here are my 'default' config and some config samples for connections
that suffer from these problems. The example describes two tunnels to
the same endpoint. Only 'leftsubnet' differs. In total, there are 16
tunnels to this endpoint, all sharing the same IKE SA. They only differ
in left- and rightsubnet. Does this make sense?

conn %default
    ikelifetime=8h
    keylife=1h
    rekeymargin=9m
    authby=secret
    keyexchange=ikev2
    mobike=no
    auto=start
    leftfirewall=no
    lefthostaccess=no
    closeaction=restart
    dpdaction=restart
    keyingtries=%forever

conn hq_uk_b4a
    left=
    leftsubnet=172.17.1.0/24
    right=
    rightsubnet=10.53.13.0/24
    ike=aes256-sha1-modp1024
    esp=aes256-sha1-modp1024
    keyexchange=ikev1
    ikelifetime=8h

conn hq_uk_b4b
    left=
    leftsubnet=172.17.5.0/24
    right=
    rightsubnet=10.53.13.0/24
    ike=aes256-sha1-modp1024
    esp=aes256-sha1-modp1024
    keyexchange=ikev1
    ikelifetime=8h

Hoping for some useful pointers...

Best regards,
Martijn Grendelman.