[strongSwan] From OpenSWAN PubKey to StrongSWAN - Other side is Checkpoiint FW1

2017-08-04 Thread Luca Arzeni 
Hi,
I'm on a debian jessie 8.0, openswan 2.6.37 and I need to migrate to
StrongSWAN 5.2.1
I'm a client (roadwarrior), the other side is a Checkpoint FW1 NG

This configuration IS WORKING FINE under openswan (i.e.: I can connect and
work without any trouble):
==
version 2.0 # conforms to second version of ipsec.conf specification

config setup
dumpdir=/var/run/pluto/
nat_traversal=yes
virtual_private=%v4:
10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:25.0.0.0/8,%v6:fd00::/8,%v6:fe80::/10
oe=off
protostack=netkey # I set this to avoid warning message at connection
startup
keep_alive=20
force_keepalive=yes

conn roadwarrior
left=%defaultroute
leftcert=my_cert.pem
leftrsasigkey=%cert
leftid=%fromcert
#
leftsourceip=A.B.C.D # CP-known client IP (not necessarily my ip), I need
to set it because I'm using also a "rightsubnets" list
leftsubnet=A.B.C.D/32 # CP-known client IP(not necessarily my ip), I need
to set it because I'm using also a "rightsubnets" list
#
right=X.Y.Z.W (FW1_IP_ADDESS)
rightid=X.Y.Z.W (I cannot use FW cert or other values, I MUST use
the firewall public IP)
rightsubnets={ 192.168.1.0/24 192.168.2.0/24 ecc... }
rightcert=firewall_cert.pem
rightrsasigkey=%cert
#
#
auto=start

# after establishing the vpn, run these script to allow routes from my
client to server behind the firevall
#
# /sbin/iptables -t nat -I POSTROUTING -d 192.168.1.0/24 -j SNAT --to my_ip
# /sbin/iptables -t nat -I POSTROUTING -d 192.168.2.0/24 -j SNAT --to my_ip

==

Now I'm trying to use StrongSWAN to setup a connection, but I'm not able to
connect.
This is my StrongSWAN ipsec.conf:

==

# ipsec.conf - strongSwan IPsec configuration file

config setup
# strictcrlpolicy=yes
# uniqueids = no
charondebug =  dmn 2, mgr 2, ike 2, chd 2, job 0, cfg 2, knl 2, net 2, asn
0, enc 0, lib 0, esp 2, tls 2, tnc 2, imc 2, imv 2, pts 2

conn home
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyingtries=1
keyexchange=ikev1
#
left=%any
leftcert=my_cert.pem
leftrsasigkey=%cert
leftid="my certificate subject"
#leftauth=pubkey
leftfirewall=yes
#
leftsourceip=A.B.C.D # CP-known client IP (not necessarily my ip), I need
to set it because I'm using also a "rightsubnets" list
leftsubnet=A.B.C.D/32 # CP-known client IP(not necessarily my ip), I need
to set it because I'm using also a "rightsubnets" list
#
rightcert=fwncest_2012-11-07_cert.pem
rightrsasigkey=%cert
right=X.Y.Z.W (FW1_IP_ADDESS)
rightid=X.Y.Z.W (I cannot use FW cert or other values, I MUST use
the firewall public IP)
rightsubnet= 192.168.1.0/24, 192.168.2.0/24, ecc...
rightcert=firewall_cert.pem
rightrsasigkey=%cert
#
auto=start
# after establishing the vpn, run these script to allow routes from
my client to server behind the firevall
#
# /sbin/iptables -t nat -I POSTROUTING -d 192.168.1.0/24 -j SNAT
--to my_ip
# /sbin/iptables -t nat -I POSTROUTING -d 192.168.2.0/24 -j SNAT
--to my_ip

include /var/lib/strongswan/ipsec.conf.inc

===

But this setup is not working.
Can someone help me?

Thanks, larzeni

Re: [strongSwan] SHA1 vs SHA256

2017-08-04 Thread Dusan Ilic 

No, not according to loaded plugins in ipsec statusall


Den 2017-08-04 kl. 21:44, skrev Noel Kuntze:

Okay. Is kernel-pfkey loaded?

On 04.08.2017 21:31, Dusan Ilic wrote:

Yep, both endpoints have loaded kernel-netlink.
However, the Strongswan versions is 5.2.2 and the other is 5.5.2.


Den 2017-08-04 kl. 21:15, skrev Noel Kuntze:

Hi Dusan,

That is unreliable.
Check the list of loaded plugins in the output of `ipsec stausall` or `swanctl 
--status`.

Kind regards

Noel

On 04.08.2017 21:11, Dusan Ilic wrote:

Hi Noel,

I think I'm already using kernel-netlink on both endpoints.

cat /etc/strongswan.d/charon/kernel-netlink.conf | grep load
  # Whether to load the plugin. Can also be an integer to increase the
  load = yes


Den 2017-08-04 kl. 21:00, skrev Noel Kuntze:

Hi,

If the pfkey API (nowadays a wrapper around XFRM) to the kernel is used, 
SHA-256 with 96 bit truncation is used[1][2]. That is because it is the default 
truncation length.
It is not possible to choose the truncation length using pfkey.
If XFRM over netlink socket is used to configure XFRM, one can choose the 
truncation length. strongSwan uses the 128 bit truncation length for 
HMAC-SHa256.

Since 5.5.3, one can choose the truncation length on a per-conn basis.
   From the roadmap[3]:

With the sha256_96 compatibility option it's possible to locally configure 
96-bit truncation
for HMAC_SHA256 (the correct truncation is 128 bit) when negotiated using the 
official
algorithm identifier (12). This is only useful for compatibility with peers 
that incorrectly
use this shorter truncation as the actual truncation length is not negotiated.

So the solution is to try using kernel-netlink instead of kernel-pfkey with 
strongSwan in an attempt to force the kernel to
use the 128 bit truncation length, which strongSwan chooses by default.

Kind regards

Noel

[1] https://wiki.strongswan.org/issues/2301
[2] https://wiki.strongswan.org/issues/2391
[3] https://wiki.strongswan.org/versions/65
On 04.08.2017 20:50, Andreas Steffen wrote:

Hi Dusan,

the only workaround I see is to either upgrade your Linux 2.6
kernel or fall back to a SHA-1 based ESP HMAC.

Regards

Andreas

On 04.08.2017 20:46, Dusan Ilic wrote:

Hi,

Unfortunately, I'm not following you guys :)
Could someone please clarify?


Den 2017-08-04 kl. 19:04, skrev Noel Kuntze:

Hi,

IIRC pfkey still uses the old truncation (It's mentioned in some
relatively recent ticket).
Try using kernel-netlink instead.

Kind regards

Noel


On 04.08.2017 19:02, Andreas Steffen wrote:

Hi Dusan,

hmmm, our documentation says that the correct ESP SHA256_128 HMAC
truncation was introduced with the 2.6.33 kernel but your kernel
might not be a vanilla 2.6.36 kernel:

 https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites

 (ESP integrity algorithm footnote n)

Regards

Andreas

On 04.08.2017 16:41, Dusan Ilic wrote:

Hi Andreas

One side is 2.6.36 and the other 3.10.20


Den 2017-08-04 kl. 12:48, skrev Andreas Steffen:

Hi Dusan,

this is a Linux kernel issue. Which kernel versions are you running
on the two endpoints?.

Regards

Andreas

On 04.08.2017 12:41, Dusan Ilic wrote:

Hi Noel,

One side is Strongswan 5.2.2 and the other is 5.5.2.
How do I switch?


Den 2017-08-04 kl. 12:25, skrev Noel Kuntze:

the remote peer probably uses the DRAFT variant of sha2-256, which
uses 96 bit truncation. strongSwan uses the actual standardized
variant that truncates to 128 bit.
You can switch between the two in the newest version of strongSwan

On 04.08.2017 12:23, Dusan Ilic wrote:

Hello!

I have a strange issue, with both settings below the tunnel goes up
as it should, but only with SHA1 in ESP traffic goes through.
When I
ping the remote client with ESP SHA256 it times out, even though
the
tunnel reports as being up by Strongswan.

Traffic working:

ike=aes256-sha256-modp2048!
esp=aes128-sha1-modp2048!

Traffic not working:

ike=aes256-sha256-modp2048!
esp=aes256-sha256-modp2048!

Below combo doesn't work either:

ike=aes256-sha256-modp2048!
esp=aes128-sha256-modp2048!


Also, are above settings good? I'm having AES128 on ESP because
with
AES256 I loose too much througput. Do you have any suggestions for
change?

Re: [strongSwan] SHA1 vs SHA256

2017-08-04 Thread Dusan Ilic 

Yep, both endpoints have loaded kernel-netlink.
However, the Strongswan versions is 5.2.2 and the other is 5.5.2.


Den 2017-08-04 kl. 21:15, skrev Noel Kuntze:

Hi Dusan,

That is unreliable.
Check the list of loaded plugins in the output of `ipsec stausall` or `swanctl 
--status`.

Kind regards

Noel

On 04.08.2017 21:11, Dusan Ilic wrote:

Hi Noel,

I think I'm already using kernel-netlink on both endpoints.

cat /etc/strongswan.d/charon/kernel-netlink.conf | grep load
 # Whether to load the plugin. Can also be an integer to increase the
 load = yes


Den 2017-08-04 kl. 21:00, skrev Noel Kuntze:

Hi,

If the pfkey API (nowadays a wrapper around XFRM) to the kernel is used, 
SHA-256 with 96 bit truncation is used[1][2]. That is because it is the default 
truncation length.
It is not possible to choose the truncation length using pfkey.
If XFRM over netlink socket is used to configure XFRM, one can choose the 
truncation length. strongSwan uses the 128 bit truncation length for 
HMAC-SHa256.

Since 5.5.3, one can choose the truncation length on a per-conn basis.
  From the roadmap[3]:

With the sha256_96 compatibility option it's possible to locally configure 
96-bit truncation
for HMAC_SHA256 (the correct truncation is 128 bit) when negotiated using the 
official
algorithm identifier (12). This is only useful for compatibility with peers 
that incorrectly
use this shorter truncation as the actual truncation length is not negotiated.

So the solution is to try using kernel-netlink instead of kernel-pfkey with 
strongSwan in an attempt to force the kernel to
use the 128 bit truncation length, which strongSwan chooses by default.

Kind regards

Noel

[1] https://wiki.strongswan.org/issues/2301
[2] https://wiki.strongswan.org/issues/2391
[3] https://wiki.strongswan.org/versions/65
On 04.08.2017 20:50, Andreas Steffen wrote:

Hi Dusan,

the only workaround I see is to either upgrade your Linux 2.6
kernel or fall back to a SHA-1 based ESP HMAC.

Regards

Andreas

On 04.08.2017 20:46, Dusan Ilic wrote:

Hi,

Unfortunately, I'm not following you guys :)
Could someone please clarify?


Den 2017-08-04 kl. 19:04, skrev Noel Kuntze:

Hi,

IIRC pfkey still uses the old truncation (It's mentioned in some
relatively recent ticket).
Try using kernel-netlink instead.

Kind regards

Noel


On 04.08.2017 19:02, Andreas Steffen wrote:

Hi Dusan,

hmmm, our documentation says that the correct ESP SHA256_128 HMAC
truncation was introduced with the 2.6.33 kernel but your kernel
might not be a vanilla 2.6.36 kernel:

https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites

(ESP integrity algorithm footnote n)

Regards

Andreas

On 04.08.2017 16:41, Dusan Ilic wrote:

Hi Andreas

One side is 2.6.36 and the other 3.10.20


Den 2017-08-04 kl. 12:48, skrev Andreas Steffen:

Hi Dusan,

this is a Linux kernel issue. Which kernel versions are you running
on the two endpoints?.

Regards

Andreas

On 04.08.2017 12:41, Dusan Ilic wrote:

Hi Noel,

One side is Strongswan 5.2.2 and the other is 5.5.2.
How do I switch?


Den 2017-08-04 kl. 12:25, skrev Noel Kuntze:

the remote peer probably uses the DRAFT variant of sha2-256, which
uses 96 bit truncation. strongSwan uses the actual standardized
variant that truncates to 128 bit.
You can switch between the two in the newest version of strongSwan

On 04.08.2017 12:23, Dusan Ilic wrote:

Hello!

I have a strange issue, with both settings below the tunnel goes up
as it should, but only with SHA1 in ESP traffic goes through.
When I
ping the remote client with ESP SHA256 it times out, even though
the
tunnel reports as being up by Strongswan.

Traffic working:

ike=aes256-sha256-modp2048!
esp=aes128-sha1-modp2048!

Traffic not working:

ike=aes256-sha256-modp2048!
esp=aes256-sha256-modp2048!

Below combo doesn't work either:

ike=aes256-sha256-modp2048!
esp=aes128-sha256-modp2048!


Also, are above settings good? I'm having AES128 on ESP because
with
AES256 I loose too much througput. Do you have any suggestions for
change?

Re: [strongSwan] SHA1 vs SHA256

2017-08-04 Thread Dusan Ilic 

Oh, I saw now from version 5.5.3.


Den 2017-08-04 kl. 21:00, skrev Noel Kuntze:

Hi,

If the pfkey API (nowadays a wrapper around XFRM) to the kernel is used, 
SHA-256 with 96 bit truncation is used[1][2]. That is because it is the default 
truncation length.
It is not possible to choose the truncation length using pfkey.
If XFRM over netlink socket is used to configure XFRM, one can choose the 
truncation length. strongSwan uses the 128 bit truncation length for 
HMAC-SHa256.

Since 5.5.3, one can choose the truncation length on a per-conn basis.
 From the roadmap[3]:

With the sha256_96 compatibility option it's possible to locally configure 
96-bit truncation
for HMAC_SHA256 (the correct truncation is 128 bit) when negotiated using the 
official
algorithm identifier (12). This is only useful for compatibility with peers 
that incorrectly
use this shorter truncation as the actual truncation length is not negotiated.

So the solution is to try using kernel-netlink instead of kernel-pfkey with 
strongSwan in an attempt to force the kernel to
use the 128 bit truncation length, which strongSwan chooses by default.

Kind regards

Noel

[1] https://wiki.strongswan.org/issues/2301
[2] https://wiki.strongswan.org/issues/2391
[3] https://wiki.strongswan.org/versions/65
On 04.08.2017 20:50, Andreas Steffen wrote:

Hi Dusan,

the only workaround I see is to either upgrade your Linux 2.6
kernel or fall back to a SHA-1 based ESP HMAC.

Regards

Andreas

On 04.08.2017 20:46, Dusan Ilic wrote:

Hi,

Unfortunately, I'm not following you guys :)
Could someone please clarify?


Den 2017-08-04 kl. 19:04, skrev Noel Kuntze:

Hi,

IIRC pfkey still uses the old truncation (It's mentioned in some
relatively recent ticket).
Try using kernel-netlink instead.

Kind regards

Noel


On 04.08.2017 19:02, Andreas Steffen wrote:

Hi Dusan,

hmmm, our documentation says that the correct ESP SHA256_128 HMAC
truncation was introduced with the 2.6.33 kernel but your kernel
might not be a vanilla 2.6.36 kernel:

   https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites

   (ESP integrity algorithm footnote n)

Regards

Andreas

On 04.08.2017 16:41, Dusan Ilic wrote:

Hi Andreas

One side is 2.6.36 and the other 3.10.20


Den 2017-08-04 kl. 12:48, skrev Andreas Steffen:

Hi Dusan,

this is a Linux kernel issue. Which kernel versions are you running
on the two endpoints?.

Regards

Andreas

On 04.08.2017 12:41, Dusan Ilic wrote:

Hi Noel,

One side is Strongswan 5.2.2 and the other is 5.5.2.
How do I switch?


Den 2017-08-04 kl. 12:25, skrev Noel Kuntze:

the remote peer probably uses the DRAFT variant of sha2-256, which
uses 96 bit truncation. strongSwan uses the actual standardized
variant that truncates to 128 bit.
You can switch between the two in the newest version of strongSwan

On 04.08.2017 12:23, Dusan Ilic wrote:

Hello!

I have a strange issue, with both settings below the tunnel goes up
as it should, but only with SHA1 in ESP traffic goes through.
When I
ping the remote client with ESP SHA256 it times out, even though
the
tunnel reports as being up by Strongswan.

Traffic working:

ike=aes256-sha256-modp2048!
esp=aes128-sha1-modp2048!

Traffic not working:

ike=aes256-sha256-modp2048!
esp=aes256-sha256-modp2048!

Below combo doesn't work either:

ike=aes256-sha256-modp2048!
esp=aes128-sha256-modp2048!


Also, are above settings good? I'm having AES128 on ESP because
with
AES256 I loose too much througput. Do you have any suggestions for
change?

Re: [strongSwan] SHA1 vs SHA256

2017-08-04 Thread Noel Kuntze 
Hi Dusan,

That is unreliable.
Check the list of loaded plugins in the output of `ipsec stausall` or `swanctl 
--status`.

Kind regards

Noel

On 04.08.2017 21:11, Dusan Ilic wrote:
> Hi Noel,
> 
> I think I'm already using kernel-netlink on both endpoints.
> 
> cat /etc/strongswan.d/charon/kernel-netlink.conf | grep load
> # Whether to load the plugin. Can also be an integer to increase the
> load = yes
> 
> 
> Den 2017-08-04 kl. 21:00, skrev Noel Kuntze:
>> Hi,
>>
>> If the pfkey API (nowadays a wrapper around XFRM) to the kernel is used, 
>> SHA-256 with 96 bit truncation is used[1][2]. That is because it is the 
>> default truncation length.
>> It is not possible to choose the truncation length using pfkey.
>> If XFRM over netlink socket is used to configure XFRM, one can choose the 
>> truncation length. strongSwan uses the 128 bit truncation length for 
>> HMAC-SHa256.
>>
>> Since 5.5.3, one can choose the truncation length on a per-conn basis.
>>  From the roadmap[3]:
>>
>> With the sha256_96 compatibility option it's possible to locally configure 
>> 96-bit truncation
>> for HMAC_SHA256 (the correct truncation is 128 bit) when negotiated using 
>> the official
>> algorithm identifier (12). This is only useful for compatibility with peers 
>> that incorrectly
>> use this shorter truncation as the actual truncation length is not 
>> negotiated.
>>
>> So the solution is to try using kernel-netlink instead of kernel-pfkey with 
>> strongSwan in an attempt to force the kernel to
>> use the 128 bit truncation length, which strongSwan chooses by default.
>>
>> Kind regards
>>
>> Noel
>>
>> [1] https://wiki.strongswan.org/issues/2301
>> [2] https://wiki.strongswan.org/issues/2391
>> [3] https://wiki.strongswan.org/versions/65
>> On 04.08.2017 20:50, Andreas Steffen wrote:
>>> Hi Dusan,
>>>
>>> the only workaround I see is to either upgrade your Linux 2.6
>>> kernel or fall back to a SHA-1 based ESP HMAC.
>>>
>>> Regards
>>>
>>> Andreas
>>>
>>> On 04.08.2017 20:46, Dusan Ilic wrote:
 Hi,

 Unfortunately, I'm not following you guys :)
 Could someone please clarify?


 Den 2017-08-04 kl. 19:04, skrev Noel Kuntze:
> Hi,
>
> IIRC pfkey still uses the old truncation (It's mentioned in some
> relatively recent ticket).
> Try using kernel-netlink instead.
>
> Kind regards
>
> Noel
>
>
> On 04.08.2017 19:02, Andreas Steffen wrote:
>> Hi Dusan,
>>
>> hmmm, our documentation says that the correct ESP SHA256_128 HMAC
>> truncation was introduced with the 2.6.33 kernel but your kernel
>> might not be a vanilla 2.6.36 kernel:
>>
>>https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites
>>
>>(ESP integrity algorithm footnote n)
>>
>> Regards
>>
>> Andreas
>>
>> On 04.08.2017 16:41, Dusan Ilic wrote:
>>> Hi Andreas
>>>
>>> One side is 2.6.36 and the other 3.10.20
>>>
>>>
>>> Den 2017-08-04 kl. 12:48, skrev Andreas Steffen:
 Hi Dusan,

 this is a Linux kernel issue. Which kernel versions are you running
 on the two endpoints?.

 Regards

 Andreas

 On 04.08.2017 12:41, Dusan Ilic wrote:
> Hi Noel,
>
> One side is Strongswan 5.2.2 and the other is 5.5.2.
> How do I switch?
>
>
> Den 2017-08-04 kl. 12:25, skrev Noel Kuntze:
>> the remote peer probably uses the DRAFT variant of sha2-256, which
>> uses 96 bit truncation. strongSwan uses the actual standardized
>> variant that truncates to 128 bit.
>> You can switch between the two in the newest version of strongSwan
>>
>> On 04.08.2017 12:23, Dusan Ilic wrote:
>>> Hello!
>>>
>>> I have a strange issue, with both settings below the tunnel goes up
>>> as it should, but only with SHA1 in ESP traffic goes through.
>>> When I
>>> ping the remote client with ESP SHA256 it times out, even though
>>> the
>>> tunnel reports as being up by Strongswan.
>>>
>>> Traffic working:
>>>
>>> ike=aes256-sha256-modp2048!
>>> esp=aes128-sha1-modp2048!
>>>
>>> Traffic not working:
>>>
>>> ike=aes256-sha256-modp2048!
>>> esp=aes256-sha256-modp2048!
>>>
>>> Below combo doesn't work either:
>>>
>>> ike=aes256-sha256-modp2048!
>>> esp=aes128-sha256-modp2048!
>>>
>>>
>>> Also, are above settings good? I'm having AES128 on ESP because
>>> with
>>> AES256 I loose too much througput. Do you have any suggestions for
>>> change?
>>>
>>>
> 



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] SHA1 vs SHA256

2017-08-04 Thread Noel Kuntze 
Hi,

If the pfkey API (nowadays a wrapper around XFRM) to the kernel is used, 
SHA-256 with 96 bit truncation is used[1][2]. That is because it is the default 
truncation length.
It is not possible to choose the truncation length using pfkey.
If XFRM over netlink socket is used to configure XFRM, one can choose the 
truncation length. strongSwan uses the 128 bit truncation length for 
HMAC-SHa256.

Since 5.5.3, one can choose the truncation length on a per-conn basis.
From the roadmap[3]:

With the sha256_96 compatibility option it's possible to locally configure 
96-bit truncation
for HMAC_SHA256 (the correct truncation is 128 bit) when negotiated using the 
official
algorithm identifier (12). This is only useful for compatibility with peers 
that incorrectly
use this shorter truncation as the actual truncation length is not negotiated.

So the solution is to try using kernel-netlink instead of kernel-pfkey with 
strongSwan in an attempt to force the kernel to
use the 128 bit truncation length, which strongSwan chooses by default.

Kind regards

Noel

[1] https://wiki.strongswan.org/issues/2301
[2] https://wiki.strongswan.org/issues/2391
[3] https://wiki.strongswan.org/versions/65
On 04.08.2017 20:50, Andreas Steffen wrote:
> Hi Dusan,
> 
> the only workaround I see is to either upgrade your Linux 2.6
> kernel or fall back to a SHA-1 based ESP HMAC.
> 
> Regards
> 
> Andreas
> 
> On 04.08.2017 20:46, Dusan Ilic wrote:
>> Hi,
>>
>> Unfortunately, I'm not following you guys :)
>> Could someone please clarify?
>>
>>
>> Den 2017-08-04 kl. 19:04, skrev Noel Kuntze:
>>> Hi,
>>>
>>> IIRC pfkey still uses the old truncation (It's mentioned in some
>>> relatively recent ticket).
>>> Try using kernel-netlink instead.
>>>
>>> Kind regards
>>>
>>> Noel
>>>
>>>
>>> On 04.08.2017 19:02, Andreas Steffen wrote:
 Hi Dusan,

 hmmm, our documentation says that the correct ESP SHA256_128 HMAC
 truncation was introduced with the 2.6.33 kernel but your kernel
 might not be a vanilla 2.6.36 kernel:

   https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites

   (ESP integrity algorithm footnote n)

 Regards

 Andreas

 On 04.08.2017 16:41, Dusan Ilic wrote:
> Hi Andreas
>
> One side is 2.6.36 and the other 3.10.20
>
>
> Den 2017-08-04 kl. 12:48, skrev Andreas Steffen:
>> Hi Dusan,
>>
>> this is a Linux kernel issue. Which kernel versions are you running
>> on the two endpoints?.
>>
>> Regards
>>
>> Andreas
>>
>> On 04.08.2017 12:41, Dusan Ilic wrote:
>>> Hi Noel,
>>>
>>> One side is Strongswan 5.2.2 and the other is 5.5.2.
>>> How do I switch?
>>>
>>>
>>> Den 2017-08-04 kl. 12:25, skrev Noel Kuntze:
 the remote peer probably uses the DRAFT variant of sha2-256, which
 uses 96 bit truncation. strongSwan uses the actual standardized
 variant that truncates to 128 bit.
 You can switch between the two in the newest version of strongSwan

 On 04.08.2017 12:23, Dusan Ilic wrote:
> Hello!
>
> I have a strange issue, with both settings below the tunnel goes up
> as it should, but only with SHA1 in ESP traffic goes through.
> When I
> ping the remote client with ESP SHA256 it times out, even though
> the
> tunnel reports as being up by Strongswan.
>
> Traffic working:
>
> ike=aes256-sha256-modp2048!
> esp=aes128-sha1-modp2048!
>
> Traffic not working:
>
> ike=aes256-sha256-modp2048!
> esp=aes256-sha256-modp2048!
>
> Below combo doesn't work either:
>
> ike=aes256-sha256-modp2048!
> esp=aes128-sha256-modp2048!
>
>
> Also, are above settings good? I'm having AES128 on ESP because
> with
> AES256 I loose too much througput. Do you have any suggestions for
> change?
>
>
>>
> 



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] Data transfer stops

2017-08-04 Thread Yu. E. Gutnikov 


Hi, Tobias.I've used lifetimes from my first mail. I'll try to reproduce 
situation with normal lifetimes.
Sincerely,Yuri Gutnikov


Отправлено с устройства Samsung

 Исходное сообщение 
От: Tobias Brunner  
Дата: 04.08.2017  18:31  (GMT+03:00) 
Кому: "Yuri Е. Gutnikov" , users@lists.strongswan.org 
Тема: Re: [strongSwan] Data transfer stops 

Hi Yuri,

> I changed logging settings as you suggested. Full logs are in attachments.

Thanks.  What lifetimes did you configure now?  It seems the CHILD_SAs
are rekeyed immediately after they got established (i.e. the settings
you mentioned in your first email can't be in use here).

Anyway, I think I see what the problem is.  With the new rekeying code
the old inbound IPsec SA will remain in the kernel for a few seconds in
order to process delayed packets (the default is 5 seconds, which can be
configured via charon.delete_rekeyed_delay).  During that time the
CHILD_SA object remains in state CHILD_DELETING.  However, CHILD_SAs in
that state will prevent the IKE_SA from getting reauthenticated ("unable
to reauthenticate in CHILD_SA DELETING state, delaying for Xs" is
logged).  Because with your rekey lifetimes there is always a CHILD_SA
in state CHILD_DELETING (actually multiple, as they are rekeyed
immediately after establishing) the IKE_SA is never replaced until it
finally is destroyed due to the hard lifetime.  I'd say with normal
rekey timings this shouldn't be a problem (i.e. when there is enough
time to retry the reauthentication before the IKE_SA is terminated if
such a collision should occur).  It's also no issue if you use IKE
rekeying (reauth=no) as CHILD_SAs are then migrated.

Regards,
Tobias

Re: [strongSwan] SHA1 vs SHA256

2017-08-04 Thread Noel Kuntze 
Hi,

IIRC pfkey still uses the old truncation (It's mentioned in some relatively 
recent ticket).
Try using kernel-netlink instead.

Kind regards

Noel


On 04.08.2017 19:02, Andreas Steffen wrote:
> Hi Dusan,
> 
> hmmm, our documentation says that the correct ESP SHA256_128 HMAC
> truncation was introduced with the 2.6.33 kernel but your kernel
> might not be a vanilla 2.6.36 kernel:
> 
>  https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites
> 
>  (ESP integrity algorithm footnote n)
> 
> Regards
> 
> Andreas
> 
> On 04.08.2017 16:41, Dusan Ilic wrote:
>> Hi Andreas
>>
>> One side is 2.6.36 and the other 3.10.20
>>
>>
>> Den 2017-08-04 kl. 12:48, skrev Andreas Steffen:
>>> Hi Dusan,
>>>
>>> this is a Linux kernel issue. Which kernel versions are you running
>>> on the two endpoints?.
>>>
>>> Regards
>>>
>>> Andreas
>>>
>>> On 04.08.2017 12:41, Dusan Ilic wrote:
 Hi Noel,

 One side is Strongswan 5.2.2 and the other is 5.5.2.
 How do I switch?


 Den 2017-08-04 kl. 12:25, skrev Noel Kuntze:
> the remote peer probably uses the DRAFT variant of sha2-256, which
> uses 96 bit truncation. strongSwan uses the actual standardized
> variant that truncates to 128 bit.
> You can switch between the two in the newest version of strongSwan
>
> On 04.08.2017 12:23, Dusan Ilic wrote:
>> Hello!
>>
>> I have a strange issue, with both settings below the tunnel goes up
>> as it should, but only with SHA1 in ESP traffic goes through. When I
>> ping the remote client with ESP SHA256 it times out, even though the
>> tunnel reports as being up by Strongswan.
>>
>> Traffic working:
>>
>> ike=aes256-sha256-modp2048!
>> esp=aes128-sha1-modp2048!
>>
>> Traffic not working:
>>
>> ike=aes256-sha256-modp2048!
>> esp=aes256-sha256-modp2048!
>>
>> Below combo doesn't work either:
>>
>> ike=aes256-sha256-modp2048!
>> esp=aes128-sha256-modp2048!
>>
>>
>> Also, are above settings good? I'm having AES128 on ESP because with
>> AES256 I loose too much througput. Do you have any suggestions for
>> change?
>>
>>
>>
> 



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] SHA1 vs SHA256

2017-08-04 Thread Andreas Steffen 
Hi Dusan,

hmmm, our documentation says that the correct ESP SHA256_128 HMAC
truncation was introduced with the 2.6.33 kernel but your kernel
might not be a vanilla 2.6.36 kernel:

 https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites

 (ESP integrity algorithm footnote n)

Regards

Andreas

On 04.08.2017 16:41, Dusan Ilic wrote:
> Hi Andreas
> 
> One side is 2.6.36 and the other 3.10.20
> 
> 
> Den 2017-08-04 kl. 12:48, skrev Andreas Steffen:
>> Hi Dusan,
>>
>> this is a Linux kernel issue. Which kernel versions are you running
>> on the two endpoints?.
>>
>> Regards
>>
>> Andreas
>>
>> On 04.08.2017 12:41, Dusan Ilic wrote:
>>> Hi Noel,
>>>
>>> One side is Strongswan 5.2.2 and the other is 5.5.2.
>>> How do I switch?
>>>
>>>
>>> Den 2017-08-04 kl. 12:25, skrev Noel Kuntze:
 the remote peer probably uses the DRAFT variant of sha2-256, which
 uses 96 bit truncation. strongSwan uses the actual standardized
 variant that truncates to 128 bit.
 You can switch between the two in the newest version of strongSwan

 On 04.08.2017 12:23, Dusan Ilic wrote:
> Hello!
>
> I have a strange issue, with both settings below the tunnel goes up
> as it should, but only with SHA1 in ESP traffic goes through. When I
> ping the remote client with ESP SHA256 it times out, even though the
> tunnel reports as being up by Strongswan.
>
> Traffic working:
>
> ike=aes256-sha256-modp2048!
> esp=aes128-sha1-modp2048!
>
> Traffic not working:
>
> ike=aes256-sha256-modp2048!
> esp=aes256-sha256-modp2048!
>
> Below combo doesn't work either:
>
> ike=aes256-sha256-modp2048!
> esp=aes128-sha256-modp2048!
>
>
> Also, are above settings good? I'm having AES128 on ESP because with
> AES256 I loose too much througput. Do you have any suggestions for
> change?
>
>
> 

-- 
==
Andreas Steffen andreas.stef...@strongswan.org
strongSwan - the Open Source VPN Solution!  www.strongswan.org
Institute for Networked Solutions
HSR University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===[INS-HSR]==



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [strongSwan] Data transfer stops

2017-08-04 Thread Tobias Brunner 
Hi Yuri,

> I changed logging settings as you suggested. Full logs are in attachments.

Thanks.  What lifetimes did you configure now?  It seems the CHILD_SAs
are rekeyed immediately after they got established (i.e. the settings
you mentioned in your first email can't be in use here).

Anyway, I think I see what the problem is.  With the new rekeying code
the old inbound IPsec SA will remain in the kernel for a few seconds in
order to process delayed packets (the default is 5 seconds, which can be
configured via charon.delete_rekeyed_delay).  During that time the
CHILD_SA object remains in state CHILD_DELETING.  However, CHILD_SAs in
that state will prevent the IKE_SA from getting reauthenticated ("unable
to reauthenticate in CHILD_SA DELETING state, delaying for Xs" is
logged).  Because with your rekey lifetimes there is always a CHILD_SA
in state CHILD_DELETING (actually multiple, as they are rekeyed
immediately after establishing) the IKE_SA is never replaced until it
finally is destroyed due to the hard lifetime.  I'd say with normal
rekey timings this shouldn't be a problem (i.e. when there is enough
time to retry the reauthentication before the IKE_SA is terminated if
such a collision should occur).  It's also no issue if you use IKE
rekeying (reauth=no) as CHILD_SAs are then migrated.

Regards,
Tobias

Re: [strongSwan] SHA1 vs SHA256

2017-08-04 Thread Dusan Ilic 

Hi Andreas

One side is 2.6.36 and the other 3.10.20


Den 2017-08-04 kl. 12:48, skrev Andreas Steffen:

Hi Dusan,

this is a Linux kernel issue. Which kernel versions are you running
on the two endpoints?.

Regards

Andreas

On 04.08.2017 12:41, Dusan Ilic wrote:

Hi Noel,

One side is Strongswan 5.2.2 and the other is 5.5.2.
How do I switch?


Den 2017-08-04 kl. 12:25, skrev Noel Kuntze:

the remote peer probably uses the DRAFT variant of sha2-256, which
uses 96 bit truncation. strongSwan uses the actual standardized
variant that truncates to 128 bit.
You can switch between the two in the newest version of strongSwan

On 04.08.2017 12:23, Dusan Ilic wrote:

Hello!

I have a strange issue, with both settings below the tunnel goes up
as it should, but only with SHA1 in ESP traffic goes through. When I
ping the remote client with ESP SHA256 it times out, even though the
tunnel reports as being up by Strongswan.

Traffic working:

ike=aes256-sha256-modp2048!
esp=aes128-sha1-modp2048!

Traffic not working:

ike=aes256-sha256-modp2048!
esp=aes256-sha256-modp2048!

Below combo doesn't work either:

ike=aes256-sha256-modp2048!
esp=aes128-sha256-modp2048!


Also, are above settings good? I'm having AES128 on ESP because with
AES256 I loose too much througput. Do you have any suggestions for
change?

Re: [strongSwan] SHA1 vs SHA256

2017-08-04 Thread Andreas Steffen 
Hi Dusan,

this is a Linux kernel issue. Which kernel versions are you running
on the two endpoints?.

Regards

Andreas

On 04.08.2017 12:41, Dusan Ilic wrote:
> Hi Noel,
> 
> One side is Strongswan 5.2.2 and the other is 5.5.2.
> How do I switch?
> 
> 
> Den 2017-08-04 kl. 12:25, skrev Noel Kuntze:
>> the remote peer probably uses the DRAFT variant of sha2-256, which
>> uses 96 bit truncation. strongSwan uses the actual standardized
>> variant that truncates to 128 bit.
>> You can switch between the two in the newest version of strongSwan
>>
>> On 04.08.2017 12:23, Dusan Ilic wrote:
>>> Hello!
>>>
>>> I have a strange issue, with both settings below the tunnel goes up
>>> as it should, but only with SHA1 in ESP traffic goes through. When I
>>> ping the remote client with ESP SHA256 it times out, even though the
>>> tunnel reports as being up by Strongswan.
>>>
>>> Traffic working:
>>>
>>> ike=aes256-sha256-modp2048!
>>> esp=aes128-sha1-modp2048!
>>>
>>> Traffic not working:
>>>
>>> ike=aes256-sha256-modp2048!
>>> esp=aes256-sha256-modp2048!
>>>
>>> Below combo doesn't work either:
>>>
>>> ike=aes256-sha256-modp2048!
>>> esp=aes128-sha256-modp2048!
>>>
>>>
>>> Also, are above settings good? I'm having AES128 on ESP because with
>>> AES256 I loose too much througput. Do you have any suggestions for
>>> change?
>>>
>>>
> 

-- 
==
Andreas Steffen andreas.stef...@strongswan.org
strongSwan - the Open Source VPN Solution!  www.strongswan.org
Institute for Networked Solutions
HSR University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===[INS-HSR]==



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [strongSwan] SHA1 vs SHA256

2017-08-04 Thread Dusan Ilic 

Hi Noel,

One side is Strongswan 5.2.2 and the other is 5.5.2.
How do I switch?


Den 2017-08-04 kl. 12:25, skrev Noel Kuntze:

the remote peer probably uses the DRAFT variant of sha2-256, which uses 96 bit 
truncation. strongSwan uses the actual standardized variant that truncates to 
128 bit.
You can switch between the two in the newest version of strongSwan

On 04.08.2017 12:23, Dusan Ilic wrote:

Hello!

I have a strange issue, with both settings below the tunnel goes up as it 
should, but only with SHA1 in ESP traffic goes through. When I ping the remote 
client with ESP SHA256 it times out, even though the tunnel reports as being up 
by Strongswan.

Traffic working:

ike=aes256-sha256-modp2048!
esp=aes128-sha1-modp2048!

Traffic not working:

ike=aes256-sha256-modp2048!
esp=aes256-sha256-modp2048!

Below combo doesn't work either:

ike=aes256-sha256-modp2048!
esp=aes128-sha256-modp2048!


Also, are above settings good? I'm having AES128 on ESP because with AES256 I 
loose too much througput. Do you have any suggestions for change?

Re: [strongSwan] SHA1 vs SHA256

2017-08-04 Thread Noel Kuntze 
the remote peer probably uses the DRAFT variant of sha2-256, which uses 96 bit 
truncation. strongSwan uses the actual standardized variant that truncates to 
128 bit.
You can switch between the two in the newest version of strongSwan

On 04.08.2017 12:23, Dusan Ilic wrote:
> Hello!
>
> I have a strange issue, with both settings below the tunnel goes up as it 
> should, but only with SHA1 in ESP traffic goes through. When I ping the 
> remote client with ESP SHA256 it times out, even though the tunnel reports as 
> being up by Strongswan.
>
> Traffic working:
>
> ike=aes256-sha256-modp2048!
> esp=aes128-sha1-modp2048!
>
> Traffic not working:
>
> ike=aes256-sha256-modp2048!
> esp=aes256-sha256-modp2048!
>
> Below combo doesn't work either:
>
> ike=aes256-sha256-modp2048!
> esp=aes128-sha256-modp2048!
>
>
> Also, are above settings good? I'm having AES128 on ESP because with AES256 I 
> loose too much througput. Do you have any suggestions for change?
>
>



signature.asc
Description: OpenPGP digital signature

[strongSwan] SHA1 vs SHA256

2017-08-04 Thread Dusan Ilic 

Hello!

I have a strange issue, with both settings below the tunnel goes up as 
it should, but only with SHA1 in ESP traffic goes through. When I ping 
the remote client with ESP SHA256 it times out, even though the tunnel 
reports as being up by Strongswan.


Traffic working:

ike=aes256-sha256-modp2048!
esp=aes128-sha1-modp2048!

Traffic not working:

ike=aes256-sha256-modp2048!
esp=aes256-sha256-modp2048!

Below combo doesn't work either:

ike=aes256-sha256-modp2048!
esp=aes128-sha256-modp2048!


Also, are above settings good? I'm having AES128 on ESP because with 
AES256 I loose too much througput. Do you have any suggestions for change?

Re: [strongSwan] Established but cannot ping with IKEv1 aggressive PSK+XAUTH

2017-08-04 Thread Andreas Tscharner 

On 03.08.2017 18:25, David Sautter wrote:

Hello all,

I'm trying to connect to my companies network. They have a Juniper
SRX-100 as VPN Gateway, which is working fine as tested with other VPN
clients. I'm using strongswan 5.5.3.

I'm using IKEv1 aggressive mode, PSK+XAUTH. The connection is
established, but i cannot ping any member of the company network.


What Kernel version are you using? I have had a similar problem and the 
culprit was Kernel 4.11. The lower 4.11.x versions are all affected, for 
me 4.11.11 worked again.


Best regards
Andreas
--
  ("`-''-/").___..--''"`-._
   `o_ o  )   `-.  ( ).`-.__.`)
   (_Y_.)'  ._   )  `._ `. ``-..-'
 _..`--'_..-_/  /--'_.' .'
(il).-''  (li).'  ((!.-'

Andreas Tscharner   a...@vis.ethz.ch   ICQ-No. 14356454