Re: [strongSwan] Timeout on poor connection

[Anvar Kuchkartaev]

Yes I completely forgot about dpdtimeout scenario.
dpdtimeout in my case left to its default value in server which is 150s
and dpdtimeout in client is 20s
I hope it helps.


  On Wed, 04 Oct 2017 23:55:07 +0200 Noel Kuntze 
 wrote  
 > You do not need to explicitely accept frag-needed. It is included in ctstate 
 > RELATED. 
 >  
 > dpddelay sets the interval between dpd packets, not when dpdaction is taken. 
 > dpdtimeout controls when the action is taken. 
 >  
 > The firewall rules you mentioned are needed anyway and do not deserve the 
 > term optimization. Not using them commonly breaks scenarios, 
 > and they are vital to having working tunnels. 
 >  
 > strongSwan is specifically optimized for multi core CPUs. You probably have 
 > problems because the CPU scheduler moves the threads around a lot. 
 > You can try working around that by tuning it(, upgrading your kernel hoping 
 > that it fixes that) or by changing the code to pin the threads to certain 
 > CPUs. 
 >  
 > I hope you optimized the strongSwan settings to make efficient use of 
 > parallelism by using hashtables[1]. 
 >  
 > [1] https://wiki.strongswan.org/projects/strongswan/wiki/IkeSaTable 
 >  
 > On 04.10.2017 08:55, Anvar Kuchkartaev wrote: 
 > > TCPMSS parameters in firewall are required proper routing of tcp 
 > > connections of client within the ipsec tunnel but: 
 > >  iptables -A INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT  
 > > 
 > > Rule can help to udp connections when mtu changes. The Same thing happened 
 > > on me when connection from clients ISP being throttled and dropped 
 > > silently. Use: 
 > > 
 > > dpddelay=300s ‎ 
 > > ‎dpdaction=clear 
 > > 
 > > On server side (this will check dead peers and remove them in every 300 
 > > seconds in your case if client disappears maximum after 300s he/she can 
 > > connect, you might decrease 300s to find optimal time) 
 > > 
 > > And use: 
 > > 
 > > dpddelay=5s 
 > > dpdaction=restart 
 > > 
 > > On client side (if connection dropped client will check in each 5s and 
 > > restart connection automatically if it drops) 
 > > In this case server will drop connections if they completely disconnected 
 > > within the 300s maximum and client will restart the connection in 5s if 
 > > temporary failure occured due to packet loss. 
 > > 
 > > Also adding mobike=yes into ipsec.conf connections and changing 
 > > reuse_ikesa to yes in strongswan.d/charon.conf will help connection remain 
 > > active even if ip changes or temporary disruptions (if client uses mobile 
 > > 3G connection with high latency and low bandwith). 
 > > 
 > > Anvar Kuchkartaev  
 > > an...@anvartay.com  
 > >   Original Message   
 > > From: Stephen Scheck 
 > > Sent: martes, 3 de octubre de 2017 09:18 p.m. 
 > > To: Anvar Kuchkartaev 
 > > Cc: Jamie Stuart; users@lists.strongswan.org 
 > > Subject: Re: [strongSwan] Timeout on poor connection 
 > > 
 > > 
 > > Thanks for the configs. 
 > > 
 > > I added the dpd* parameters to my configurations. My situation is a little 
 > > different in that my traffic is primarily UDP, so the TCP MSS settings are 
 > > not needed. I also need to use IKEv1. Furthermore, I’m running a scale 
 > > test in which there’s low latency and plenty of bandwidth, which may 
 > > nonetheless be saturated by the number of simultaneous connections which 
 > > are being attempted. 
 > > 
 > > Unfortunately, the dpd* parameters did not help. I still notice a small 
 > > number (25-50) connections out of several thousand which fail to 
 > > establish, and stay that way until the StrongSwans are restarted. 
 > > 
 > > Does anybody know of any further parameters which may influence connection 
 > > attempts and retries? 
 > > 
 > > One thing that I’ve noted is that if I run both the client and server 
 > > StrongSwan processes on single core machines, or with the StrongSwan 
 > > threads pinned to a single CPU, the success rate is *decidedly better* 
 > > than with multiple cores available (although, occasionally, even then a 
 > > couple of them fail to establish and stay “stuck”). 
 > > 
 > > I’m beginning to think there may be some troublesome concurrency bugs in 
 > > the StrongSwan IKEv1 routines. 
 > > 
 > > Any help appreciated! 
 > > 
 > > 
 > > 
 > >> On Sep 30, 2017, at 7:14 PM, Anvar Kuchkartaev  
 > >> wrote: 
 > >> 
 > >> ipsec.conf 
 > >> 
 > >> keyexchange=ikev2 
 > >> type=tunnel 
 > >> dpdaction=clear 
 > >> dpddelay=300s 
 > >> rekey=yes 
 > >> left=%any 
 > >> right=%any 
 > >> fragmentation=yes 
 > >> compress=yes 
 > >> 
 > >> parameters from server side and: 
 > >> 
 > >> dpdtimeout=20s 
 > >> dpddelay=5s 
 > >> dpdaction=restart 
 > >> 
 > >> from client side I think most important. 
 > >> 
 > >> Also you have to do several server optimizations like: 
 > >> 
 > >> 
 > >> firewall: 
 > >> 
 > >> iptables -A INPUT -p esp -j ACCEPT 
 > >> 
 > >> iptables -A INPUT -p udp -m multiport 

Re: [strongSwan] (no subject)

[Noel Kuntze]

Hi Sandesh

There's no POSTROUTING chain in the *filter table, so your command will never 
work.
The table is probably *mangle, because *nat never gets packets with ctstate 
INVALID.
You're probably missing something major here.

Please provide the information listed here[1] using the provided commands.

[1] https://wiki.strongswan.org/projects/strongswan/wiki/HelpRequests

On 03.10.2017 14:34, Sandesh Sawant wrote:
> Hi Noel,
> 
> Apologies for late response. The setup I was using had to be dismantled and 
> rebuilt. After further debugging it is found that this issue isn't related to 
> strongswan/xfrm behavior - it's related to firewall. The reason for the VTI 
> ping not going out of ipsec tunnel was a firewall rule: iptables -A 
> POSTROUTING -m state --state INVALID -j DROP
> If this rule is deleted or overridden with iptables -I POSTROUTING -o vNic_0 
> -j ACCEPT
> then everything works fine. But I don't want to do it for security reasons. 
> Any idea why packet originating from VTI and entering corresponding tunnel 
> local endpoint interface is considered as INVALID state?
>  
> Thanks,
> Sandesh
> 
> On Fri, Sep 22, 2017 at 2:50 PM, Noel Kuntze 
>  > wrote:
> 
> Please provide the following data:
> 
> - Output of `iptables-save` of both hosts
> - Output of `ip route show table all` of both hosts
> - Output of `ip address` of both hosts
> 
> Kind regards
> 
> Noel
> 
> On 22.09.2017 07 :17, Sandesh Sawant wrote:
> > I have referred to following links and configured strongSwan to 
> establish a route-based VPN tunnel between 2 Linux 4.4.57 boxes.
> > https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN 
>  
>  >
> > https://wiki.strongswan.org/projects/strongswan/wiki/ReducedPrivileges 
>  
>  >
> >
> > The data path used to work perfectly fine when both sides are using 
> strongSwan v5.5.1. After upgrading same setup to v5.5.2, tunnel gets 
> established but ping between the VTI interfaces doesn't work. If we ping from 
> host running v5.5.2, no ESP packet is sent out. If we ping form host running 
> v5.5.1 to host running v5.5.2, ESP packet goes out, but host running v5.5.2 
> doesn't send ESP in response.
> >
> > My ipsec.conf file is as follows (install_route=no is added in 
> strongswan.conf):
> > conn 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0
> >         left=10.160.229.241
> >         leftid=10.160.229.241
> >         rightid=10.160.229.240
> >         leftsubnet=0.0.0.0/0  
> >         right=10.160.229.240
> >         rightsubnet=0.0.0.0/0  
> >         authby=secret
> >         keyexchange = ikev2
> >         mark = 1
> >         auto = start
> >         esp=aes128-sha1-modp2048
> >         ike=aes128-sha1-modp2048!
> >
> > Tunnel establishment works fine, there is nothing suspicious in logs, 
> and the output of 'ipsec statusall' is as follows:
> >
> > Status of IKE charon daemon (strongSwan 5.5.2, Linux 4.4.57, x86_64):
> >   uptime: 18 days, since Aug 18 10:58:17 2017
> >   malloc: sbrk 1477008, mmap 0, used 357360, free 1119648
> >   worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, 
> scheduled: 6
> >   loaded plugins: charon aes des rc2 sha2 sha1 md5 random nonce x509 
> revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem 
> openssl fips-prf xcbc cmac hmac attr kernel-netlink resolve socket-default 
> stroke vici updown xauth-generic
> > Listening IP addresses:
> >   10.160.229.241
> > Connections:
> > 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0:  
> 10.160.229.241...10.160.229.240  IKEv2, dpddelay=30s
> > 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0:   local:  
> [10.160.229.241] uses pre-shared key authentication
> > 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0:   remote: 
> [10.160.229.240] uses pre-shared key authentication
> > 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0:   child:  0.0.0.0/0 
>   === 0.0.0.0/0  
>  TUNNEL, dpdaction=restart
> > Routed Connections:
> > 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0{253}:  ROUTED, 
> TUNNEL, reqid 6
> > 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0{253}:   0.0.0.0/0 
> 

Re: [strongSwan] Timeout on poor connection

[Noel Kuntze]

You do not need to explicitely accept frag-needed. It is included in ctstate 
RELATED.

dpddelay sets the interval between dpd packets, not when dpdaction is taken.
dpdtimeout controls when the action is taken.

The firewall rules you mentioned are needed anyway and do not deserve the term 
optimization. Not using them commonly breaks scenarios,
and they are vital to having working tunnels.

strongSwan is specifically optimized for multi core CPUs. You probably have 
problems because the CPU scheduler moves the threads around a lot.
You can try working around that by tuning it(, upgrading your kernel hoping 
that it fixes that) or by changing the code to pin the threads to certain CPUs.

I hope you optimized the strongSwan settings to make efficient use of 
parallelism by using hashtables[1].

[1] https://wiki.strongswan.org/projects/strongswan/wiki/IkeSaTable

On 04.10.2017 08:55, Anvar Kuchkartaev wrote:
> TCPMSS parameters in firewall are required proper routing of tcp connections 
> of client within the ipsec tunnel but:
>  iptables -A INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT 
>
> Rule can help to udp connections when mtu changes. The Same thing happened on 
> me when connection from clients ISP being throttled and dropped silently. Use:
>
> dpddelay=300s ‎
> ‎dpdaction=clear
>
> On server side (this will check dead peers and remove them in every 300 
> seconds in your case if client disappears maximum after 300s he/she can 
> connect, you might decrease 300s to find optimal time)
>
> And use:
>
> dpddelay=5s
> dpdaction=restart
>
> On client side (if connection dropped client will check in each 5s and 
> restart connection automatically if it drops)
> In this case server will drop connections if they completely disconnected 
> within the 300s maximum and client will restart the connection in 5s if 
> temporary failure occured due to packet loss.
>
> Also adding mobike=yes into ipsec.conf connections and changing reuse_ikesa 
> to yes in strongswan.d/charon.conf will help connection remain active even if 
> ip changes or temporary disruptions (if client uses mobile 3G connection with 
> high latency and low bandwith).
>
> Anvar Kuchkartaev 
> an...@anvartay.com 
>   Original Message  
> From: Stephen Scheck
> Sent: martes, 3 de octubre de 2017 09:18 p.m.
> To: Anvar Kuchkartaev
> Cc: Jamie Stuart; users@lists.strongswan.org
> Subject: Re: [strongSwan] Timeout on poor connection
>
>
> Thanks for the configs.
>
> I added the dpd* parameters to my configurations. My situation is a little 
> different in that my traffic is primarily UDP, so the TCP MSS settings are 
> not needed. I also need to use IKEv1. Furthermore, I’m running a scale test 
> in which there’s low latency and plenty of bandwidth, which may nonetheless 
> be saturated by the number of simultaneous connections which are being 
> attempted.
>
> Unfortunately, the dpd* parameters did not help. I still notice a small 
> number (25-50) connections out of several thousand which fail to establish, 
> and stay that way until the StrongSwans are restarted.
>
> Does anybody know of any further parameters which may influence connection 
> attempts and retries?
>
> One thing that I’ve noted is that if I run both the client and server 
> StrongSwan processes on single core machines, or with the StrongSwan threads 
> pinned to a single CPU, the success rate is *decidedly better* than with 
> multiple cores available (although, occasionally, even then a couple of them 
> fail to establish and stay “stuck”).
>
> I’m beginning to think there may be some troublesome concurrency bugs in the 
> StrongSwan IKEv1 routines.
>
> Any help appreciated!
>
>
>
>> On Sep 30, 2017, at 7:14 PM, Anvar Kuchkartaev  wrote:
>>
>> ipsec.conf
>>
>> keyexchange=ikev2
>> type=tunnel
>> dpdaction=clear
>> dpddelay=300s
>> rekey=yes
>> left=%any
>> right=%any
>> fragmentation=yes
>> compress=yes
>>
>> parameters from server side and:
>>
>> dpdtimeout=20s
>> dpddelay=5s
>> dpdaction=restart
>>
>> from client side I think most important.
>>
>> Also you have to do several server optimizations like:
>>
>>
>> firewall:
>>
>> iptables -A INPUT -p esp -j ACCEPT
>>
>> iptables -A INPUT -p udp -m multiport --dport 500,4500 -j ACCEPT
>>
>> iptables -A INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
>>
>> iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS 
>> --clamp-mss-to-pmtu
>>
>> sysctl.conf
>>
>> net.ipv4.ip_forward_use_pmtu=1 (I assume you have done rest of the sysctl 
>> configurations like ip_forward, etc.)
>>
>>
>>
>> On 30/09/17 19:37, Jamie Stuart wrote:
>>> Could you post your (redacted) strongswan config Anvar?
>>>
 On 30 Sep 2017, at 00:59, Anvar Kuchkartaev  wrote:

 I also have some clients connecting from central Asia where internet is 
 very poor and restricted. The main optimizations must be done at the 
 server os and firewall not in strongswan. In strongswan try to 
 

Re: [strongSwan] Timeout on poor connection

[Anvar Kuchkartaev]

TCPMSS parameters in firewall are required proper routing of tcp connections of 
client within the ipsec tunnel but:
 iptables -A INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT 

Rule can help to udp connections when mtu changes. The Same thing happened on 
me when connection from clients ISP being throttled and dropped silently. Use:

dpddelay=300s ‎
‎dpdaction=clear

On server side (this will check dead peers and remove them in every 300 seconds 
in your case if client disappears maximum after 300s he/she can connect, you 
might decrease 300s to find optimal time)

And use:

dpddelay=5s
dpdaction=restart

On client side (if connection dropped client will check in each 5s and restart 
connection automatically if it drops)
In this case server will drop connections if they completely disconnected 
within the 300s maximum and client will restart the connection in 5s if 
temporary failure occured due to packet loss.

Also adding mobike=yes into ipsec.conf connections and changing reuse_ikesa to 
yes in strongswan.d/charon.conf will help connection remain active even if ip 
changes or temporary disruptions (if client uses mobile 3G connection with high 
latency and low bandwith).

Anvar Kuchkartaev 
an...@anvartay.com 
  Original Message  
From: Stephen Scheck
Sent: martes, 3 de octubre de 2017 09:18 p.m.
To: Anvar Kuchkartaev
Cc: Jamie Stuart; users@lists.strongswan.org
Subject: Re: [strongSwan] Timeout on poor connection


Thanks for the configs.

I added the dpd* parameters to my configurations. My situation is a little 
different in that my traffic is primarily UDP, so the TCP MSS settings are not 
needed. I also need to use IKEv1. Furthermore, I’m running a scale test in 
which there’s low latency and plenty of bandwidth, which may nonetheless be 
saturated by the number of simultaneous connections which are being attempted.

Unfortunately, the dpd* parameters did not help. I still notice a small number 
(25-50) connections out of several thousand which fail to establish, and stay 
that way until the StrongSwans are restarted.

Does anybody know of any further parameters which may influence connection 
attempts and retries?

One thing that I’ve noted is that if I run both the client and server 
StrongSwan processes on single core machines, or with the StrongSwan threads 
pinned to a single CPU, the success rate is *decidedly better* than with 
multiple cores available (although, occasionally, even then a couple of them 
fail to establish and stay “stuck”).

I’m beginning to think there may be some troublesome concurrency bugs in the 
StrongSwan IKEv1 routines.

Any help appreciated!



> On Sep 30, 2017, at 7:14 PM, Anvar Kuchkartaev  wrote:
> 
> ipsec.conf
> 
> keyexchange=ikev2
> type=tunnel
> dpdaction=clear
> dpddelay=300s
> rekey=yes
> left=%any
> right=%any
> fragmentation=yes
> compress=yes
> 
> parameters from server side and:
> 
> dpdtimeout=20s
> dpddelay=5s
> dpdaction=restart
> 
> from client side I think most important.
> 
> Also you have to do several server optimizations like:
> 
> 
> firewall:
> 
> iptables -A INPUT -p esp -j ACCEPT
> 
> iptables -A INPUT -p udp -m multiport --dport 500,4500 -j ACCEPT
> 
> iptables -A INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
> 
> iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS 
> --clamp-mss-to-pmtu
> 
> sysctl.conf
> 
> net.ipv4.ip_forward_use_pmtu=1 (I assume you have done rest of the sysctl 
> configurations like ip_forward, etc.)
> 
> 
> 
> On 30/09/17 19:37, Jamie Stuart wrote:
>> Could you post your (redacted) strongswan config Anvar?
>> 
>>> On 30 Sep 2017, at 00:59, Anvar Kuchkartaev  wrote:
>>> 
>>> I also have some clients connecting from central Asia where internet is 
>>> very poor and restricted. The main optimizations must be done at the server 
>>> os and firewall not in strongswan. In strongswan try to authenticate server 
>>> with 2048 bit certificate or higher and watch out IKE ciphers, 
>>> dos_protection, ikesa_table_size, ikesa_table_segments, 
>>> ikesa_hashtable_size parameters. Allow only IKEv2 if possible and decrease 
>>> dpd requests and set dpdaction=restart to restart connection automatically 
>>> if tunnel fails. From operating system watch out mtu changes because in my 
>>> case I had a lot of mtu decreases within the provider network in the region 
>>> client located. Allow icmp fragmentation needed requests from firewall and 
>>> make tcpmss optimizations. It is also recommended to install proxy server 
>>> behind VPN server which only possible to connect within the VPN tunnel (so 
>>> client could configure it's browser to proxy server to enhance connection 
>>> stability).
>>> 
>>> Anvar Kuchkartaev
>>> an...@anvartay.com
>>> Original Message
>>> From: Jamie Stuart
>>> Sent: viernes, 29 de septiembre de 2017 05:59 p.m.
>>> To: users@lists.strongswan.org
>>> Subject: [strongSwan] Timeout on poor connection
>>> 
>>> 
>>> Hi,
>>> 
>>> We have