Re: [strongSwan] nonce Length

2017-09-14 Thread Jafar Al-Gharaibeh 

On 9/14/2017 11:53 AM, Andreas Steffen wrote:

Hi Jafar,

the mandatory nonce plugin is a nonce generator which returns
the requested number of random bytes. There are many other places in
the strongSwan code where nonces of variable size are needed
(e.g. for the IKE SPI or for the TLS client or server Hello).


Sure, my first grep -r "nonce" returned  hundreds if not thousands of 
results.


Thanks again for the explanation, and also for the great work of 
StrongSwan team.


Kind Regards,
Jafar


Kind regards

Andreas

On 14.09.2017 17:28, Jafar Al-Gharaibeh wrote:

Hi Andreas,

    Thanks for the quick and thorough answer. I did not find that piece
of information (nonce size) in the documentation, but as you noted about
the source code, I did download and dig through the source code
yesterday and came across the the 32 byte number. Thanks for confirming
that.

    I also came across nonce plugin configuration:
    nonce {
    }

Is there really any thing configurable here or is that just there for
completeness?

Kind Regards,
Jafar

On 9/14/2017 1:56 AM, Andreas Steffen wrote:

Hi Jafar,

section 2.10 of IKEv2 RFC 7296 [1] states that

    Nonces used in IKEv2
    MUST be randomly chosen, MUST be at least 128 bits in size, and 
MUST
    be at least half the key size of the negotiated pseudorandom 
function

    (PRF).  However, the initiator chooses the nonce before the outcome
    of the negotiation is known.  Because of that, the nonce has to be
    long enough for all the PRFs being proposed.

This is why strongSwan generates nonces with a constant size of 32 
bytes

(256 bits) as defined in nonce_payloads.h [2]

   /**
    * Nonce size in bytes for nonces sending to other peer.
    */
   #define NONCE_SIZE 32

Best regards

Andreas

[1]https://tools.ietf.org/html/rfc7296#section-2.10
[2]https://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libcharon/encoding/payloads/nonce_payload.h;h=ee8ad17f789ed4fe6a2e3476fc710b79d74885aa;hb=HEAD#l30 




On 13.09.2017 20:37, Jafar Al-Gharaibeh wrote:

Hi,

    What is the default length of the nonce used  to establish and 
rekey

IKE/Child SAs?  is that based on the DH group? and is the length
configurable?

Thanks,
Jafar

==
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]==

Re: [strongSwan] nonce Length

2017-09-14 Thread Andreas Steffen 

Hi Jafar,

the mandatory nonce plugin is a nonce generator which returns
the requested number of random bytes. There are many other places in
the strongSwan code where nonces of variable size are needed
(e.g. for the IKE SPI or for the TLS client or server Hello).

Kind regards

Andreas

On 14.09.2017 17:28, Jafar Al-Gharaibeh wrote:

Hi Andreas,

Thanks for the quick and thorough answer. I did not find that piece
of information (nonce size) in the documentation, but as you noted about
the source code, I did download and dig through the source code
yesterday and came across the the 32 byte number. Thanks for confirming
that.

I also came across nonce plugin configuration:
nonce {
}

Is there really any thing configurable here or is that just there for
completeness?

Kind Regards,
Jafar

On 9/14/2017 1:56 AM, Andreas Steffen wrote:

Hi Jafar,

section 2.10 of IKEv2 RFC 7296 [1] states that

Nonces used in IKEv2
MUST be randomly chosen, MUST be at least 128 bits in size, and MUST
be at least half the key size of the negotiated pseudorandom function
(PRF).  However, the initiator chooses the nonce before the outcome
of the negotiation is known.  Because of that, the nonce has to be
long enough for all the PRFs being proposed.

This is why strongSwan generates nonces with a constant size of 32 bytes
(256 bits) as defined in nonce_payloads.h [2]

   /**
* Nonce size in bytes for nonces sending to other peer.
*/
   #define NONCE_SIZE 32

Best regards

Andreas

[1]https://tools.ietf.org/html/rfc7296#section-2.10
[2]https://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libcharon/encoding/payloads/nonce_payload.h;h=ee8ad17f789ed4fe6a2e3476fc710b79d74885aa;hb=HEAD#l30


On 13.09.2017 20:37, Jafar Al-Gharaibeh wrote:

Hi,

What is the default length of the nonce used  to establish and rekey
IKE/Child SAs?  is that based on the DH group? and is the length
configurable?

Thanks,
Jafar

==
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]==





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



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [strongSwan] nonce Length

2017-09-14 Thread Jafar Al-Gharaibeh 

Hi Andreas,

   Thanks for the quick and thorough answer. I did not find that piece 
of information (nonce size) in the documentation, but as you noted about 
the source code, I did download and dig through the source code 
yesterday and came across the the 32 byte number. Thanks for confirming 
that.


   I also came across nonce plugin configuration:
   nonce {
   }

Is there really any thing configurable here or is that just there for 
completeness?


Kind Regards,
Jafar

On 9/14/2017 1:56 AM, Andreas Steffen wrote:

Hi Jafar,

section 2.10 of IKEv2 RFC 7296 [1] states that

Nonces used in IKEv2
MUST be randomly chosen, MUST be at least 128 bits in size, and MUST
be at least half the key size of the negotiated pseudorandom function
(PRF).  However, the initiator chooses the nonce before the outcome
of the negotiation is known.  Because of that, the nonce has to be
long enough for all the PRFs being proposed.

This is why strongSwan generates nonces with a constant size of 32 bytes
(256 bits) as defined in nonce_payloads.h [2]

   /**
* Nonce size in bytes for nonces sending to other peer.
*/
   #define NONCE_SIZE 32

Best regards

Andreas

[1]https://tools.ietf.org/html/rfc7296#section-2.10
[2]https://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libcharon/encoding/payloads/nonce_payload.h;h=ee8ad17f789ed4fe6a2e3476fc710b79d74885aa;hb=HEAD#l30

On 13.09.2017 20:37, Jafar Al-Gharaibeh wrote:

Hi,

What is the default length of the nonce used  to establish and rekey
IKE/Child SAs?  is that based on the DH group? and is the length
configurable?

Thanks,
Jafar

==
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]==

Re: [strongSwan] 24/7/365 tunnel?

2017-09-14 Thread Turbo Fredriksson 
On 14 Sep 2017, at 11:23, Eric Germann  wrote:

> I’ve found auto=route to be much more stable in AWS.  Spins up when it’s down 
> but needed and starts passing traffic.

Ok, thanx! I’ll let it run like this for a couple of days so I get a feel
for how it works and then try that if I have to..



signature.asc
Description: Message signed with OpenPGP

Re: [strongSwan] strongswan not picking up traffic

2017-09-14 Thread Noel Kuntze 
Hi,

You're expected to use auto=route. It is normal, by design and common with all 
other *swans, that auto=add does not initiate a connection.
You gotta read the manual/documentation before using the software.

Kind regards

Noel

On 14.09.2017 09:07, Chengcheng Fu wrote:
> Hi,
> 
> After I manually bring up the tunnel from the spoke side, it has started 
> working.
> 
> "ipsec up host-host".
> 
> But is this normal??
> 
> Regards,
> 
> Terry
> 
> On Sep 13, 2017, at 07:12 PM, Chengcheng Fu  wrote:
> 
>> Hi,
>>
>> The GRE tunnel is working on its own, it's like Strongswan is not even aware 
>> of it's happening, and not trying to encapsulate it.
>> I must be missing something simple.
>>
>> Below are my configs.
>>
>>
>> =
>> hub-192.168.23.193
>> =
>> # ipsec.conf #
>> config setup
>>
>> conn %default
>> ikelifetime=60m
>> keylife=20m
>> rekeymargin=3m
>> keyingtries=1
>> authby=secret
>> mobike=no
>> keyexchange=ikev2
>>
>> conn host-host
>> left=192.168.23.193
>> leftprotoport=gre
>> rightprotoport=gre
>> type=transport
>> auto=add
>> reauth=no
>> closeaction=clear
>> keyexchange=ikev2
>> right=%any
>> mark=%unique
>>
>>
>> # strongswan.conf #
>> charon {
>> load_modular = yes
>> plugins {
>> include strongswan.d/charon/*.conf
>> }
>> filelog {
>> /var/log/charon_debug.log {
>> time_format = %a, %Y-%m-%d %R
>> default = 2
>> mgr = 0
>> net = 1
>> enc = 1
>> asn = 1
>> job = 1
>> knl = 1
>> ike_name = yes
>> append = no
>> flush_line = yes
>> }
>> }
>> }
>>
>> include strongswan.d/*.conf
>>
>>
>>
>> # swanctl.conf #
>> include conf.d/*.conf
>>
>>
>>
>>
>> # ipsec statusall #
>> Status of IKE charon daemon (strongSwan 5.6.0, Linux 4.9.47, x86_64):
>> uptime: 12 minutes, since Sep 14 09:52:04 2017
>> malloc: sbrk 1081344, mmap 0, used 267712, free 813632
>> worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, 
>> scheduled: 0
>> loaded plugins: charon aes des rc2 sha2 sha1 md5 random nonce x509 
>> revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem 
>> fips-prf gmp curve25519 xcbc cmac hmac attr kernel-netlink resolve 
>> socket-default stroke vici updown xauth-generic
>> Listening IP addresses:
>> 192.168.23.193
>> 192.168.34.1
>> Connections:
>> host-host: 192.168.23.193...%any IKEv2
>> host-host: local: [192.168.23.193] uses pre-shared key authentication
>> host-host: remote: uses pre-shared key authentication
>> host-host: child: dynamic[gre] === dynamic[gre] TRANSPORT
>> Security Associations (0 up, 0 connecting):
>> none
>>
>>
>>
>>
>> # iptables -L -v #
>> Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
>> pkts bytes target prot opt in out source destination
>> 25 1876 ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED
>> 0 0 ACCEPT icmp -- any any anywhere anywhere
>> 0 0 ACCEPT all -- lo any anywhere anywhere
>> 0 0 ACCEPT tcp -- any any anywhere anywhere state NEW tcp dpt:ssh
>>
>> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
>> pkts bytes target prot opt in out source destination
>>
>> Chain OUTPUT (policy ACCEPT 13 packets, 1332 bytes)
>> pkts bytes target prot opt in out source destination
>>
>>
>>
>>
>>
>> # ip route show table all #
>> default via 192.168.23.232 dev eth0 proto static metric 20
>> default via 192.168.23.232 dev eth0 proto static metric 100
>> 192.168.23.0/24 dev eth0 proto kernel scope link src 192.168.23.193 metric 
>> 100
>> 192.168.34.3 dev gre1 proto kernel scope link src 192.168.34.1
>> broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
>> local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
>> local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
>> broadcast 127.255.255.255 dev lo table local proto kernel scope link src 
>> 127.0.0.1
>> broadcast 192.168.23.0 dev eth0 table local proto kernel scope link src 
>> 192.168.23.193
>> local 192.168.23.193 dev eth0 table local proto kernel scope host src 
>> 192.168.23.193
>> broadcast 192.168.23.255 dev eth0 table local proto kernel scope link src 
>> 192.168.23.193
>> local 192.168.34.1 dev gre1 table local proto kernel scope host src 
>> 192.168.34.1
>> unreachable default dev lo proto kernel metric 4294967295 error -101 pref 
>> medium
>> unreachable ::/96 dev lo metric 1024 error -113 pref medium
>> unreachable :::0.0.0.0/96 dev lo metric 1024 error -113 pref medium
>> unreachable 2002:a00::/24 dev lo metric 1024 error -113 pref medium
>> unreachable 2002:7f00::/24 dev lo metric 1024 error -113 pref medium
>> unreachable 2002:a9fe::/32 dev lo metric 1024 error -113 pref medium
>> unreachable 2002:ac10::/28 dev lo metric 1024 error -113 pref medium
>> unreachable 2002:c0a8::/32 dev lo metric 1024 error -113 pref medium
>> unreachable 2002:e000::/19 dev lo metric 1024 error -113 pref medium
>> unreachable 3ffe:::/32 dev lo metric 1024 error -113 pref medium
>> fe80::/64 dev

Re: [strongSwan] 24/7/365 tunnel?

2017-09-14 Thread Noel Kuntze 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

You need to use auto=route, otherwise the tunnel will not be established 
(anymore) if it ever gets deleted by one side, a fatal error is encountered or 
it can not
be established in the first place.

On 14.09.2017 12:23, Eric Germann wrote:
> I’ve found auto=route to be much more stable in AWS.  Spins up when it’s down 
> but needed and starts passing traffic. > > EKG > >> On Sep 14, 2017, at 6:21 
> AM, Turbo Fredriksson  wrote: >> >> I’ve been playing with: 
> >> >> type=tunnel >> auto=start >> dpdaction=restart >> dpddelay=2400s >> >> 
> which never worked. I’ve now changed this to: >> >> type=tunnel >> auto=start 
> >> dpdaction=restart >> dpddelay=10 >> dpdtimeout=60 >> >> and so far so 
> good. Although I haven’t waited long enough, so I’m >> going to let it be for 
> the next few days to see if that works in the long >> run. >> >> Would it 
> help to set ‘auto=route’ instead? Thing is, I need this link to >> be started 
> at boot AND be up 24/7/365 - I have a (bunch of) web apps >> in London that 
> need access to databases in Ireland to work. >> >> >> I’m considering setting 
> up DBs in London as well, but that will both >> cost a small fortune AND 
> replication/updates on the DBs will be >> problematic. So I’d prefer a 
> “perfect” link between them... >> >> >>> On 13 Sep 2017, at 20:16, Noel Kuntze
 wrote: >>> >>> Hi, >>> >>> 
DPD just checks if the remote peer is still "there" and reachable. It doesn't 
do anything with the CHILD_SAs. >>> It only helps to keep up the IKE_SA and 
keep it working (e.g. it wouldn't work anymore if the NAT mapping on an 
intermediate NAT router >>> would expire). Peers are free to delete CHILD_SAs 
and IKE_SAs without renegotiating new ones, destroying the tunnel. >>> >>> Use 
auto=route (swanctl equivalent is start_action=trap), as advised previously. 
>>> >>> Kind regards >>> >>> Noel >>> >>> On 13.09.2017 17:38, Michael 
Schwartzkopff wrote:  Am 13.09.2017 um 17:33 schrieb Eric Germann: > 
Usually if it "takes down the tunnel" it's due to no traffic. Keep interesting 
traffic going and it will stay up. > > If you have the ability to set 
"auto = route" it will reestablish the tunnel as needed. We run several hundred 
tunnels this way in AWS without issue. > > EKG > >
>> On Sep 13, 2017, at 09:21, Turbo Fredriksson  wrote: 
>> >> >> I’m trying to setup a tunnel between two regions in >> 
>> AWS. >> >> Works fine, other than the fact that Strongswan seems 
>> to take >> down the tunnel automatically (?) after a few hours. 
>> >> >> How can I 1) make sure there’s no timeout (?) and 2) that 
>> IF >> the tunnel goes down, for whatever reason, that it will 
>> reinitiate >> the connection automatically? >>  Dead Peer 
>> Detection (DPD) sends packets that keep the tunnel up.    
>> Michael Schwartzkopff   Mit freundlichen Grüßen,  >>> >> > 
>> -BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEENSSTvrX3jmMTcq8t9U7kCwc5rWwFAlm6X6cACgkQ9U7kCwc5
rWy5Cg/+P02oFmCJwB9qiREw4DXCRZRCo8HAeC6mlP0P95PfvWy4Lr20LX1SMNhw
PBgm7c7dQHyKjQO/fqGPTB4kbi03Or5lYtyYLc3Y1YDJ79W2OpVTCiHoaznleyW6
elVZyPBhxeZYYWI4FekcgOB9vS+ek8Jbz2FNI+16b7hfHwN3QnkU1X5DH9oVkO+J
aW0ywUwKgNMMxtDEmFvUffBb/uxJ1DOq4XHaNIYNicOQ6wkbc3GMlbVh6Bz7MUbI
RJutqLiZqMy7Da6VPP6Xf+Y1ogvCLPmzqDHCxhwCrw2b3BBgOSpNqMzV+37h5POh
qTFabCd42PC8lNm8BGrEixvVk3GqHkIshaww0bdqrYYdYh3DQHqbBfQsWCS62r8q
iSrccp4CUxSzTp5VEcGT8GFPAXT7lcsovl2iPnAodl9TMiksh9JqzwhIZy0DPiAA
JgB+AwFk8mTZZXmr2WDHQo2cUI8u+ZRuh5mOYSqgBNebOUuFUBA7X/uHuKFwhugg
F1QWG2QFF3CljSjZKY27YpSDh6Hf2IGk+RiKfQbVhpBMF9QjlSyXIc6wbceol9y/
621zjVb5JpNbu7UYslCoUAQkjGFpjPGAtsiqpfPYObTmoA8rSrlbcV0y9+BrXbHV
bGFQi1ktqUC5h2Lio5S0PnIRtrGOKhX23dfbUA0VKUJCqXzP+GI=
=W4nf
-END PGP SIGNATURE-

Re: [strongSwan] 24/7/365 tunnel?

2017-09-14 Thread Eric Germann 
I’ve found auto=route to be much more stable in AWS.  Spins up when it’s down 
but needed and starts passing traffic.

EKG

> On Sep 14, 2017, at 6:21 AM, Turbo Fredriksson  wrote:
> 
> I’ve been playing with:
> 
>type=tunnel
>auto=start
>dpdaction=restart
>dpddelay=2400s
> 
> which never worked. I’ve now changed this to:
> 
>type=tunnel
>auto=start
>dpdaction=restart
>dpddelay=10
>dpdtimeout=60
> 
> and so far so good. Although I haven’t waited long enough, so I’m
> going to let it be for the next few days to see if that works in the long
> run.
> 
> Would it help to set ‘auto=route’ instead? Thing is, I need this link to
> be started at boot AND be up 24/7/365 - I have a (bunch of) web apps
> in London that need access to databases in Ireland to work.
> 
> 
> I’m considering setting up DBs in London as well, but that will both
> cost a small fortune AND replication/updates on the DBs will be
> problematic. So I’d prefer a “perfect” link between them...
> 
> 
>> On 13 Sep 2017, at 20:16, Noel Kuntze 
>>  wrote:
>> 
>> Hi,
>> 
>> DPD just checks if the remote peer is still "there" and reachable. It 
>> doesn't do anything with the CHILD_SAs.
>> It only helps to keep up the IKE_SA and keep it working (e.g. it wouldn't 
>> work anymore if the NAT mapping on an intermediate NAT router
>> would expire). Peers are free to delete CHILD_SAs and IKE_SAs without 
>> renegotiating new ones, destroying the tunnel.
>> 
>> Use auto=route (swanctl equivalent is start_action=trap), as advised 
>> previously.
>> 
>> Kind regards
>> 
>> Noel
>> 
>> On 13.09.2017 17:38, Michael Schwartzkopff wrote:
>>> Am 13.09.2017 um 17:33 schrieb Eric Germann:
 Usually if it "takes down the tunnel" it's due to no traffic. Keep 
 interesting traffic going and it will stay up.
 
 If you have the ability to set "auto = route" it will reestablish the 
 tunnel as needed. We run several hundred tunnels this way in AWS without 
 issue.
 
 EKG
 
 
> On Sep 13, 2017, at 09:21, Turbo Fredriksson  wrote:
> 
> I’m trying to setup a tunnel between two regions in
> AWS.
> 
> Works fine, other than the fact that Strongswan seems to take
> down the tunnel automatically (?) after a few hours.
> 
> How can I 1) make sure there’s no timeout (?) and 2) that IF
> the tunnel goes down, for whatever reason, that it will reinitiate
> the connection automatically?
> 
>>> Dead Peer Detection (DPD) sends packets that keep the tunnel up.
>>> 
>>> 
>>> Michael Schwartzkopff
>>> 
>>> Mit freundlichen Grüßen,
>>> 
>> 
> 



signature.asc
Description: Message signed with OpenPGP

Re: [strongSwan] 24/7/365 tunnel?

2017-09-14 Thread Turbo Fredriksson 
I’ve been playing with:

type=tunnel
auto=start
dpdaction=restart
dpddelay=2400s

which never worked. I’ve now changed this to:

type=tunnel
auto=start
dpdaction=restart
dpddelay=10
dpdtimeout=60

and so far so good. Although I haven’t waited long enough, so I’m
going to let it be for the next few days to see if that works in the long
run.

Would it help to set ‘auto=route’ instead? Thing is, I need this link to
be started at boot AND be up 24/7/365 - I have a (bunch of) web apps
in London that need access to databases in Ireland to work.


I’m considering setting up DBs in London as well, but that will both
cost a small fortune AND replication/updates on the DBs will be
problematic. So I’d prefer a “perfect” link between them...


> On 13 Sep 2017, at 20:16, Noel Kuntze 
>  wrote:
> 
> Hi,
> 
> DPD just checks if the remote peer is still "there" and reachable. It doesn't 
> do anything with the CHILD_SAs.
> It only helps to keep up the IKE_SA and keep it working (e.g. it wouldn't 
> work anymore if the NAT mapping on an intermediate NAT router
> would expire). Peers are free to delete CHILD_SAs and IKE_SAs without 
> renegotiating new ones, destroying the tunnel.
> 
> Use auto=route (swanctl equivalent is start_action=trap), as advised 
> previously.
> 
> Kind regards
> 
> Noel
> 
> On 13.09.2017 17:38, Michael Schwartzkopff wrote:
>> Am 13.09.2017 um 17:33 schrieb Eric Germann:
>>> Usually if it "takes down the tunnel" it's due to no traffic. Keep 
>>> interesting traffic going and it will stay up.
>>> 
>>> If you have the ability to set "auto = route" it will reestablish the 
>>> tunnel as needed. We run several hundred tunnels this way in AWS without 
>>> issue.
>>> 
>>> EKG
>>> 
>>> 
 On Sep 13, 2017, at 09:21, Turbo Fredriksson  wrote:
 
 I’m trying to setup a tunnel between two regions in
 AWS.
 
 Works fine, other than the fact that Strongswan seems to take
 down the tunnel automatically (?) after a few hours.
 
 How can I 1) make sure there’s no timeout (?) and 2) that IF
 the tunnel goes down, for whatever reason, that it will reinitiate
 the connection automatically?
 
>> Dead Peer Detection (DPD) sends packets that keep the tunnel up.
>> 
>> 
>> Michael Schwartzkopff
>> 
>> Mit freundlichen Grüßen,
>> 
> 



signature.asc
Description: Message signed with OpenPGP

Re: [strongSwan] Strongswan. Address definition/Routing.

2017-09-14 Thread Aleksey Kravchenko 
Hello, Noel. Thanks for the answer. Unfortunately, there is no way to
bypass.As a solution we can use the second white IP for Strongswan, and the
web server on the 1st IP.

2017-09-13 22:17 GMT+03:00 Noel Kuntze <
noel.kuntze+strongswan-users-ml@thermi.consulting>:

> Hi,
>
> That is because Windows and MacOS implement crappy route based IPsec which
> conceptually can not protect traffic to the IKE peer's
> address (unless policy based routing is used, which neither Windows nor
> MacOS implement).
>
> Kind regards
>
> Noel
>
> On 13.09.2017 17:14, Aleksey Kravchenko wrote:
> > Hello.I need your advice.
> > The work of Strongswan + IKEv2 is configured. Everything works fine (on
> iOS, macOS, windows, linux), but I noticed strange behavior in VPN's work.
> There is a server on which Strongswan and Nginx are installed.When you
> connect to the VPN and go to the site which is located in the same place as
> the strongswan daemon, the nginx log shows different addresses for
> connections. For instance:android / linux -> login from the address issued
> by the VPN  (for example, 192.168.1.2).
> > windows / macos -> login from the usual address (provider address).
> > But if you go to the IP detection server, the result for all devices is
> the same: you logged in from the VPN server.Maybe you have any thoughts
> about this? Thank you!
>
>

Re: [strongSwan] strongswan not picking up traffic

2017-09-14 Thread Chengcheng Fu 
Hi,After I manually bring up the tunnel from the spoke side, it has started working."ipsec up host-host".But is this normal??Regards,TerryOn Sep 13, 2017, at 07:12 PM, Chengcheng Fu  wrote:Hi,The GRE tunnel is working on its own, it's like Strongswan is not even aware of it's happening, and not trying to encapsulate it.I must be missing something simple.Below are my configs.= hub-192.168.23.193=# ipsec.conf #config setupconn %default ikelifetime=60m keylife=20m rekeymargin=3m keyingtries=1 authby=secret mobike=no keyexchange=ikev2conn host-host left=192.168.23.193 leftprotoport=gre rightprotoport=gre type=transport auto=add reauth=no closeaction=clear keyexchange=ikev2 right=%any mark=%unique# strongswan.conf #charon { load_modular = yes plugins { include strongswan.d/charon/*.conf } filelog { /var/log/charon_debug.log { time_format = %a, %Y-%m-%d %R default = 2 mgr = 0 net = 1 enc = 1 asn = 1 job = 1 knl = 1 ike_name = yes append = no flush_line = yes } }}include strongswan.d/*.conf# swanctl.conf #include conf.d/*.conf# ipsec statusall #Status of IKE charon daemon (strongSwan 5.6.0, Linux 4.9.47, x86_64): uptime: 12 minutes, since Sep 14 09:52:04 2017 malloc: sbrk 1081344, mmap 0, used 267712, free 813632 worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 0 loaded plugins: charon aes des rc2 sha2 sha1 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem fips-prf gmp curve25519 xcbc cmac hmac attr kernel-netlink resolve socket-default stroke vici updown xauth-genericListening IP addresses: 192.168.23.193 192.168.34.1Connections: host-host: 192.168.23.193...%any IKEv2 host-host: local: [192.168.23.193] uses pre-shared key authentication host-host: remote: uses pre-shared key authentication host-host: child: dynamic[gre] === dynamic[gre] TRANSPORTSecurity Associations (0 up, 0 connecting): none# iptables -L -v #Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination  25 1876 ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED 0 0 ACCEPT icmp -- any any anywhere anywhere  0 0 ACCEPT all -- lo any anywhere anywhere  0 0 ACCEPT tcp -- any any anywhere anywhere state NEW tcp dpt:sshChain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 13 packets, 1332 bytes) pkts bytes target prot opt in out source destination # ip route show table all #default via 192.168.23.232 dev eth0 proto static metric 20 default via 192.168.23.232 dev eth0 proto static metric 100 192.168.23.0/24 dev eth0 proto kernel scope link src 192.168.23.193 metric 100 192.168.34.3 dev gre1 proto kernel scope link src 192.168.34.1 broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1 local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 broadcast 192.168.23.0 dev eth0 table local proto kernel scope link src 192.168.23.193 local 192.168.23.193 dev eth0 table local proto kernel scope host src 192.168.23.193 broadcast 192.168.23.255 dev eth0 table local proto kernel scope link src 192.168.23.193 local 192.168.34.1 dev gre1 table local proto kernel scope host src 192.168.34.1 unreachable default dev lo proto kernel metric 4294967295 error -101 pref mediumunreachable ::/96 dev lo metric 1024 error -113 pref mediumunreachable :::0.0.0.0/96 dev lo metric 1024 error -113 pref mediumunreachable 2002:a00::/24 dev lo metric 1024 error -113 pref mediumunreachable 2002:7f00::/24 dev lo metric 1024 error -113 pref mediumunreachable 2002:a9fe::/32 dev lo metric 1024 error -113 pref mediumunreachable 2002:ac10::/28 dev lo metric 1024 error -113 pref mediumunreachable 2002:c0a8::/32 dev lo metric 1024 error -113 pref mediumunreachable 2002:e000::/19 dev lo metric 1024 error -113 pref mediumunreachable 3ffe:::/32 dev lo metric 1024 error -113 pref mediumfe80::/64 dev eth0 proto kernel metric 256 pref mediumfe80::/64 dev gre1 proto kernel metric 256 pref mediumunreachable default dev lo proto kernel metric 4294967295 error -101 pref mediumlocal ::1 dev lo table local proto none metric 0 pref mediumlocal fe80:: dev lo table local proto none metric 0 pref mediumlocal fe80:: dev lo table local proto none metric 0 pref mediumlocal fe80::5efe:c0a8:17c1 dev lo table local proto none metric 0 pref mediumlocal fe80::5054:ff:fecb:abeb dev lo table local proto none metric 0 pref mediumff00::/8 dev eth1 table local metric 256 pref mediumff00::/8 dev eth2 table local metric 256 pref mediumff00::/8 dev eth0 table local metric 256 pref mediumff00::/8 dev gre1 table local metric 256 pref mediumunreachable default dev lo proto kernel metric 4294967295 error

Re: [strongSwan] nonce Length

2017-09-14 Thread Andreas Steffen 
Hi Jafar,

section 2.10 of IKEv2 RFC 7296 [1] states that

   Nonces used in IKEv2
   MUST be randomly chosen, MUST be at least 128 bits in size, and MUST
   be at least half the key size of the negotiated pseudorandom function
   (PRF).  However, the initiator chooses the nonce before the outcome
   of the negotiation is known.  Because of that, the nonce has to be
   long enough for all the PRFs being proposed.

This is why strongSwan generates nonces with a constant size of 32 bytes
(256 bits) as defined in nonce_payloads.h [2]

  /**
   * Nonce size in bytes for nonces sending to other peer.
   */
  #define NONCE_SIZE 32

Best regards

Andreas

[1]https://tools.ietf.org/html/rfc7296#section-2.10
[2]https://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libcharon/encoding/payloads/nonce_payload.h;h=ee8ad17f789ed4fe6a2e3476fc710b79d74885aa;hb=HEAD#l30

On 13.09.2017 20:37, Jafar Al-Gharaibeh wrote:
> Hi,
> 
>What is the default length of the nonce used  to establish and rekey 
> IKE/Child SAs?  is that based on the DH group? and is the length
> configurable?
> 
> Thanks,
> Jafar

==
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]==