Re: [strongSwan] dpd not getting triggered

[Kalyani Garigipati (kagarigi)]

Hi,

Thanks a lot for the reply. It worked. I see the dpd triggering now.

I am working on a case when dpd from strongswan sends the nat detection 
payloads.
I wanted to know upon which conditions strongswan would send dpd request with 
nat_detection_src_ip and nat_detection_dst_ip.

Is it done only in specific case like when strongswan is behind the nat ? and 
strongswan is in remote-access-client ?

Regards,
kalyani

From: bls s [mailto:bl...@outlook.com]
Sent: Friday, January 12, 2018 6:40 AM
To: Kalyani Garigipati (kagarigi) ; 
users@lists.strongswan.org
Subject: RE: [strongSwan] dpd not getting triggered


By default dpdaction=none, which disables sending dpd messages.



From: Kalyani Garigipati (kagarigi)
Sent: Thursday, January 11, 2018 10:47 AM
To: users@lists.strongswan.org
Subject: [strongSwan] dpd not getting triggered


Hi,

I am using strongswan version 5.6.1
I found that even though I configured dpd using dpddelay and dpdtimeout, dpd is 
not getting triggered from strongswan client at all even though there is no 
traffic passing.
Please let me know how to debug this.


config setup
 charondebug=all
# crlcheckinterval=600
# strictcrlpolicy=yes
# cachecrls=yes
# nat_traversal=yes
# charonstart=no

conn %default
   ikelifetime=100m
   keylife=20m
   rekeymargin=8m
   keyingtries=1
   authby=psk
   keyexchange=ikev2
   ike=aes256-sha256-modp1024
   esp=3des-sha1
   mobike=yes
   dpddelay=5s
   dpdtimeout=150s

# Add connections here.

# Add connections here.
conn net-net
left=10.127.47.104
leftsubnet=10.127.47.104/32
leftid=10.127.47.104
right=10.104.108.110
rightsubnet=10.104.108.110/32
rightid=10.104.108.110
auto=start

~
Regards,
kalyani

Re: [strongSwan] Reconnect failed with android phone

[JWD]

Nothing logged when android disconnect. Android does not send any message to 
strongswan.
EAP-MSCHAPv2 works find on my PC.

Jan 12 09:07:20 03[NET] <4> received packet: from 223.104.3.235[26141] to 
172.31.2.1[500] (476 bytes)
Jan 12 09:07:20 03[ENC] <4> parsed ID_PROT request 0 [ SA V V V V V V V V ]
Jan 12 09:07:20 03[IKE] <4> received NAT-T (RFC 3947) vendor ID
Jan 12 09:07:20 03[IKE] <4> received draft-ietf-ipsec-nat-t-ike-02 vendor ID
Jan 12 09:07:20 03[IKE] <4> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
Jan 12 09:07:20 03[IKE] <4> received draft-ietf-ipsec-nat-t-ike-00 vendor ID
Jan 12 09:07:20 03[IKE] <4> received XAuth vendor ID
Jan 12 09:07:20 03[IKE] <4> received Cisco Unity vendor ID
Jan 12 09:07:20 03[IKE] <4> received FRAGMENTATION vendor ID
Jan 12 09:07:20 03[IKE] <4> received DPD vendor ID
Jan 12 09:07:20 03[IKE] <4> 223.104.3.235 is initiating a Main Mode IKE_SA
Jan 12 09:07:20 03[ENC] <4> generating ID_PROT response 0 [ SA V V V V ]
Jan 12 09:07:20 03[NET] <4> sending packet: from 172.31.2.1[500] to 
223.104.3.235[26141] (160 bytes)
Jan 12 09:07:20 12[NET] <4> received packet: from 223.104.3.235[26141] to 
172.31.2.1[500] (228 bytes)
Jan 12 09:07:20 12[ENC] <4> parsed ID_PROT request 0 [ KE No NAT-D NAT-D ]
Jan 12 09:07:20 12[IKE] <4> local host is behind NAT, sending keep alives
Jan 12 09:07:20 12[IKE] <4> remote host is behind NAT
Jan 12 09:07:20 12[ENC] <4> generating ID_PROT response 0 [ KE No NAT-D NAT-D ]
Jan 12 09:07:20 12[NET] <4> sending packet: from 172.31.2.1[500] to 
223.104.3.235[26141] (244 bytes)
Jan 12 09:07:20 16[NET] <4> received packet: from 223.104.3.235[21528] to 
172.31.2.1[4500] (92 bytes)
Jan 12 09:07:20 16[ENC] <4> parsed ID_PROT request 0 [ ID HASH ]
Jan 12 09:07:20 16[CFG] <4> looking for XAuthInitPSK peer configs matching 
172.31.2.1...223.104.3.235[10.58.28.34]
Jan 12 09:07:20 16[CFG] <4> selected peer config "XAuth-PSK"
Jan 12 09:07:20 16[ENC]  generating ID_PROT response 0 [ ID HASH ]
Jan 12 09:07:20 16[NET]  sending packet: from 172.31.2.1[4500] to 
223.104.3.235[21528] (76 bytes)
Jan 12 09:07:20 16[ENC]  generating TRANSACTION request 2279139339 
[ HASH CPRQ(X_USER X_PWD) ]
Jan 12 09:07:20 16[NET]  sending packet: from 172.31.2.1[4500] to 
223.104.3.235[21528] (76 bytes)
Jan 12 09:07:20 05[NET]  received packet: from 
223.104.3.235[21528] to 172.31.2.1[4500] (108 bytes)
Jan 12 09:07:20 05[ENC]  parsed INFORMATIONAL_V1 request 
3724774013 [ HASH N(INITIAL_CONTACT) ]
Jan 12 09:07:20 04[NET]  received packet: from 
223.104.3.235[21528] to 172.31.2.1[4500] (108 bytes)
Jan 12 09:07:20 04[ENC]  parsed TRANSACTION response 2279139339 [ 
HASH CPRP(X_USER X_PWD) ]
Jan 12 09:07:20 04[CFG]  sending RADIUS Access-Request to server 
'127.0.0.1'
Jan 12 09:07:20 04[CFG]  received RADIUS Access-Accept from server 
'127.0.0.1'
Jan 12 09:07:20 04[IKE]  XAuth authentication of 'vpnuser1' 
successful
Jan 12 09:07:20 04[ENC]  generating TRANSACTION request 3413157947 
[ HASH CPS(X_STATUS) ]
Jan 12 09:07:20 04[NET]  sending packet: from 172.31.2.1[4500] to 
223.104.3.235[21528] (76 bytes)
Jan 12 09:07:20 09[NET]  received packet: from 
223.104.3.235[21528] to 172.31.2.1[4500] (92 bytes)
Jan 12 09:07:20 09[ENC]  parsed TRANSACTION response 3413157947 [ 
HASH CPA(X_STATUS) ]
Jan 12 09:07:20 09[IKE]  IKE_SA XAuth-PSK[4] established between 
172.31.2.1[172.31.2.1]...223.104.3.235[10.58.28.34]
Jan 12 09:07:20 09[IKE]  scheduling reauthentication in 10139s
Jan 12 09:07:20 09[IKE]  maximum IKE_SA lifetime 10679s
Jan 12 09:07:20 07[NET]  received packet: from 
223.104.3.235[21528] to 172.31.2.1[4500] (124 bytes)
Jan 12 09:07:20 07[ENC]  parsed TRANSACTION request 3929122124 [ 
HASH CPRQ(ADDR MASK DNS NBNS U_BANNER U_DEFDOM U_SPLITDNS U_SPLITINC U_LOCALLAN 
VER) ]
Jan 12 09:07:20 07[IKE]  peer requested virtual IP %any
Jan 12 09:07:20 07[CFG]  assigning new lease to 'vpnuser1'
Jan 12 09:07:20 07[IKE]  assigning virtual IP 172.31.254.1 to peer 
'vpnuser1'
Jan 12 09:07:20 07[ENC]  generating TRANSACTION response 
3929122124 [ HASH CPRP(ADDR DNS NBNS DNS NBNS) ]
Jan 12 09:07:20 07[NET]  sending packet: from 172.31.2.1[4500] to 
223.104.3.235[21528] (108 bytes)
Jan 12 09:07:39 11[NET]  received packet: from 
223.104.3.235[21528] to 172.31.2.1[4500] (364 bytes)
Jan 12 09:07:39 11[ENC]  parsed QUICK_MODE request 3003341863 [ 
HASH SA No ID ID ]
Jan 12 09:07:39 11[IKE]  received 28800s lifetime, configured 3600s
Jan 12 09:07:39 11[ENC]  generating QUICK_MODE response 3003341863 
[ HASH SA No ID ID ]
Jan 12 09:07:39 11[NET]  sending packet: from 172.31.2.1[4500] to 
223.104.3.235[21528] (172 bytes)
Jan 12 09:07:39 10[NET]  received packet: from 
223.104.3.235[21528] to 172.31.2.1[4500] (76 bytes)
Jan 12 09:07:39 10[ENC]  parsed QUICK_MODE request 3003341863 [ 
HASH ]
Jan 12 09:07:39 10[IKE]  CHILD_SA XAuth-PSK{6} established with 
SPIs cdf6f39c_i 0c4a03f5_o and TS 0.0.0.0/0 === 172.31.254.1/32

Jan 12 09:09:15 07[NET] <5> received packet: from 223.104.3.235[26141] to 
172.31.2.1[500] (4

[strongSwan] dpd not getting triggered

[Kalyani Garigipati (kagarigi)]

Hi,

I am using strongswan version 5.6.1
I found that even though I configured dpd using dpddelay and dpdtimeout, dpd is 
not getting triggered from strongswan client at all even though there is no 
traffic passing.
Please let me know how to debug this.


config setup
 charondebug=all
# crlcheckinterval=600
# strictcrlpolicy=yes
# cachecrls=yes
# nat_traversal=yes
# charonstart=no

conn %default
   ikelifetime=100m
   keylife=20m
   rekeymargin=8m
   keyingtries=1
   authby=psk
   keyexchange=ikev2
   ike=aes256-sha256-modp1024
   esp=3des-sha1
   mobike=yes
   dpddelay=5s
   dpdtimeout=150s

# Add connections here.

# Add connections here.
conn net-net
left=10.127.47.104
leftsubnet=10.127.47.104/32
leftid=10.127.47.104
right=10.104.108.110
rightsubnet=10.104.108.110/32
rightid=10.104.108.110
auto=start

~
Regards,
kalyani

Re: [strongSwan] IPSec Tunnel IP

[Jafar Al-Gharaibeh]

you also have to delete the setting at the AP side, just get rid of this:

  ipsec     primary tunnel peer tunnel ip         :1.1.1.127

--Jafar

On 1/11/2018 2:06 AM, Yusuf Güngör wrote:

Hi Jafar,

I have tried both deleting "rightsubnet=0.0.0.0/0 " 
and adding "rightsubnet=%dynamic" now. AP still gets "1.1.1.127" as 
peer tunnel ip.


ipsec     primary tunnel peer tunnel ip        :1.1.1.127
ipsec     primary tunnel ap tunnel ip           :10.254.0.1

The problem caused from AP side?


2018-01-10 21:00 GMT+03:00 Jafar Al-Gharaibeh >:


Yusuf,

  Have you tried deleting "rightsubnet=0.0.0.0/0
" as Noel suggested below?

  In a dynamic address setup like this I usually do (Which has the
same effect of deleting it):

  rightsubnet=%dynamic


--Jafar


On 1/10/2018 4:28 AM, Yusuf Güngör wrote:

Hi Noel,

We have APs which located at various locations. APs get ip from
strongswan.

We have to add the "rightsubnet=0.0.0.0/0 " to
let APs connect. (We do not know the APs private-public ip addreses)

We have to add the "rightsourceip=10.254.0.0/24
" to give APs tunnel ip.

APs can get ip from the "righsourceip" pool successfully:

ipsec  primary tunnel ap tunnel ip  :10.254.0.1


But why peer tunnel ip is "1.1.1.127"

ipsec  primary tunnel peer tunnel ip  :1.1.1.127


We can establish vpn connections from APs to Aruba Controllers
and that time APs get ip addresses as expected:

ipsec     primary tunnel ap tunnel ip           :10.254.0.1

ipsec     primary tunnel peer tunnel ip         :
*
*

We are missing something?

Also, VPN connection to strongswan restarts about every 3 hours.
AP disconnect and reconnect because of packet loss. This should
be subject of another topic, i wrote if something is related with
that.

Thanks for help.

2017-12-28 16:12 GMT+03:00 Noel Kuntze
mailto:noel.kuntze+strongswan-users-ml@thermi.consulting>>:

Hello,

It's because you set "rightsubnet=0.0.0.0/0
" and evidently the AP proposes "1.1.1.127"
as its local TS, so it gets narrowed to that. I propose you
delete those two lines.

Kind regards

Noel

On 27.12.2017 11:01, Yusuf Güngör wrote:
> Hi,
>
> I have a configuration like below and VPN connection
successfully established but client side get "1.1.1.127" as
tunnel IP. Can we change this tunnel IP? I can not find any
clue about why StrongSwan assign "1.1.1.127" as tunnel IP to
clients?
>
> Thanks.
>
>
> *StrongSwan Config (Left)*
>
>     conn vpn-test
>       left=%defaultroute
>       leftsubnet=172.30.1.1/25 

>       leftauth=psk
>       leftfirewall=no
>       right=%any
>       rightsubnet=0.0.0.0/0 

>       rightsourceip=10.254.0.0/24 

>       auto=add
>       keyexchange=ikev1
>       rightauth=psk
>       rightauth2=xauth
>       type=tunnel
>       mobike=yes
>       rightid=%any
>
>
> *Client VPN Status: (Aruba Instant AP - Right)*
>
>     current using tunnel               :primary tunnel
>     current tunnel using time                :1 hour 43
minutes 31 seconds
>     ipsec is preempt status                :disable
>     ipsec is fast failover status                :disable
>     ipsec hold on period               :0s
>     ipsec tunnel monitor frequency (seconds/packet) :5
>     ipsec tunnel monitor timeout by lost packet cnt :6
>
>     ipsec     primary tunnel crypto type            :PSK
>     ipsec     primary tunnel peer address         
 :52.55.49.104
>     ipsec     primary tunnel peer tunnel ip         :1.1.1.127
>     ipsec     primary tunnel ap tunnel ip           :10.254.0.1
>     ipsec     primary tunnel using interface        :tun0
>     ipsec     primary tunnel using MTU              :1230
>     ipsec     primary tunnel current sm status      :Up
>     ipsec     primary tunnel tunnel status          :Up
>     ipsec     primary tunnel tunnel retry times     :6
>     ipsec     primary tunnel tunnel uptime          :1 hour
43 minutes 31 seconds
>
>     ipsec      backup tunnel crypto type            :PSK
>     ipsec      backup tunnel peer address           :N/A
>     ipsec      backup tunnel peer tunnel ip         :N/A
>  

Re: [strongSwan] mobileconfig file - do i need to install a root CA

[Alex Sharaz]

Sorted, in the .mobileconfig I had Server Certificate Issuer Common name
set to the root ca name. Removed that config, deletes the root ca and it
worked

BTW had the root/intermed certs in cacerts

Rgds
Alex


On 11 January 2018 at 12:17, Noel Kuntze <
noel.kuntze+strongswan-users-ml@thermi.consulting> wrote:

> Put the root CA and the intermediate CAs into /etc/ipsec.d/cacerts, then
> run `ipsec stroke rereadcacerts` and then retry.
> If that does not help, check the logs of iOS. You can get access to them
> via Apple's SDK.
>
> On 11.01.2018 13:13, Alex Sharaz wrote:
> > Thats what is  confusing, its the QuoVadis root CA which is one we use
> on a whole batch of servers and my osx machine validates those certs just
> fine. ... and I can see them ( root and intermediate)  in the system root
> keystore... but certainly if I remove it from the mobileconfig file I don't
> connect ,if I put it in there I do
> > A
> >
> > On 11 January 2018 at 12:01, Noel Kuntze  ml@thermi.consulting  consulting>> wrote:
> >
> > Hi,
> >
> > You only need to install a root certificate, if the issuer of your
> server certificate or its root certificate are not in the client's
> certificate store.
> > A client needs to be able to verify the server's certificate from
> the root to the server certificate. That includes CRLs and OCSP.
> >
> > That's PKI 101.
> >
> > Kind regards
> >
> > Noel
> >
> > On 10.01.2018 12:44, Alex Sharaz wrote:
> > > Hi,
> > > I've got a .mobileconfig file set up that will allow a macOS/iOS
> user to connect to my SSwan VPN server (5.6.1)
> > > In it I have a cert payload defined containing both the
> intermediate and root cert of the server certificate. This all works just
> fine
> > >
> > > However, our security people are objecting to the fact that I'm
> installing a root CA on the client device.
> > >
> > > Server cert has an intermediate cet between it and the root CA
> > >
> > > server config is
> > >
> > > conn it-services-ikev2
> > >   left=%any
> > >   leftauth=pubkey
> > >   leftcert=vpn.york.ac.uk.pem
> > >   leftid=@vpn.york.ac.uk  <
> http://vpn.york.ac.uk>
> > >   leftsendcert=always
> > >   leftsubnet=0.0.0.0/0,::/0  <
> http://0.0.0.0/0,::/0>
> > >   leftfirewall=yes
> > >   right=%any
> > >   rightauth=eap-radius
> > >   rightsendcert=never
> > >   rightgroups="Cserv"
> > >   eap_identity=%any
> > >   keyexchange=ikev2
> > >   rightsourceip=%itservices
> > >   fragmentation=yes
> > >   auto=add
> > >
> > >
> > > If I remove the root cert from the mobileconfig, connection fails.
> Should I be able to connect without the root CA in the payload?
> > >
> > > Rgds
> > > Alex
> > >
> >
> >
>
>

Re: [strongSwan] mobileconfig file - do i need to install a root CA

[Noel Kuntze]

Actually not. Just refer to the right file in your system's CA store. (e.g. 
/etc/ca-certificates/extracted/cadir/bla.pem).
Or play around with symlinking /etc/ipsec.d/cacerts or a subdirectory of it to 
your system's CA store.

Kind regards

Noel

On 11.01.2018 13:29, Giuseppe De Marco wrote:
> You can even use charon-cmd this way:
> 
> charon-cmd --host SERVER_HOSTNAME --profile ikev2-eap --identity LOGIN --cert 
> /PATH/TO/ca.crt
> 
> Using a valid CA lets Windows10 and MacOSX clients run without CA.crt, with 
> GNU/Linux we have to have ca.crt instead
> 
> 2018-01-11 13:17 GMT+01:00 Noel Kuntze 
>  >:
> 
> Put the root CA and the intermediate CAs into /etc/ipsec.d/cacerts, then 
> run `ipsec stroke rereadcacerts` and then retry.
> If that does not help, check the logs of iOS. You can get access to them 
> via Apple's SDK.
> 
> On 11.01.2018 13:13, Alex Sharaz wrote:
> > Thats what is  confusing, its the QuoVadis root CA which is one we use 
> on a whole batch of servers and my osx machine validates those certs just 
> fine. ... and I can see them ( root and intermediate)  in the system root 
> keystore... but certainly if I remove it from the mobileconfig file I don't 
> connect ,if I put it in there I do
> > A
> >
> > On 11 January 2018 at 12:01, Noel Kuntze 
>   >> wrote:
> >
> >     Hi,
> >
> >     You only need to install a root certificate, if the issuer of your 
> server certificate or its root certificate are not in the client's 
> certificate store.
> >     A client needs to be able to verify the server's certificate from 
> the root to the server certificate. That includes CRLs and OCSP.
> >
> >     That's PKI 101.
> >
> >     Kind regards
> >
> >     Noel
> >
> >     On 10.01.2018 12:44, Alex Sharaz wrote:
> >     > Hi,
> >     > I've got a .mobileconfig file set up that will allow a macOS/iOS 
> user to connect to my SSwan VPN server (5.6.1)
> >     > In it I have a cert payload defined containing both the 
> intermediate and root cert of the server certificate. This all works just fine
> >     >
> >     > However, our security people are objecting to the fact that I'm 
> installing a root CA on the client device.
> >     >
> >     > Server cert has an intermediate cet between it and the root CA
> >     >
> >     > server config is
> >     >
> >     > conn it-services-ikev2
> >     >   left=%any
> >     >   leftauth=pubkey
> >     >   leftcert=vpn.york.ac.uk.pem
> >     >   leftid=@vpn.york.ac.uk  
>  
> >     >   leftsendcert=always
> >     >   leftsubnet=0.0.0.0/0,::/0  
>  
> >     >   leftfirewall=yes
> >     >   right=%any
> >     >   rightauth=eap-radius
> >     >   rightsendcert=never
> >     >   rightgroups="Cserv"
> >     >   eap_identity=%any
> >     >   keyexchange=ikev2
> >     >   rightsourceip=%itservices
> >     >   fragmentation=yes
> >     >   auto=add
> >     >
> >     >
> >     > If I remove the root cert from the mobileconfig, connection 
> fails. Should I be able to connect without the root CA in the payload?
> >     >
> >     > Rgds
> >     > Alex
> >     >
> >
> >
> 
> 



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] checkpoint interoperability problem

[Noel Kuntze]

Hi,

That's weird behaviour that I've seen with checkpoints, too. I think the right 
solution is to stop the checkpoint from initiating main mode on its own.

Kind regards

Noel

On 05.01.2018 16:59, Marco Berizzi wrote:
> Hello everyone,
>
> I have a very nasty problem with an ipsec tunnel between
> strongswan 5.6.1 and a customer ipsec gateway (checkpoint).
>
> This is my ipsec.conf tunnel configuration:
>
> config setup
> # strictcrlpolicy=yes
> # uniqueids = no
>
> conn %default
> keyingtries=%forever
> #left=%defaultroute
> keyexchange = ikev1
>
> conn customer-10.0.16.0
> left=205.223.229.254
> right=213.255.45.11
> leftsubnet=192.168.121.0/28
> rightsubnet=10.0.16.0/21
> authby=secret
> auto=route
> ike=aes256-sha1-modp2048
> esp=aes256-sha1-modp2048
> compress=no
> leftid=205.223.229.254
> keyingtries=%forever
> keylife=1h
> ikelifetime=1h
>
> When I run 'ipsec up customer-10.0.16.0' everything is in
> good shape: main mode and quick mode are established.
>
> The problem happens after few hours (when there is no traffic
> from/to this ipsec tunnel).
> If I try to ping a customer system, strongswan is trying to
> do a quick mode to the customer peer, but the checkpoint start
> the main mode and the quick mode is not established anymore
> by strongswan.
>
> 16:02:36 10[KNL] creating acquire job for policy 192.168.121.14/32[icmp/8] 
> === 10.0.20.16/32[icmp/8] with reqid {239} 
> 16:02:36 10[ENC] generating QUICK_MODE request 1914820055 [ HASH SA No KE ID 
> ID ] 
> 16:02:36 10[NET] sending packet: from 205.223.229.254[500] to 
> 213.255.45.11[500] (444 bytes) 
> 16:02:36 11[NET] received packet: from 213.255.45.11[500] to 
> 205.223.229.254[500] (152 bytes) 
> 16:02:36 11[ENC] parsed ID_PROT request 0 [ SA V V ] 
> 16:02:36 11[ENC] received unknown vendor ID: 
> f4:ed:19:e0:c1:14:eb:51:6f:aa:ac:0e:e3:7d:af:28:07:b4:38:1f:00:00:00:01:00:00:13:8d:5a:4f:93:8b:00:00:00:00:18:28:00:00
>  
> 16:02:36 11[IKE] received FRAGMENTATION vendor ID 
> 16:02:36 11[IKE] 213.255.45.11 is initiating a Main Mode IKE_SA 
> 16:02:36 11[ENC] generating ID_PROT response 0 [ SA V V V ] 
> 16:02:36 11[NET] sending packet: from 205.223.229.254[500] to 
> 213.255.45.11[500] (144 bytes) 
> 16:02:36 09[NET] received packet: from 213.255.45.11[500] to 
> 205.223.229.254[500] (312 bytes) 
> 16:02:36 09[ENC] parsed ID_PROT request 0 [ KE No ] 
> 16:02:36 09[ENC] generating ID_PROT response 0 [ KE No ] 
> 16:02:36 09[NET] sending packet: from 205.223.229.254[500] to 
> 213.255.45.11[500] (324 bytes) 
> 16:02:36 05[NET] received packet: from 213.255.45.11[500] to 
> 205.223.229.254[500] (76 bytes) 
> 16:02:36 05[ENC] parsed ID_PROT request 0 [ ID HASH ] 
> 16:02:36 05[CFG] looking for pre-shared key peer configs matching 
> 205.223.229.254...213.255.45.11[213.255.45.11] 
> 16:02:36 05[CFG] selected peer config "customer-10.0.16.0" 
> 16:02:36 05[IKE] IKE_SA customer-10.0.16.0[802] established between 
> 205.223.229.254[205.223.229.254]...213.255.45.11[213.255.45.11] 
> 16:02:36 05[IKE] scheduling reauthentication in 2723s 
> 16:02:36 05[IKE] maximum IKE_SA lifetime 3263s 
> 16:02:36 05[ENC] generating ID_PROT response 0 [ ID HASH ] 
> 16:02:36 05[NET] sending packet: from 205.223.229.254[500] to 
> 213.255.45.11[500] (76 bytes) 
> 16:02:36 07[NET] received packet: from 213.255.45.11[500] to 
> 205.223.229.254[500] (92 bytes) 
> 16:02:36 07[ENC] parsed INFORMATIONAL_V1 request 3913147254 [ HASH D ] 
> 16:02:36 07[IKE] received DELETE for different IKE_SA, ignored 
> 16:02:40 04[IKE] sending retransmit 1 of request message ID 1914820055, seq 4 
> 16:02:40 04[NET] sending packet: from 205.223.229.254[500] to 
> 213.255.45.11[500] (444 bytes) 
> 16:02:46 13[IKE] deleting IKE_SA customer-10.0.16.0[795] between 
> 205.223.229.254[205.223.229.254]...213.255.45.11[213.255.45.11] 
> 16:02:46 13[IKE] sending DELETE for IKE_SA customer-10.0.16.0[795] 
> 16:02:46 13[ENC] generating INFORMATIONAL_V1 request 216163641 [ HASH D ] 
> 16:02:46 13[NET] sending packet: from 205.223.229.254[500] to 
> 213.255.45.11[500] (92 bytes) 
>
> It there any configuration option to tweak on my strongswan
> side to fix this problem?
>
> I have also found article sk118536 from checkpoint, but I'm
> running IKEv1 and not IKEv2:
>
> Symptoms
>
> VPN Site To Site with StrongSwan (mobile router using Linux with IPSec 
> implementation) fails.
> Unstable VPN connection between the VPN peers.
> Security Gateway not able to create new keys with StrongSwan. 
>
> Cause
>
> There is a known issue with Strongswan that it only stores (and uses) keys 
> that are re-keys of existing keys.
>
> There are even scenarios when Strongswan peer itself starts a new Phase 2 
> exchange but never stores the exchanged keys because they are not re-keys of 
> existing key and then we are not able to decrypt the traffic encrypted with 
> t

Re: [strongSwan] mobileconfig file - do i need to install a root CA

[Giuseppe De Marco]

You can even use charon-cmd this way:

charon-cmd --host SERVER_HOSTNAME --profile ikev2-eap --identity LOGIN
--cert /PATH/TO/ca.crt

Using a valid CA lets Windows10 and MacOSX clients run without CA.crt, with
GNU/Linux we have to have ca.crt instead

2018-01-11 13:17 GMT+01:00 Noel Kuntze <
noel.kuntze+strongswan-users-ml@thermi.consulting>:

> Put the root CA and the intermediate CAs into /etc/ipsec.d/cacerts, then
> run `ipsec stroke rereadcacerts` and then retry.
> If that does not help, check the logs of iOS. You can get access to them
> via Apple's SDK.
>
> On 11.01.2018 13:13, Alex Sharaz wrote:
> > Thats what is  confusing, its the QuoVadis root CA which is one we use
> on a whole batch of servers and my osx machine validates those certs just
> fine. ... and I can see them ( root and intermediate)  in the system root
> keystore... but certainly if I remove it from the mobileconfig file I don't
> connect ,if I put it in there I do
> > A
> >
> > On 11 January 2018 at 12:01, Noel Kuntze  ml@thermi.consulting  consulting>> wrote:
> >
> > Hi,
> >
> > You only need to install a root certificate, if the issuer of your
> server certificate or its root certificate are not in the client's
> certificate store.
> > A client needs to be able to verify the server's certificate from
> the root to the server certificate. That includes CRLs and OCSP.
> >
> > That's PKI 101.
> >
> > Kind regards
> >
> > Noel
> >
> > On 10.01.2018 12:44, Alex Sharaz wrote:
> > > Hi,
> > > I've got a .mobileconfig file set up that will allow a macOS/iOS
> user to connect to my SSwan VPN server (5.6.1)
> > > In it I have a cert payload defined containing both the
> intermediate and root cert of the server certificate. This all works just
> fine
> > >
> > > However, our security people are objecting to the fact that I'm
> installing a root CA on the client device.
> > >
> > > Server cert has an intermediate cet between it and the root CA
> > >
> > > server config is
> > >
> > > conn it-services-ikev2
> > >   left=%any
> > >   leftauth=pubkey
> > >   leftcert=vpn.york.ac.uk.pem
> > >   leftid=@vpn.york.ac.uk  <
> http://vpn.york.ac.uk>
> > >   leftsendcert=always
> > >   leftsubnet=0.0.0.0/0,::/0  <
> http://0.0.0.0/0,::/0>
> > >   leftfirewall=yes
> > >   right=%any
> > >   rightauth=eap-radius
> > >   rightsendcert=never
> > >   rightgroups="Cserv"
> > >   eap_identity=%any
> > >   keyexchange=ikev2
> > >   rightsourceip=%itservices
> > >   fragmentation=yes
> > >   auto=add
> > >
> > >
> > > If I remove the root cert from the mobileconfig, connection fails.
> Should I be able to connect without the root CA in the payload?
> > >
> > > Rgds
> > > Alex
> > >
> >
> >
>
>

Re: [strongSwan] Dual IPSEC SA after re-auth

[Noel Kuntze]

Hi,

Use the site-to-site config for IKEv1 and two subnets from the UsableExamples 
page on the wiki.

Kind regards

Noel

On 04.01.2018 17:53, Loic Chabert wrote:
> Hello Strongswan list,
>
> I have a trouble with an IPSEC site-to-site VPN from a Cisco ASA and 
> strongswan version 5.5.3, Linux 3.10.0-327.10.1.el7.x86_64.
>
> With Strongwan, i want to send two subnet: 172.16.5.0/24 
>  and 192.168.1.0/24 .
> When i start strongswan, no error, all ping pass throught ipsec tunnel and no 
> problem.
> After 7h (probably after a re-auth), two tunnels are inserted for the same 
> subnet. The other subnet continue to work as expected. Only one "crash". One 
> ping over two has been drop.
>
> Please find below output command of "statusall":
>
> /#strongswan statusall
> Status of IKE charon daemon (strongSwan 5.5.3, Linux 
> 3.10.0-327.10.1.el7.x86_64, x86_64):
>   uptime: 26 hours, since Jan 03 14:53:30 2018
>   malloc: sbrk 1622016, mmap 0, used 529568, free 1092448
>   worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, 
> scheduled: 8
>   loaded plugins: charon aes des rc2 sha2 sha1 md4 md5 random nonce x509 
> revocation constraints acert pubkey pkcs1 pkcs8 pkcs12 pgp dnskey sshkey pem 
> openssl gcrypt fips-prf gmp curve25519 xcbc cmac hmac ctr ccm gcm curl attr 
> kernel-netlink resolve socket-default farp stroke vici updown eap-identity 
> eap-md5 eap-gtc eap-mschapv2 eap-tls eap-ttls eap-peap xauth-generic 
> xauth-eap xauth-pam xauth-noauth dhcp unity
> Listening IP addresses:
>   185.119.XXX.XXX
>   172.16.0.0
>   2a06:8bc0:XXX
>   10.8.0.1
> Connections:
>     conn-1:  ///185.119.XXX.YYY/...46.31.ZZ.ZZ  IKEv1
>     ///conn/-1:   local:  [185.119.XXX.YYY/./] uses pre-shared key 
> authentication
>     ///conn/-1:   remote: [///46.31.ZZ.ZZ/] uses pre-shared key authentication
>     ///conn/-1:   child:  192.168.1.0/24  === 
> 10.2.1.192/29  TUNNEL
>     ///conn/-2:   child:  172.16.5.0/24  === 
> 10.2.1.192/29  TUNNEL
> Security Associations (1 up, 0 connecting):
>     ///conn/-1[7]: ESTABLISHED 2 hours ago, 
> 185.119.XXX.YYY/./[185.119.XXX.YYY/./]...///46.31.ZZ.ZZ/[///46.31.ZZ.ZZ/]
>     ///conn/-1[7]: IKEv1 SPIs: f8490bafd768b806_i* 86c5c1b6cb09c905_r, 
> pre-shared key reauthentication in 5 hours
>     ///conn/-1[7]: IKE proposal: 
> AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536
>     ///conn/-2{817}:  INSTALLED, TUNNEL, reqid 71, ESP SPIs: c70f39e7_i 
> 474d86cc_o
>     ///conn/-2{817}:  AES_CBC_256/HMAC_SHA1_96/MODP_1024, 65021 bytes_i (1413 
> pkts, 27s ago), 1535741 bytes_o (3046 pkts, 27s ago), rekeying in 6 hours
>     ///conn/-2{817}:   172.16.5.0/24  === 10.2.1.192/29 
> 
> *    *//*/conn/-1{867}:  INSTALLED, TUNNEL, reqid 69, ESP SPIs: cf6a0fee_i 
> 4d77c585_o
>     *//*/conn/-1{867}:  AES_CBC_256/HMAC_SHA1_96/MODP_1024, 0 bytes_i, 0 
> bytes_o, rekeying in 6 hours
>     *//*/conn/-1{867}:   192.168.1.0/24  === 
> 10.2.1.192/29 
>     *//*/conn/-1{869}:  INSTALLED, TUNNEL, reqid 69, ESP SPIs: c3e3a651_i 
> 7d5fc4f2_o
>     *//*/conn/-1{869}:  AES_CBC_256/HMAC_SHA1_96/MODP_1024, 4441746 bytes_i 
> (3181 pkts, 419s ago), 54984 bytes_o (1373 pkts, 419s ago), rekeying in 6 
> hours
>     *//*/conn/-1{869}:   192.168.1.0/24  === 
> 10.2.1.192/29 *
>
> /
> /
> /
> Here my configuration:
>
> /# ipsec.conf - strongSwan IPsec configuration file
>
> # basic configuration
>
> config setup
>     # strictcrlpolicy=yes
>     charondebug="cfg 2, chd 1, dmn 1, ike 1, knl 1, net 1"
>     # uniqueids = no
>
> # Add connections here.
>
> # Sample VPN connections
> conn conn--1
>     auto=start
>     rightsubnet=192.168.1.0/24 
>     authby=secret
>     compress=no
>     closeaction=restart
>     mobike=no
>     keyexchange=ikev1
>     keyingtries=1
>     rekeymargin=3m
>     ike=aes256-sha-modp1536
>     esp=aes256-sha-modp1024
>     ikelifetime=28800s
>     lifetime=28800s
>     left=46.31.ZZ.ZZ
>     right=185.119.XXX.YYY
>     leftsubnet=10.2.1.192/29 
>     leftid=46.31.ZZ.ZZ
>     rightid=185.119.XXX.YYY
>
> conn conn-2
>     auto=start
>     rightsubnet=172.16.5.0/24 
>     authby=secret
>     compress=no
>     closeaction=restart
>     mobike=no
>     rekeymargin=3m
>     keyexchange=ikev1
>     ike=aes256-sha-modp1536
>     esp=aes256-sha-modp1024
>     ikelifetime=28800s
>     keyingtries=1
>     lifetime=28800s
>     left=46.31.ZZ.ZZ
>     right=185.119.XXX.YYY
>     leftsubnet=10.2.1.192/29 
>     leftid=46.31.ZZ.ZZ/
> /
> /
> /
> /
> If i set rightsubnet, separared by a comma, only one subnet over two is UP.
> I have disable cisco_unity plugin (same behaviour if this plugin is enabled).
>
> Do you have an

Re: [strongSwan] How to set some strongswan parameters for all connections at once?

[Noel Kuntze]

CentOS also has `ipsec`. They just renamed it to `strongswan`, so it does not 
conflict with libreswan's `ipsec` tool for controling their pluto daemon.

You can use the file inclusion mechanism to load text from other files into 
parts of the configuration. The man page mentions how to do that.

Be aware that you can not change conns based on the eap_identity.

Kind regards

Noel

On 11.01.2018 12:24, Marian Kechlibar wrote:
> OK, so I set up an experimental VPN and started playing with it, as not
> to break the production VPN.
>
> CentOS uses swanctl as a lightweight controller, so ipsec.conf is not
> really loaded.
>
> I was able to set up DPD, Proposals etc. on a user-by-user basis, but
> not globally.
>
> Is there any way how to set something for all connections at once when
> using swanctl?
>
> Best regards
>
> Marian Kechlibar
> Prague, CZ
>
> Dne 11.1.2018 v 9:54 Marian Kechlibar napsal(a):
>> Hi all,
>>
>> I would like to ask a question with regard to StrongSwan server
>> configuration.
>>
>> We are running a VPN server based on StrongSwan 5.5.3 on CentOS 7. The
>> settings are as follows:
>>
>> * ipsec.conf is completely empty, except for comments (the default state
>> of the file after a fresh installation),
>> * strongswan.conf includes all the charon confs, which are left in the
>> default state as well,
>> * swanctl.conf includes config files and pool files of all the
>> individual users, where local_addrs, local_sa, remote_sa, children etc.
>> is determined.
>>
>> Now I would like to set up the following parameters of the system:
>>
>> * Dead Peer Detection
>> * Cipher Suites
>> * Enforcement of IKEv2 only
>> * Lifetime
>>
>> And I would like for those parameters to apply to all the users of the
>> system at once.
>>
>> How do I do it? Do I add a conn block into the ipsec.conf?
>>
>> And how about making exceptions for individual users? Let us say that I
>> do not want Dead Peer Detection for user X. Can I turn it off in the
>> appropriate user's config?
>>
>> I studied the documentation online, but it is not entirely clear to me
>> and I am afraid of ruining a setup of a functional VPN by trial and error.
>>
>> Many thanks in advance.
>>
>> Marian Kechlibar
>> Prague, CZ
>>



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] OpenWRT. IPSec server

[Noel Kuntze]

Hi,

Create and provide logs. List all information in the format and with the 
commands as described on the HelpRequests page.

Kind regards

Noel

On 06.01.2018 07:15, Sujoy wrote:
> Hi All,
> 
> We are able to connect to StrongSwan IPSec using LAN IP. But in the same 
> system which is having Public IP with NAT trying to connect it says one 
> connecting only. Connection could not establish.
> 
> Someone can please help me in solving this.
> 
> 
> Thanks & Regards
> 
> 
> On Thursday 04 January 2018 07:16 PM, Noel Kuntze wrote:
>> Not on openwrt. But you need plaintext or AD like passwords in LDAP. 
>> Otherwise you can't auth with mschap(v2).
>>
>> On 04.01.2018 14:38, Giuseppe De Marco wrote:
>>> Yes Noel and thank you, my question is:
>>> Is there any experiences about running strongswan in openwrt as ikev2 
>>> server with mschap,radius,ldap auth backend?
>>>
>>> 2018-01-04 14:17 GMT+01:00 Noel Kuntze 
>>> >> >:
>>>
>>> Hi,
>>>
>>> `ipsec` is just a command line tool. It's not a daemon (or generally a 
>>> service).
>>> Are there any open questions?
>>>
>>> Kind regards
>>>
>>> Noel
>>>
>>> On 04.01.2018 14:14, Giuseppe De Marco wrote:
>>> > Hi and thank you Noel,
>>> > I meant to run ipsec and charon in the embedded openwrt router, I use 
>>> dpd as well
>>> >
>>> >   # dead-peer detection to clear any "dangling" connections in case 
>>> the client unexpectedly disconnects
>>> >   dpdaction=clear
>>> >   # If the tunnel has no traffic for this long (default 30 secs), 
>>> Charon will send a dead peer detection packet. The value 0 means to not 
>>> send such packets, relying on ordinary traffic, which will occur at least 
>>> once an hour, which is the default rekeying lifetime.
>>> >   dpddelay=33s
>>> >   #  DPD Retries : 3
>>> >   dpdtimeout=300s
>>> >
>>> > Running strongswan in a 18-70$ openwrt router is very usefull in many 
>>> way
>>>
>>>
> 



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] mobileconfig file - do i need to install a root CA

[Noel Kuntze]

Put the root CA and the intermediate CAs into /etc/ipsec.d/cacerts, then run 
`ipsec stroke rereadcacerts` and then retry.
If that does not help, check the logs of iOS. You can get access to them via 
Apple's SDK.

On 11.01.2018 13:13, Alex Sharaz wrote:
> Thats what is  confusing, its the QuoVadis root CA which is one we use on a 
> whole batch of servers and my osx machine validates those certs just fine. 
> ... and I can see them ( root and intermediate)  in the system root 
> keystore... but certainly if I remove it from the mobileconfig file I don't 
> connect ,if I put it in there I do
> A
> 
> On 11 January 2018 at 12:01, Noel Kuntze 
>  > wrote:
> 
> Hi,
> 
> You only need to install a root certificate, if the issuer of your server 
> certificate or its root certificate are not in the client's certificate store.
> A client needs to be able to verify the server's certificate from the 
> root to the server certificate. That includes CRLs and OCSP.
> 
> That's PKI 101.
> 
> Kind regards
> 
> Noel
> 
> On 10.01.2018 12:44, Alex Sharaz wrote:
> > Hi,
> > I've got a .mobileconfig file set up that will allow a macOS/iOS user 
> to connect to my SSwan VPN server (5.6.1)
> > In it I have a cert payload defined containing both the intermediate 
> and root cert of the server certificate. This all works just fine
> >
> > However, our security people are objecting to the fact that I'm 
> installing a root CA on the client device.
> >
> > Server cert has an intermediate cet between it and the root CA
> >
> > server config is
> >
> > conn it-services-ikev2
> >   left=%any
> >   leftauth=pubkey
> >   leftcert=vpn.york.ac.uk.pem
> >   leftid=@vpn.york.ac.uk  
> >   leftsendcert=always
> >   leftsubnet=0.0.0.0/0,::/0  
> 
> >   leftfirewall=yes
> >   right=%any
> >   rightauth=eap-radius
> >   rightsendcert=never
> >   rightgroups="Cserv"
> >   eap_identity=%any
> >   keyexchange=ikev2
> >   rightsourceip=%itservices
> >   fragmentation=yes
> >   auto=add
> >
> >
> > If I remove the root cert from the mobileconfig, connection fails. 
> Should I be able to connect without the root CA in the payload?
> >
> > Rgds
> > Alex
> >
> 
> 



signature.asc
Description: OpenPGP digital signature

[strongSwan] Fwd: CRL validation failing

[Matthew Winnett]

I am running 5.6.1 and trying to establish a site to site vlan to a F5
bigip using ikev2 and certificates. The tunnel works ok with psk but when
using certificates I get the following in the log:

11[CFG] checking certificate status of "C=gb, ST=anglesey, L=benllech,
O=f5, OU=es, CN=moriarty_k-server_1.winnett.gb"
11[CFG]   fetching crl from
'file:///usr/local/etc/swanctl/x509crl/ca-cacert.crl'
...
11[CFG] issuer of fetched CRL 'C=gb, ST=anglesey, L=benllech, O=f5, OU=es,
CN=moriarty_k-Root_CA.winnett.gb' does not match CRL issuer
'0e:db:41:37:bb:8c:b8:1c:de:9b:35:31:de:4d:6b:67:5a:02:57:22'

I found a previous thread indicating that the "CRL must contain an
authorityKeyIdentifier equal to the subjectKeyIdentifier of the CRL
issuer", which I now have ...

$ openssl crl -in ca-cacert.crl -noout -text | grep -E "CRL extensions:" -A
4
CRL extensions:
X509v3 Authority Key Identifier:
keyid:0E:DB:41:37:BB:8C:B8:1C:DE:9B:35:31:DE:4D:6B:67:5A:02:
57:22
DirName:/C=gb/ST=anglesey/L=benllech/O=f5/OU=es/CN=moriart
y_k-Root_CA.winnett.gb
serial:5A:4D:03:09

$ openssl x509 -in ca-cacert.pem -text | grep -E "X509v3 extensions:" -A 6
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Key Identifier:
0E:DB:41:37:BB:8C:B8:1C:DE:9B:35:31:DE:4D:6B:67:5A:02:57:22
X509v3 Authority Key Identifier:
keyid:0E:DB:41:37:BB:8C:B8:1C:DE:9B:35:31:DE:4D:6B:67:5A:02:
57:22

Any idea what is wrong ?

Many thanks ...

Re: [strongSwan] Question related to ESP_TFC_PADDING_NOT_SUPPORTED

[Noel Kuntze]

TFC padding is only used if you set "tfc=$value" in ipsec.conf.
By default it is disabled. TFC increases the packet size of ESP packets to be 
at least $value. It significantly degrades performance,
because of the humongous overhead.
ESP_TFC_PADDING_NOT_SUPPORTED means that the other peer does not support TFC. 
The other peer sending it does NOT have anything to do with any setting on your 
side.

Kind regards

Noel

On 10.01.2018 17:40, rajeev nohria wrote:
> Let me ask question again..
> 
> On local I did not configure TFC and by default it should be disabled.  From 
> remote I am receiving following message 
> 
> 12[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
> 
> What exactly it mean  "not using ESPv3 TFC padding"  does it means  local is 
> also not using TFC padding? 
> 
> Why would local would send msg with TFC when TFC disabled by default. I have 
> tried tfc_padding = 0 in configuration and get the same message.  Just trying 
> to understand..
> 
> 
> 
> 
> 
> On Wed, Jan 10, 2018 at 10:51 AM, rajeev nohria  > wrote:
> 
> I am trying to understand if ESP_TFC_PADDING_NOT_SUPPORTED means Local is 
> using the TFC.
> 
> I am getting ESP_TFC_PADDING_NOT_SUPPORTED msg from remote. Is that means 
> local is using the TFC. 
> On local I have to configured tfc_padding and by default it is disabled.  
> If by default it is disabled why local side is sending packet with TFC.
> 
> 
> 
> 
> 
> 12[CFG] certificate status is not available
> 
> 12[CFG]   reached self-signed root ca with a path length of 1
> 
> 12[IKE] authentication of 'C=US, O=CableLabs, CN=00:01:5c:96:16:00' with 
> RSA signature successful
> 
> 12[IKE] IKE_SA rpdfc00:cada:c406::200[1] established between 
> fc00:cada:c406:607::1001[C=US, O=ARRIS, OU=LOWELL, 
> CN=00:33:5f:ab:8c:9e]...fc00:cada:c406::200[C=US, O=CableLabs, 
> CN=00:01:5c:96:16:00]
> 
> 12[IKE] scheduling rekeying in 13218s
> 
> 12[IKE] maximum IKE_SA lifetime 14658s
> 
> 12[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC 
> padding
> 
> [  274.326216] alg: No test for authenc(hmac(sha256),ecb(cipher_null)) 
> (authenc(hmac(sha256-generic),ecb-cipher_null))
> 
> 12[IKE] CHILD_SA gcpfc00:cada:c406::200{3} established with SPIs 
> c2b4f3ce_i 2bcba3d9_o and TS fc00:cada:c406:607::1001/128[tcp] === 
> fc00:cada:c406::200/128[tcp/8190]
> 
> 
> 
> Thanks,
> 
> Rajeev
> 
> 



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] mobileconfig file - do i need to install a root CA

[Alex Sharaz]

Thats what is  confusing, its the QuoVadis root CA which is one we use on a
whole batch of servers and my osx machine validates those certs just fine.
... and I can see them ( root and intermediate)  in the system root
keystore... but certainly if I remove it from the mobileconfig file I don't
connect ,if I put it in there I do
A

On 11 January 2018 at 12:01, Noel Kuntze <
noel.kuntze+strongswan-users-ml@thermi.consulting> wrote:

> Hi,
>
> You only need to install a root certificate, if the issuer of your server
> certificate or its root certificate are not in the client's certificate
> store.
> A client needs to be able to verify the server's certificate from the root
> to the server certificate. That includes CRLs and OCSP.
>
> That's PKI 101.
>
> Kind regards
>
> Noel
>
> On 10.01.2018 12:44, Alex Sharaz wrote:
> > Hi,
> > I've got a .mobileconfig file set up that will allow a macOS/iOS user to
> connect to my SSwan VPN server (5.6.1)
> > In it I have a cert payload defined containing both the intermediate and
> root cert of the server certificate. This all works just fine
> >
> > However, our security people are objecting to the fact that I'm
> installing a root CA on the client device.
> >
> > Server cert has an intermediate cet between it and the root CA
> >
> > server config is
> >
> > conn it-services-ikev2
> >   left=%any
> >   leftauth=pubkey
> >   leftcert=vpn.york.ac.uk.pem
> >   leftid=@vpn.york.ac.uk 
> >   leftsendcert=always
> >   leftsubnet=0.0.0.0/0,::/0 
> >   leftfirewall=yes
> >   right=%any
> >   rightauth=eap-radius
> >   rightsendcert=never
> >   rightgroups="Cserv"
> >   eap_identity=%any
> >   keyexchange=ikev2
> >   rightsourceip=%itservices
> >   fragmentation=yes
> >   auto=add
> >
> >
> > If I remove the root cert from the mobileconfig, connection fails.
> Should I be able to connect without the root CA in the payload?
> >
> > Rgds
> > Alex
> >
>
>

Re: [strongSwan] Issue with IKE_SA rekey towards Cisco

[Noel Kuntze]

Hi,

I'm absolutely baffled why you choose a weak PSK-Xauth authentication scheme 
with aggressive mode.
You're basically doing everything wrong. At least use Pubkey-Xauth with hybrid 
mode authentication. That way,
the clients don't need a certificate and an attacker listening in on the KEX 
can not use an offline dictionary attack on the PSK
and other client's can't perform MITM attacks.

And please use a modern cipher suite. It's very cheap and your auditors will 
thank you. It also looks better and is more professionally.

The problem is with the responder. It doesn't answer and deletes reauthed 
IKE_SAs. Read or provide its logs.

> Thu, 2018-01-04 21:22 06[ENC]  generating TRANSACTION request 
> 238578509 [ HASH CPRQ(ADDR DNS U_SPLITINC U_LOCALLAN) ]
> Thu, 2018-01-04 21:22 06[NET]  sending packet: from 
> 192.168.10.23[4500] to [4500] (92 bytes)
> Thu, 2018-01-04 21:22 02[IKE]  sending retransmit 1 of request 
> message ID 238578509, seq 3

> Thu, 2018-01-04 21:27 13[NET]  received packet: from  IP>[4500] to 192.168.10.23[4500] (92 bytes)
> Thu, 2018-01-04 21:27 13[ENC]  parsed INFORMATIONAL_V1 request 
> 3161543286 [ HASH D ]
> Thu, 2018-01-04 21:27 13[IKE]  received DELETE for IKE_SA home[4]

Please keep attaching the logs to your emails.

Kind regards

Noel

On 10.01.2018 16:44, Henrik Juul Pedersen wrote:
> Hi StrongSwan community,
>
> I'm implementing a VPN based on StrongSwan for the client side (an
> embedded linux board) for a customer. Currently we are testing against
> a Cisco ASA5506.
>
> Our requirements:
>  - Clients must be able to uniquely identify themselves
>  - Clients has unique passwords generated from secrets known in both ends.
>  - Clients must get IP and DNS information from the concentrator
>  - Clients must function behind NAT
>
> We have implemented it with IKEv1 and XAUTH, we use a secret shared
> between all clients for the first stage IKE_SA, and we use a generated
> password and a unique username for XAUTH.
>
> The clients connect and are able to rekey CHILD_SA on expiry every
> hour, but when reauthenticating IKE_SA after 4 hours, some
> miscommunication result in loss of connection.
>
> I can't disclose the customer, or their application, but I've supplied
> sanitized configuration- and log-files, which should show the setup
> and the runtime results. If I've removed some important context please
> let me know, and I'll try and present the needed information.
>
> We have enabled 'cisco_unity' in charon.conf, and for testing we have
> enabled 'i_dont_care_about_security_and_use_aggressive_mode_psk', so
> this shouldn't be the thing stopping us.
>
> We have tested the setup with a Shrew Soft client on a Windows
> machine, which seems to be able to keep the connection alive
> indefinitely (possibly with minor interruptions - we haven't been able
> to test with a long-running connection on Windows).
>
> These logs are made from a Linux PC with newest available StrongSwan client:
>  - IKE charon daemon (strongSwan 5.6.1, Linux 4.14.10-1-ARCH, x86_64)
>
> We are not using swanctl as that isn't the default for our embedded
> target. We control StrongSwan using the ipsec script.
>
> I've tried to follow
> "https://wiki.strongswan.org/projects/strongswan/wiki/HelpRequests";,
> and have supplied full (sanitized) log files as MIME attachments.
> Please let me know if you prefer them externally hosted, or supplied
> inline in future communication.
>
> I hope some of you have an idea of what the issue might be. I'm sure
> we've just made some misconfiguration.
>
> Thank you in advance,
> Best regards
> Henrik Juul Pedersen
> LIAB ApS



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] Reconnect failed with android phone

[Noel Kuntze]

What's happening in between those two lines?

On 10.01.2018 15:34, JWD wrote:
> Jan 10 22:22:37 04[NET]  sending packet: from 172.31.2.1[4500] 
> to 117.100.110.176[4500] (108 bytes)
>  
> Jan 10 22:22:55 15[NET] <4> received packet: from 117.100.110.176[500] to 
> 172.31.2.1[500] (476 bytes)

Btw, switch to a better cipher suite.
> ike=aes256-sha1-modp1024,aes256-sha256-modp1024,3des-sha1-modp1024!
> esp=aes256-sha1,aes256-sha256,3des-sha1!

Kind regards

Noel


signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] mobileconfig file - do i need to install a root CA

[Noel Kuntze]

Hi,

You only need to install a root certificate, if the issuer of your server 
certificate or its root certificate are not in the client's certificate store.
A client needs to be able to verify the server's certificate from the root to 
the server certificate. That includes CRLs and OCSP.

That's PKI 101.

Kind regards

Noel

On 10.01.2018 12:44, Alex Sharaz wrote:
> Hi,
> I've got a .mobileconfig file set up that will allow a macOS/iOS user to 
> connect to my SSwan VPN server (5.6.1)
> In it I have a cert payload defined containing both the intermediate and root 
> cert of the server certificate. This all works just fine
>
> However, our security people are objecting to the fact that I'm installing a 
> root CA on the client device.
>
> Server cert has an intermediate cet between it and the root CA
>
> server config is
>
> conn it-services-ikev2
>   left=%any
>   leftauth=pubkey
>   leftcert=vpn.york.ac.uk.pem
>   leftid=@vpn.york.ac.uk 
>   leftsendcert=always
>   leftsubnet=0.0.0.0/0,::/0 
>   leftfirewall=yes
>   right=%any
>   rightauth=eap-radius
>   rightsendcert=never
>   rightgroups="Cserv"
>   eap_identity=%any
>   keyexchange=ikev2
>   rightsourceip=%itservices
>   fragmentation=yes
>   auto=add
>
>
> If I remove the root cert from the mobileconfig, connection fails. Should I 
> be able to connect without the root CA in the payload?
>
> Rgds
> Alex
>



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] roadwarrior ike/esp SA are not dropped after lifetime expiration

[Noel Kuntze]

AFAIK you can use `inactivity=$time`, but it only pertains the CHILD_SAs 
(unless charon.inactivity_close_ike is set to "yes"). DPD only pertains 
IKE_SAs. If an IKE_SA is deleted (and not rekeyed), its CHILD_SAs are deleted, 
too.
It probably works if you use both inactivity and set 
charon.inactivity_close_ike = yes in /etc/strongswan.d/charon.conf.

Kind regards

Noel

On 09.01.2018 14:36, Marco Berizzi wrote:
> Giuseppe De Marco 
> Ciao Marco,
>
>  Probably I'm wrong but I think that the Dead Peer Detection feature could be 
> helpfull for you
>
>   # dead-peer detection to clear any "dangling" connections in case the 
> client unexpectedly disconnects   dpdaction=clear   # If the tunnel has no 
> traffic for this long (default 30 secs), Charon will send a dead peer 
> detection packet. The value 0 means to not send such packets, relying on 
> ordinary traffic, which will occur at least once an hour, which is the 
> default rekeying lifetime.   dpddelay=33s   #  DPD Retries : 3   
> dpdtimeout=300s  
>
>
> Hi Giuseppe,
>
> thanks for the tips. Yes indeed dpd should do the trick. But I would like to 
> ask if the strongswan behaviour, (not dropping the IKE/IPSec SA after 
> timeout) is the expected one.
>
> Thanks



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] Multiple IKE SA between same pair of address

[Noel Kuntze]

Hi,

Set uniqueids = no in config setup.
Better, use swanctl.conf with swanctl. There, you can set it per conn and not 
globally.

Kind regards

Noel

On 06.01.2018 01:15, Jun Hu wrote:
> Hi,
> Does strongswan support multiple IKE SA (each with its own CHILD_SA) between 
> single pair of address?
> it seems strongswan only allow one IKE SA per pair of address
>
> I am using strongswan 5.5.0, inter-op with a IKEv2 client that I wrote (for 
> learning purpose) , my client is the tunnel initiator, when I only creates 
> one IKE SA (along with one CHILD_SA), everything is good;
> but when my client try to create 2nd CHILD_SA (using IKE_SA_INIT and IKE_AUTH 
> exchange, not rekey) using same addresses,the 2nd IKE and CHILD SA were 
> created successfully at the beginning, but after a few seconds, strongswan 
> send a delete msg to delete the 1st IKE_SA
>
> I also tried to set charon.reuse_ikesa to no, but same result
>
> I checked strongswan logs, it doesn't say why it deletes 1st IKE SA:
> root@vm-svr:/usr/local/etc# ipsec status
> Security Associations (2 up, 0 connecting):
>          l2l[2]: ESTABLISHED 9 seconds ago, 
> 10.10.10.1[10.10.10.1]...10.10.10.20[1.1.1.1]
>          l2l{2}:  INSTALLED, TUNNEL, reqid 2, ESP SPIs: c1aab5fc_i 3f174706_o
>          l2l{2}:   10.10.10.1/32  === 1.1.1.2/32 
> 
>          l2l[1]: ESTABLISHED 19 seconds ago, 
> 10.10.10.1[10.10.10.1]...10.10.10.20[1.1.1.1]
>          l2l{1}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: ca5a49fd_i 617a4971_o
>          l2l{1}:   10.10.10.1/32  === 1.1.1.1/32 
> 
> root@vm-svr:/usr/local/etc# ipsec status
> Security Associations (1 up, 0 connecting):
>          l2l[2]: ESTABLISHED 10 seconds ago, 
> 10.10.10.1[10.10.10.1]...10.10.10.20[1.1.1.1]
>          l2l{2}:  INSTALLED, TUNNEL, reqid 2, ESP SPIs: c1aab5fc_i 3f174706_o
>          l2l{2}:   10.10.10.1/32  === 1.1.1.2/32 
> 
>
>
>
> part of the log:
> .
> Jan  5 15:50:21 06[MGR]  checkout IKEv2 SA with SPIs 
> 2c79130e38a24598_i c530ad0d0f1a47f0_r
> Jan  5 15:50:21 06[MGR]  IKE_SA l2l[1] successfully checked out
> Jan  5 15:50:21 06[MGR]  checkin IKE_SA l2l[1]
> Jan  5 15:50:21 06[MGR]  checkin of IKE_SA successful
> Jan  5 15:50:21 06[IKE]  IKE_SA l2l[2] established between 
> 10.10.10.1[10.10.10.1]...10.10.10.20[1.1.1.1]
> Jan  5 15:50:21 06[IKE]  IKE_SA l2l[2] state change: CONNECTING => 
> ESTABLISHED
> Jan  5 15:50:21 06[IKE]  scheduling rekeying in 490s
> Jan  5 15:50:21 06[IKE]  maximum IKE_SA lifetime 500s
> Jan  5 15:50:21 06[KNL]  got SPI c1aab5fc
> Jan  5 15:50:21 06[KNL]  adding SAD entry with SPI c1aab5fc and reqid 
> {2}
> Jan  5 15:50:21 06[KNL]    using encryption algorithm AES_CBC with key 
> size 128
> Jan  5 15:50:21 06[KNL]    using integrity algorithm HMAC_SHA1_96 with 
> key size 160
> Jan  5 15:50:21 06[KNL]    using replay window of 32 packets
> Jan  5 15:50:21 06[KNL]  adding SAD entry with SPI 3f174706 and reqid 
> {2}
> Jan  5 15:50:21 06[KNL]    using encryption algorithm AES_CBC with key 
> size 128
> Jan  5 15:50:21 06[KNL]    using integrity algorithm HMAC_SHA1_96 with 
> key size 160
> Jan  5 15:50:21 06[KNL]    using replay window of 0 packets
> Jan  5 15:50:21 06[KNL]  adding policy 10.10.10.1/32 
>  === 1.1.1.2/32  out [priority 
> 383616, refcount 1]
> Jan  5 15:50:21 06[KNL]  adding policy 1.1.1.2/32  
> === 10.10.10.1/32  in [priority 383616, refcount 1]
> Jan  5 15:50:21 06[KNL]  adding policy 1.1.1.2/32  
> === 10.10.10.1/32  fwd [priority 383616, refcount 1]
> Jan  5 15:50:21 06[KNL]  adding policy 10.10.10.1/32 
>  === 1.1.1.2/32  fwd [priority 
> 383616, refcount 1]
> Jan  5 15:50:21 06[KNL]  policy 10.10.10.1/32  
> === 1.1.1.2/32  out already exists, increasing refcount
> Jan  5 15:50:21 06[KNL]  updating policy 10.10.10.1/32 
>  === 1.1.1.2/32  out [priority 
> 183616, refcount 2]
> Jan  5 15:50:21 06[KNL]  getting a local address in traffic selector 
> 10.10.10.1/32 
> Jan  5 15:50:21 06[KNL]  using host 10.10.10.1
> Jan  5 15:50:21 06[KNL]  getting iface name for index 4
> Jan  5 15:50:21 06[KNL]  using 10.10.10.20 as nexthop and eth2 as dev 
> to reach 10.10.10.20/32 
> Jan  5 15:50:21 06[KNL]  installing route: 1.1.1.2/32 
>  via 10.10.10.20 src 10.10.10.1 dev eth2
> Jan  5 15:50:21 06[KNL]  getting iface index for eth2
> Jan  5 15:50:21 06[KNL]  policy 1.1.1.2/32  === 
> 10.10.10.1/32  in already exists, increasing refcount
> Jan  5 15:50:21 06[KNL]  updating policy 1.1.1.2/32 
>  === 10.10.10.1/32  in [priority 
> 183616, refcount 2]

Re: [strongSwan] IPSec Tunnel Up, No Traffic Passed to End Destination

[Noel Kuntze]

Disable the source check in the VPC for the strongSwan server in the VPC.
Check if forwarding is enabled in sysctl globally for IPv4, too.
> sysctl net.ipv6.conf.all.forwarding=1
That is IPv6 only. You're tunneling IPv4 packets though.

BTW, your cipher suite sucks. use something better and use auto = route. Better 
yet, use a configuration from the UsableExamples page on the wiki.

GZ, you just leaked the keys of your SAs via the output of `ip xfrm state`.


The output of `iptables -L` is useless. Provide the output of `iptables-save` 
instead.
Generally, adhere to what the HelpRequests page says.

Kind regards

Noel

On 05.01.2018 19:09, Cruz Tovar wrote:
>
> Below is a network diagram of StrongSwan box configured in Amazon Web 
> Services with tunnel to a Cisco ASA. 
>
>  
>
> The tunnel between the StrongSwan box and the Cisco device are working 
> properly, phase 1 and phase 2 have completed.
>
>  
>
> The issue is that the traffic destined to the StrongSwan box should then be 
> passed to the 'Test Server' box (172.31.12.176) 
>
>  
>
> I am able to see the ICMP packets sent from the 192.168.20.0/24 network hit 
> the StrongSwan box, but this traffic is not passed along to the Test Server. 
>
>  
>
> I have enabled forward client traffic and included forward rules for traffic 
> sourced from the 192.168.20.0/24 subnet to be forwarded to 172.31.12.176.
>
>  
>
> Does someone have any insight into what I may have configured incorrectly?
>
>  
>
> |TEST SERVER (172.31.12.176)| == Eth1 172.31.12.187 -- |STRONGSWAN 
> SERVER| -- Eth0 172.31.10.126 (EIP x.x.x.209) == Outside Interface 
> x.x.x.143 -- |CISCO ASA| -- 192.168.20.0/24 Subnet to other hots
>
>  
>
> StrongSwan Server has two Interfaces: Eth0 and Eth1.
>
>  Eth0 has an EIP associated to it (x.x.x.209)
>
>  Eth1 has an IP of 172.31.12.187 that I believe should pass traffic to 
> the Test Server
>
>  
>
> Test Server has an IP address of 172.31.12.176
>
>  
>
> Cisco ASA has an outside interface of x.x.x.143 and communicates to the 
> subnet 192.168.20.0/24.
>
>  
>
>  
>
> CONFIGS & OUTPUT IP/ROUTE DETAILS
>
> # ipsec.conf - strongSwan IPsec configuration file
>
>  
>
> # basic configuration
>
>  
>
> config setup
>
>     # strictcrlpolicy=yes
>
>     # uniqueids = no
>
> charondebug="ike 2, knl 2, cfg 2, dmn 2, esp 2, net 2, chd 2"
>
>  
>
> conn RedSkyPIX-CHI
>
>     type = tunnel
>
>     authby = psk
>
>     auto = start
>
>     keyexchange = ikev1
>
>     ike = aes128-sha1-modp1024
>
>     esp = aes128-sha1
>
>     ikelifetime = 28800s
>
>     keylife = 3600s
>
>     aggressive = no
>
>     left = 172.31.10.126
>
>     leftsubnet = 172.31.12.0/24
>
>     leftid = x.x.x.209
>
>     leftfirewall = yes
>
>     right = x.x.x.143
>
>     rightsubnet= 192.168.20.0/24
>
>     rightid = x.x.x.143
>
>     rightfirewall = yes
>
>  
>
>  
>
>  
>
> # The following are enabled
>
> sysctl net.ipv4.ip_forward=1
>
> sysctl net.ipv6.conf.all.forwarding=1
>
>  
>
>  
>
> # ip route show
>
> 172.31.12.0/24 dev eth1  proto kernel  scope link  src 172.31.12.187
>
> 172.31.10.0/24 dev eth0  proto kernel  scope link  src 172.31.10.126
>
> 169.254.0.0/16 dev eth0  scope link  metric 1002
>
> 169.254.0.0/16 dev eth1  scope link  metric 1003
>
> default via 172.31.10.1 dev eth0
>
>  
>
>  
>
>  
>
> # ip -s xfrm state
>
> src 172.31.10.126 dst x.x.x.143
>
>     proto esp spi 0xae1ca856(2921113686) reqid 1(0x0001) mode tunnel
>
>     replay-window 32 seq 0x flag 20 (0x0010)
>
>     auth hmac(sha1) 0x6008d28b0f40c2eb8fa884730aa41fa9da85dcac (160 bits)
>
>     enc cbc(aes) 0xdcfd69f529f3529a026aa2ddefce61bc (128 bits)
>
>     encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
>
>     lifetime config:
>
>       limit: soft (INF)(bytes), hard (INF)(bytes)
>
>   limit: soft (INF)(packets), hard (INF)(packets)
>
>   expire add: soft 3055(sec), hard 3600(sec)
>
>   expire use: soft 0(sec), hard 0(sec)
>
>     lifetime current:
>
>   0(bytes), 0(packets)
>
>   add 2018-01-04 14:22:14 use -
>
>     stats:
>
>   replay-window 0 replay 0 failed 0
>
> src x.x.x.143 dst 172.31.10.126
>
>     proto esp spi 0xc3a540f4(3282387188) reqid 1(0x0001) mode tunnel
>
>     replay-window 32 seq 0x flag 20 (0x0010)
>
>     auth hmac(sha1) 0x840c9d785e7bb09cd5b868ff13295f558191b3e5 (160 bits)
>
>     enc cbc(aes) 0xade0f2bfc266c8fcce9267f2270fcfe1 (128 bits)
>
>     encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
>
>     lifetime config:
>
>   limit: soft (INF)(bytes), hard (INF)(bytes)
>
>   limit: soft (INF)(packets), hard (INF)(packets)
>
>   expire add: soft 2940(sec), hard 3600(sec)
>
>   expire use: soft 0(sec), hard 0(sec)
>
>     lifetime current:
>
>   2160(bytes), 36(packets)
>
>   

Re: [strongSwan] How to set some strongswan parameters for all connections at once?

[Marian Kechlibar]

OK, so I set up an experimental VPN and started playing with it, as not
to break the production VPN.

CentOS uses swanctl as a lightweight controller, so ipsec.conf is not
really loaded.

I was able to set up DPD, Proposals etc. on a user-by-user basis, but
not globally.

Is there any way how to set something for all connections at once when
using swanctl?

Best regards

Marian Kechlibar
Prague, CZ

Dne 11.1.2018 v 9:54 Marian Kechlibar napsal(a):
> Hi all,
> 
> I would like to ask a question with regard to StrongSwan server
> configuration.
> 
> We are running a VPN server based on StrongSwan 5.5.3 on CentOS 7. The
> settings are as follows:
> 
> * ipsec.conf is completely empty, except for comments (the default state
> of the file after a fresh installation),
> * strongswan.conf includes all the charon confs, which are left in the
> default state as well,
> * swanctl.conf includes config files and pool files of all the
> individual users, where local_addrs, local_sa, remote_sa, children etc.
> is determined.
> 
> Now I would like to set up the following parameters of the system:
> 
> * Dead Peer Detection
> * Cipher Suites
> * Enforcement of IKEv2 only
> * Lifetime
> 
> And I would like for those parameters to apply to all the users of the
> system at once.
> 
> How do I do it? Do I add a conn block into the ipsec.conf?
> 
> And how about making exceptions for individual users? Let us say that I
> do not want Dead Peer Detection for user X. Can I turn it off in the
> appropriate user's config?
> 
> I studied the documentation online, but it is not entirely clear to me
> and I am afraid of ruining a setup of a functional VPN by trial and error.
> 
> Many thanks in advance.
> 
> Marian Kechlibar
> Prague, CZ
> 

Re: [strongSwan] Fwd: Windows native VPN client routing problem

[Kamil Jońca]

Giuseppe De Marco
 writes:

> def gw Route's metric in Windows can be changed runtime.
> If you want to fix the def gw from vpn in windows 10 just go in NIC propriety 
> of the vpn network interface, network, ipv4 -> Propriety, Advanced, Use 
> default gateway, then apply :)
>


But, sometimes, I want route ONLY to subnetwork (eg. work) via vpn, and
default rotue unchanged. And I did not found other resoultion than OP.
KJ


-- 
http://wolnelektury.pl/wesprzyj/teraz/
New Hampshire law forbids you to tap your feet, nod your head, or in
any way keep time to the music in a tavern, restaurant, or cafe.

[strongSwan] Fwd: Windows native VPN client routing problem

[Giuseppe De Marco]

def gw Route's metric in Windows can be changed runtime.
If you want to fix the def gw from vpn in windows 10 just go in NIC
propriety of the vpn network interface, network, ipv4 -> Propriety,
Advanced, Use default gateway, then apply :)

https://goo.gl/Zj5ktL

2018-01-11 9:35 GMT+01:00 Marian Kechlibar 
:

> Hi all,
>
> this is a description of a problem that I spent a better part of
> yesterday struggling with. I am sending a description of the problem and
> the solution for anyone who might be interested.
>
> I also have the feeling that this might be suited for the StrongSwan
> Wiki. Please let me know whether I should add it there.
>
> So.
>
> The symptoms
> 
> Server: strongswan 5.5.3 on CentOS 7.
> Client: native Windows VPN client, Windows 7 or Windows 10.
>
> Upon connection, the client ignores the traffic selectors sent by the
> server. A "print route" command will reveal that they were not added to
> the routing table. But non-Windows clients (Linux, Android) are routing
> well, so the server is probably correctly set up.
>
> Setting log level of charon to 2 will reveal that the traffic selectors
> are indeed sent correctly.
>
> The cause
> -
> Windows native VPN client ignores the traffic selectors unless your
> client IP address is from the same range. So if you get, say,
> 10.105.107.31 and your local_ts is 10.105.107.0/24, your routing will be
> OK, but if your local_ts is 172.17.1.0/24, it will not.
>
> Whether this is a bug or a weird feature, I do not know. That is how
> things go with Microsoft.
>
> The solution
> 
> AFAIK there is no way how to force the native client into acknowledging
> the traffic selectors sent by the server.
>
> All workarounds require Administrator privileges on the client Windows
> installation, at least for a few minutes.
>
> If your traffic selectors are dynamic, you are better off with another,
> non-native Windows client.
>
> If your traffic selectors are static, you can set up permanent routes on
> your system from Administrator's command line like this.
>
> First, you need to know the interface number of your VPN. Connect the
> VPN (even though the routing is bad) and run "route print". At the
> beginning of the output, list of all the interfaces is given. Each line
> represents one interface and begins with number of the interface. In my
> case, the VPN usually has something like 30.
>
> Disconnect the VPN and run the following command from your
> Administrator's command line:
>
> route -P add (range) mask (mask) (gateway) IF (interface number)
>
> This will create a permanent route tied to your VPN. After that, a
> regular Windows user will be able to connect the VPN with correct routing.
>
> On Windows 10, there is another solution using a PowerShell script. In
> case of interest, I can describe it as well.
>
> Best regards
>
> Marian Kechlibar
> Prague, CZ
>

[strongSwan] How to set some strongswan parameters for all connections at once?

[Marian Kechlibar]

Hi all,

I would like to ask a question with regard to StrongSwan server
configuration.

We are running a VPN server based on StrongSwan 5.5.3 on CentOS 7. The
settings are as follows:

* ipsec.conf is completely empty, except for comments (the default state
of the file after a fresh installation),
* strongswan.conf includes all the charon confs, which are left in the
default state as well,
* swanctl.conf includes config files and pool files of all the
individual users, where local_addrs, local_sa, remote_sa, children etc.
is determined.

Now I would like to set up the following parameters of the system:

* Dead Peer Detection
* Cipher Suites
* Enforcement of IKEv2 only
* Lifetime

And I would like for those parameters to apply to all the users of the
system at once.

How do I do it? Do I add a conn block into the ipsec.conf?

And how about making exceptions for individual users? Let us say that I
do not want Dead Peer Detection for user X. Can I turn it off in the
appropriate user's config?

I studied the documentation online, but it is not entirely clear to me
and I am afraid of ruining a setup of a functional VPN by trial and error.

Many thanks in advance.

Marian Kechlibar
Prague, CZ

[strongSwan] Windows native VPN client routing problem

[Marian Kechlibar]

Hi all,

this is a description of a problem that I spent a better part of
yesterday struggling with. I am sending a description of the problem and
the solution for anyone who might be interested.

I also have the feeling that this might be suited for the StrongSwan
Wiki. Please let me know whether I should add it there.

So.

The symptoms

Server: strongswan 5.5.3 on CentOS 7.
Client: native Windows VPN client, Windows 7 or Windows 10.

Upon connection, the client ignores the traffic selectors sent by the
server. A "print route" command will reveal that they were not added to
the routing table. But non-Windows clients (Linux, Android) are routing
well, so the server is probably correctly set up.

Setting log level of charon to 2 will reveal that the traffic selectors
are indeed sent correctly.

The cause
-
Windows native VPN client ignores the traffic selectors unless your
client IP address is from the same range. So if you get, say,
10.105.107.31 and your local_ts is 10.105.107.0/24, your routing will be
OK, but if your local_ts is 172.17.1.0/24, it will not.

Whether this is a bug or a weird feature, I do not know. That is how
things go with Microsoft.

The solution

AFAIK there is no way how to force the native client into acknowledging
the traffic selectors sent by the server.

All workarounds require Administrator privileges on the client Windows
installation, at least for a few minutes.

If your traffic selectors are dynamic, you are better off with another,
non-native Windows client.

If your traffic selectors are static, you can set up permanent routes on
your system from Administrator's command line like this.

First, you need to know the interface number of your VPN. Connect the
VPN (even though the routing is bad) and run "route print". At the
beginning of the output, list of all the interfaces is given. Each line
represents one interface and begins with number of the interface. In my
case, the VPN usually has something like 30.

Disconnect the VPN and run the following command from your
Administrator's command line:

route -P add (range) mask (mask) (gateway) IF (interface number)

This will create a permanent route tied to your VPN. After that, a
regular Windows user will be able to connect the VPN with correct routing.

On Windows 10, there is another solution using a PowerShell script. In
case of interest, I can describe it as well.

Best regards

Marian Kechlibar
Prague, CZ

Re: [strongSwan] IPSec Tunnel IP

[Yusuf Güngör]

Hi Jafar,

I have tried both deleting "rightsubnet=0.0.0.0/0" and adding "
rightsubnet=%dynamic" now. AP still gets "1.1.1.127" as peer tunnel ip.

ipsec primary tunnel peer tunnel ip:1.1.1.127
ipsec primary tunnel ap tunnel ip   :10.254.0.1

The problem caused from AP side?


2018-01-10 21:00 GMT+03:00 Jafar Al-Gharaibeh :

> Yusuf,
>
>   Have you tried deleting "rightsubnet=0.0.0.0/0" as Noel suggested
> below?
>
>   In a dynamic address setup like this I usually do (Which has the same
> effect of deleting it):
>
>   rightsubnet=%dynamic
>
>
> --Jafar
>
>
> On 1/10/2018 4:28 AM, Yusuf Güngör wrote:
>
> Hi Noel,
>
> We have APs which located at various locations. APs get ip from
> strongswan.
>
> We have to add the "rightsubnet=0.0.0.0/0" to let APs connect. (We do not
> know the APs private-public ip addreses)
>
> We have to add the "rightsourceip=10.254.0.0/24" to give APs tunnel ip.
>
> APs can get ip from the "righsourceip" pool successfully:
>
> ipsec primary tunnel ap tunnel ip   :10.254.0.1
>
>
> But why peer tunnel ip is "1.1.1.127"
>
> ipsec primary tunnel peer tunnel ip :1.1.1.127
>
>
> We can establish vpn connections from APs to Aruba Controllers and that
> time APs get ip addresses as expected:
>
> ipsec primary tunnel ap tunnel ip   :10.254.0.1
>
> ipsec primary tunnel peer tunnel ip : controller>
>
> We are missing something?
>
> Also, VPN connection to strongswan restarts about every 3 hours. AP
> disconnect and reconnect because of packet loss. This should be subject of
> another topic, i wrote if something is related with that.
>
> Thanks for help.
>
> 2017-12-28 16:12 GMT+03:00 Noel Kuntze  ml@thermi.consulting>:
>
>> Hello,
>>
>> It's because you set "rightsubnet=0.0.0.0/0" and evidently the AP
>> proposes "1.1.1.127" as its local TS, so it gets narrowed to that. I
>> propose you delete those two lines.
>>
>> Kind regards
>>
>> Noel
>>
>> On 27.12.2017 11:01, Yusuf Güngör wrote:
>> > Hi,
>> >
>> > I have a configuration like below and VPN connection successfully
>> established but client side get "1.1.1.127" as tunnel IP. Can we change
>> this tunnel IP? I can not find any clue about why StrongSwan assign
>> "1.1.1.127" as tunnel IP to clients?
>> >
>> > Thanks.
>> >
>> >
>> > *StrongSwan Config (Left)*
>> >
>> > conn vpn-test
>> >   left=%defaultroute
>> >   leftsubnet=172.30.1.1/25 
>> >   leftauth=psk
>> >   leftfirewall=no
>> >   right=%any
>> >   rightsubnet=0.0.0.0/0 
>> >   rightsourceip=10.254.0.0/24 
>> >   auto=add
>> >   keyexchange=ikev1
>> >   rightauth=psk
>> >   rightauth2=xauth
>> >   type=tunnel
>> >   mobike=yes
>> >   rightid=%any
>> >
>> >
>> > *Client VPN Status: (Aruba Instant AP - Right)*
>> >
>> > current using tunnel:primary tunnel
>> > current tunnel using time   :1 hour 43 minutes
>> 31 seconds
>> > ipsec is preempt status :disable
>> > ipsec is fast failover status   :disable
>> > ipsec hold on period:0s
>> > ipsec tunnel monitor frequency (seconds/packet) :5
>> > ipsec tunnel monitor timeout by lost packet cnt :6
>> >
>> > ipsec primary tunnel crypto type:PSK
>> > ipsec primary tunnel peer address   :52.55.49.104
>> > ipsec primary tunnel peer tunnel ip :1.1.1.127
>> > ipsec primary tunnel ap tunnel ip   :10.254.0.1
>> > ipsec primary tunnel using interface:tun0
>> > ipsec primary tunnel using MTU  :1230
>> > ipsec primary tunnel current sm status  :Up
>> > ipsec primary tunnel tunnel status  :Up
>> > ipsec primary tunnel tunnel retry times :6
>> > ipsec primary tunnel tunnel uptime  :1 hour 43 minutes
>> 31 seconds
>> >
>> > ipsec  backup tunnel crypto type:PSK
>> > ipsec  backup tunnel peer address   :N/A
>> > ipsec  backup tunnel peer tunnel ip :N/A
>> > ipsec  backup tunnel ap tunnel ip   :N/A
>> > ipsec  backup tunnel using interface:N/A
>> > ipsec  backup tunnel using MTU  :N/A
>> > ipsec  backup tunnel current sm status  :Init
>> > ipsec  backup tunnel tunnel status  :Down
>> > ipsec  backup tunnel tunnel retry times :0
>> > ipsec  backup tunnel tunnel
>> >
>> >
>>
>
>
>