Re: [strongSwan] strict crl policy

[Jafar Al-Gharaibeh]

Hi,

   Double check two things:

        1 - Make sure the revocation plugin is loaded, use "ipsec 
statusall"


   2- Make sure the crl is loaded, use " ipsec listcrls"

--Jafar


On 9/24/2021 3:14 PM, Modster, Anthony wrote:


Hello

Does setting strict CRL policy to yes still work ?

The CRL’s for TA and SCA are removed.

Was expecting the VPN tunnel not to make a connection.

strongSwan 5.8.2

# ipsec.conf - strongSwan IPsec configuration file

# basic configuration

config setup

    charondebug="ike 2,cfg 2"

    strictcrlpolicy=yes

    # uniqueids = no


Teledyne Confidential; Commercially Sensitive Business Data

Re: [strongSwan] Strongswan IKEv2 certificates - "user authentication failed" ????

[Jafar Al-Gharaibeh]

Try the following for "remote":

/    remote {
    auth = eap-tls
    eap_id = %any
    }/

--Jafar


On 4/24/21 10:33 PM, pLAN9 Administrator wrote:
>
> I am trying to set up Strongswan to act as a remote access  server for
> an iPhone using IKEv2 certificate auth. It is a major headache!
>
> I have made sure to set the SAN in both the server and phone
> certificate. Here is the the server SAN:
>
> /    X509v3 extensions:
>     X509v3 Subject Alternative Name:
>     DNS:echo.pLAN9.co
>     X509v3 Extended Key Usage:
>     TLS Web Server Authentication, TLS Web Client
> Authentication/
>
> Here is the phone SAN:
>
> /    X509v3 extensions:
>     X509v3 Subject Alternative Name:
>     DNS:pLAN9-iPhone.pLAN9.co
>     X509v3 Extended Key Usage:
>     TLS Web Server Authentication, TLS Web Client
> Authentication/
>
> Here is /etc/swanctl/swanctl.conf
>
> /connections {
>     RA {
>     local_addrs = %any
>     local {
>     auth = pubkey
>     certs = ECHO.crt
>     id = @echo.pLAN9.co
>     }
>     remote {
>     auth = pubkey
>     id = %any
>     }
>     children {
>     net {
>     local_ts = 0.0.0.0/0
>     esp_proposals = aes256-sha256
>     }
>     }
>     version = 2
>     proposals = aes256-sha256-modp2048
>     send_certreq = no
>     pools = pool
>     }
> }
> pools {
>     pool {
>     addrs = 172.16.16.64/29
>     dns = 172.16.16.1
>     }
>     }/
>
>
> Here is the output of a connection:
>
>
> /01[NET] received packet: from IPHONE_IP[9975] to STRONGSWAN_IP[500]
> (604 bytes)//
> //01[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(REDIR_SUP)
> N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]//
> //01[IKE] IPHONE_IP is initiating an IKE_SA//
> //01[CFG] selected proposal:
> IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048//
> //01[IKE] remote host is behind NAT//
> //01[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP)
> N(NATD_D_IP) N(FRAG_SUP) N(CHDLESS_SUP) N(MULT_AUTH) ]//
> //01[NET] sending packet: from STRONGSWAN_IP[500] to IPHONE_IP[9975]
> (456 bytes)//
> //10[NET] received packet: from IPHONE_IP[9959] to STRONGSWAN_IP[4500]
> (532 bytes)//
> //10[ENC] parsed IKE_AUTH request 1 [ EF(1/4) ]//
> //13[NET] received packet: from IPHONE_IP[9959] to STRONGSWAN_IP[4500]
> (532 bytes)//
> //10[ENC] received fragment #1 of 4, waiting for complete IKE message//
> //13[ENC] parsed IKE_AUTH request 1 [ EF(2/4) ]//
> //13[ENC] received fragment #2 of 4, waiting for complete IKE message//
> //14[NET] received packet: from IPHONE_IP[9959] to STRONGSWAN_IP[4500]
> (532 bytes)//
> //14[ENC] parsed IKE_AUTH request 1 [ EF(3/4) ]//
> //01[NET] received packet: from IPHONE_IP[9959] to STRONGSWAN_IP[4500]
> (180 bytes)//
> //14[ENC] received fragment #3 of 4, waiting for complete IKE message//
> //01[ENC] parsed IKE_AUTH request 1 [ EF(4/4) ]//
> //01[ENC] received fragment #4 of 4, reassembled fragmented IKE
> message (1552 bytes)//
> //01[ENC] unknown attribute type INTERNAL_DNS_DOMAIN//
> //01[ENC] parsed IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) IDr
> AUTH CPRQ(ADDR MASK DHCP DNS ADDR6 DHCP6 DNS6 DOMAIN) N(ESP_TFC_PAD_N)
> N(NON_FIRST_FRAG) SA TSi TSr N(MOBIKE_SUP) ]//
> //01[IKE] received end entity cert "CN=pLAN9-iPhone"//
> //01[CFG] looking for peer configs matching
> STRONGSWAN_IP[echo.plan9.co]...IPHONE_IP[pLAn9-iPhone.pLAN9.co]//
> //01[CFG] selected peer config 'RA'//
> //01[CFG]   using certificate "CN=pLAN9-iPhone"//
> //01[CFG]   using trusted ca certificate "CN=pLAN9 CA 2019-2021"//
> //01[CFG] checking certificate status of "CN=pLAN9-iPhone"//
> //01[CFG] certificate status is not available//
> //01[CFG]   reached self-signed root ca with a path length of 0//
> //01[IKE] authentication of 'pLAn9-iPhone.pLAN9.co' with RSA signature
> successful//
> //01[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC
> padding//
> //01[IKE] peer supports MOBIKE//
> //01[IKE] authentication of 'echo.plan9.co' (myself) with RSA
> signature successful//
> //01[IKE] IKE_SA RA[2] established between
> STRONGSWAN_IP[echo.plan9.co]...IPHONE_IP[pLAn9-iPhone.pLAN9.co]//
> //01[IKE] scheduling rekeying in 13941s//
> //01[IKE] maximum IKE_SA lifetime 15381s//
> //01[IKE] peer requested virtual IP %any//
> //01[CFG] assigning new lease to 'pLAn9-iPhone.pLAN9.co'//
> //01[IKE] assigning virtual IP 172.16.16.65 to peer
> 'pLAn9-iPhone.pLAN9.co'//
> //01[IKE] peer requested virtual IP %any6//
> //01[IKE] no virtual IP found for %any6 requested by
> 

Re: [strongSwan] strongSwan, FRR, NHRP

[Jafar Al-Gharaibeh]

Hi,

 These patches never got merged, but you can still find them at [1].

 The actively maintained patches are available at [2].

--Jafar

[1] https://git-old.alpinelinux.org/user/tteras/strongswan/

[2]
https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/main/strongswan


On 1/21/21 1:34 AM, Volodymyr Litovka wrote:
>
> Hi colleagues,
>
> docs @ http://docs.frrouting.org/en/latest/nhrpd.html describes the
> way to create DMVPN network using FRR and says the following: "nhrpd
> needs tight integration with IKE daemon for various reasons. Currently
> only strongSwan is supported as IKE daemon. ... strongSwan currently
> needs few patches applied. Please check out the
> https://git.alpinelinux.org/user/tteras/strongswan/log/?h=tteras-release
> and https://git.alpinelinux.org/user/tteras/strongswan/log/?h=tteras
> git repositories for the patches." while there are no repositories at
> the specified links.
>
> The question is - whether these patches were merged in strongSwan and,
> if yes, starting which version?
>
> Thank you!
>
> --
> Volodymyr Litovka
>   "Vision without Execution is Hallucination." -- Thomas Edison

Re: [strongSwan] Cannot load private key

[Jafar Al-Gharaibeh]

I have seen this also happenning when the key itself is encrypted with 
an (outdated-disabled) algorithm like 3des. Reload secrets and check the 
logs.


Regards,

Jafar

On 11/24/2020 10:28 AM, Tobias Brunner wrote:

Hi Udo,


Why is the correct password denied by swanctl?

Either the password is simply wrong, or the key is stored in a format
that's currently not supported.  Could you send me the key?

Regards,
Tobias

Re: [strongSwan] Issue of "no IKE config found for ..., sending NO_PROPOSAL_CHOSEN"

[Jafar Al-Gharaibeh]

Jianjun,

  I see at least one issue, "left" config is wrong, instead of

   left=0.0.0.0

 you want

   left=%any

Regards,

Jafar



On 9/2/19 5:03 PM, Jianjun Shen Shen wrote:
> Hello,
>
> I am using strongswan (U5.3.5/K4.4.0-87-generic) on Ubuntu (16.04.3 LTS).
>
> Running "/usr/lib/ipsec/charon --debug-cfg 4 --debug-ike 4" got the
> following log messages:
> 00[DMN] Starting IKE charon daemon (strongSwan 5.3.5, Linux
> 4.4.0-87-generic, x86_64)
> 00[CFG] loading ca certificates from '/etc/ipsec.d/cacerts'
> 00[CFG] loading aa certificates from '/etc/ipsec.d/aacerts'
> 00[CFG] loading ocsp signer certificates from '/etc/ipsec.d/ocspcerts'
> 00[CFG] loading attribute certificates from '/etc/ipsec.d/acerts'
> 00[CFG] loading crls from '/etc/ipsec.d/crls'
> 00[CFG] loading secrets from '/etc/ipsec.secrets'
> 00[CFG]   loaded IKE secret for 0.0.0.0 10.162.19.54
> 00[CFG]   secret: 73:77:6f:72:64:66:69:73:68
> 00[LIB] loaded plugins: charon test-vectors aes rc2 sha1 sha2 md4 md5
> random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8
> pkcs12 pgp dnskey sshkey pem fips-prf gmp xcbc hmac attr
> kernel-netlink resolve socket-default stroke updown
> 00[LIB] dropped capabilities, running as uid 0, gid 0
> 00[JOB] spawning 16 worker threads
> 05[NET] received packet: from 10.162.19.54[500] to 10.162.19.55[500]
> (660 bytes)
> 05[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP)
> N(NATD_D_IP) N(HASH_ALG) ]
> 05[CFG] looking for an ike config for 10.162.19.55...10.162.19.54
> 05[IKE] no IKE config found for 10.162.19.55...10.162.19.54, sending
> NO_PROPOSAL_CHOSEN
> 05[ENC] generating IKE_SA_INIT response 0 [ N(NO_PROP) ]
> 05[NET] sending packet: from 10.162.19.55[500] to 10.162.19.54[500]
> (36 bytes)
> 05[IKE] IKE_SA (unnamed)[1] state change: CREATED => DESTROYING
>
> And my ipsec.conf is quite simple:
> config setup
>     uniqueids=yes
>
> conn %default
>     keyingtries=%forever
>     type=transport
>     keyexchange=ikev2
>     auto=route
>     ike=aes256gcm16-sha256-modp2048
>     esp=aes256gcm16-modp2048
>
> conn host54
>     left=0.0.0.0
>     right=10.162.19.54
>     authby=psk
>     leftprotoport=gre
>     rightprotoport=gre
>
> "ipsec statusall" shows the following:
> Status of IKE charon daemon (strongSwan 5.3.5, Linux 4.4.0-87-generic,
> x86_64):
>   uptime: 3 seconds, since Sep 02 22:00:24 2019
>   malloc: sbrk 1216512, mmap 0, used 251808, free 964704
>   worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0,
> scheduled: 0
>   loaded plugins: charon test-vectors aes rc2 sha1 sha2 md4 md5 random
> nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp
> dnskey sshkey pem fips-prf gmp xcbc hmac attr kernel-netlink resolve
> socket-default stroke updown
> Listening IP addresses:
>   10.162.19.55
>   fd01:0:101:2616:20c:29ff:fe2f:26c4
>   172.17.0.1
>   192.168.0.55
> Connections:
>     host54:  0.0.0.0...10.162.19.54  IKEv2
>     host54:   local:  uses pre-shared key authentication
>     host54:   remote: [10.162.19.54] uses pre-shared key authentication
>     host54:   child:  dynamic[gre] === dynamic[gre] TRANSPORT
> Routed Connections:
>     host54 {1}:  ROUTED, TRANSPORT, reqid 1
>     host54 {1}:   10.162.19.55/32[gre] 
> === 10.162.19.54/32[gre] 
> Security Associations (0 up, 0 connecting):
>   none
>
> So, I could not see anything wrong. Could you please help?
>
> Regards,
> Jianjun
>
>
>


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [strongSwan] Frequent childsa close and open

[Jafar Al-Gharaibeh]

You haven't shared any configuration to tell but we have seen this
behavior over and over again. Check

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

Probably  your issue is the same and the solution is explained on the
same page.

--Jafar


On 8/15/19 11:29 AM, Naveen Neelakanta wrote:
> Hi 
>
> I am seeing this continuous close and create for the childsa. My logs
> are overrun, any clue on what might cause this and any way to prevent
> this from happening?.
>
>
> 2019-08-11T05:43:45.275Z inf charon local1         @dGzD9B
> text:14[IKE]  CHILD_SA sl3childsa{300113} established with
> SPIs a4efb19d_i 094e6541_o and TS 0.0.0.0/0  ===
> 0.0.0.0/0 
> 2019-08-11T05:43:45.526Z inf charon local1         @9xFYmB
> text:07[IKE]  closing CHILD_SA sl3childsa{300112} with SPIs
> 925920ac_i (40 bytes) 0c3067c2_o (40 bytes) and TS 0.0.0.0/0
>  === 0.0.0.0/0 
> 2019-08-11T05:43:45.577Z inf charon local1         @cxVdKB
> text:08[IKE]  CHILD_SA sl3childsa{300114} established with
> SPIs 9fb40275_i 08aab039_o and TS 0.0.0.0/0  ===
> 0.0.0.0/0 
> 2019-08-11T05:43:45.768Z inf charon local1         @Or8ri text:12[IKE]
>  closing CHILD_SA sl3childsa{300113} with SPIs a4efb19d_i
> (118 bytes) 094e6541_o (80 bytes) and TS 0.0.0.0/0 
> === 0.0.0.0/0 
> 2019-08-11T05:43:45.819Z inf charon local1         @rzhCjC
> text:07[IKE]  CHILD_SA sl3childsa{300115} established with
> SPIs 9c191940_i 09933911_o and TS 0.0.0.0/0  ===
> 0.0.0.0/0 
> 2019-08-11T05:43:46.173Z inf charon local1         @7Mh7WB
> text:11[IKE]  closing CHILD_SA sl3childsa{300114} with SPIs
> 9fb40275_i (166 bytes) 08aab039_o (80 bytes) and TS 0.0.0.0/0
>  === 0.0.0.0/0 
> 2019-08-11T05:43:46.219Z inf charon local1         @8aPAC text:06[IKE]
>  CHILD_SA sl3childsa{300116} established with SPIs
> 92827d7f_i 0aa37fd0_o and TS 0.0.0.0/0  ===
> 0.0.0.0/0 
> 2019-08-11T05:43:46.340Z inf charon local1         @v3IcGD
> text:13[IKE]  closing CHILD_SA sl3childsa{300115} with SPIs
> 9c191940_i (269 bytes) 09933911_o (1882 bytes) and TS 0.0.0.0/0
>  === 0.0.0.0/0 
> 2019-08-11T05:43:46.398Z inf charon local1         @lkT2O text:14[IKE]
>  CHILD_SA sl3childsa{300117} established with SPIs
> 7cd063e0_i 002cea3f_o and TS 0.0.0.0/0  ===
> 0.0.0.0/0 
> 2019-08-11T05:43:46.522Z inf charon local1         @SZB5P text:06[IKE]
>  closing CHILD_SA sl3childsa{300116} with SPIs 92827d7f_i
> (309 bytes) 0aa37fd0_o (1815 bytes) and TS 0.0.0.0/0
>  === 0.0.0.0/0 
> 2019-08-11T05:43:46.571Z inf charon local1         @4hJI2C
> text:07[IKE]  CHILD_SA sl3childsa{300118} established with
> SPIs 814927ac_i 06c97028_o and TS 0.0.0.0/0  ===
> 0.0.0.0/0 
> 2019-08-11T05:43:47.177Z inf charon local1         @P0vCN text:14[IKE]
>  closing CHILD_SA sl3childsa{300117} with SPIs 7cd063e0_i
> (113 bytes) 002cea3f_o (80 bytes) and TS 0.0.0.0/0 
> === 0.0.0.0/0 
> 2019-08-11T05:43:47.225Z inf charon local1         @l7zl7B
> text:12[IKE]  CHILD_SA sl3childsa{300119} established with
> SPIs 8469ef1d_i 0faab34b_o and TS 0.0.0.0/0  ===
> 0.0.0.0/0 
> 2019-08-11T05:43:47.350Z inf charon local1         @nS9xmC
> text:06[IKE]  closing CHILD_SA sl3childsa{300118} with SPIs
> 814927ac_i (309 bytes) 06c97028_o (1378 bytes) and TS 0.0.0.0/0
>  === 0.0.0.0/0 
> 2019-08-11T05:43:47.401Z inf charon local1         @13NLhB
> text:09[IKE]  CHILD_SA sl3childsa{300120} established with
> SPIs a0a0820d_i 09e1ebf5_o and TS 0.0.0.0/0  ===
> 0.0.0.0/0 
> 2019-08-11T05:43:47.951Z inf charon local1         @pGxtx text:14[IKE]
>  closing CHILD_SA sl3childsa{300119} with SPIs 8469ef1d_i
> (453 bytes) 0faab34b_o (386 bytes) and TS 0.0.0.0/0 
> === 0.0.0.0/0 
> 2019-08-11T05:43:47.998Z inf charon local1         @PwvBS text:07[IKE]
>  CHILD_SA sl3childsa{300121} established with SPIs
> 6b54047d_i 0195131c_o and TS 0.0.0.0/0  ===
> 0.0.0.0/0 
> 2019-08-11T05:43:48.119Z inf charon local1         @vU02x text:11[IKE]
>  closing CHILD_SA sl3childsa{300120} with SPIs a0a0820d_i
> (72 bytes) 09e1ebf5_o (488 bytes) and TS 0.0.0.0/0 
> === 0.0.0.0/0 
> 2019-08-11T05:43:48.167Z inf charon local1         @statc text:12[IKE]
>  CHILD_SA sl3childsa{300122} established with SPIs
> 7f4a4ad2_i 0f4abf4d_o and TS 0.0.0.0/0  ===
> 0.0.0.0/0 
> 2019-08-11T05:43:48.736Z inf charon local1         @9uAQz text:16[IKE]
>  closing CHILD_SA sl3childsa{300121} with SPIs 6b54047d_i
> (76 bytes) 

Re: [strongSwan] Problem initilizig ipsec tunnel

[Jafar Al-Gharaibeh]

Philippe,

   We don't know what happened either. If you want help follow the 
instructions on [1].

  provide configs/logs/etc.


--Jafar

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

On 10/18/2018 10:53 AM, MIDOL MONNET Philippe wrote:

Hello

I'm not familiar with StrongSwan and I have the following issue when I
try to establish a tunnel:

With the charon log and a tcpdump I can see that, initialisation and
authentication seem to be OK:

Send: IKE_SA_INIT Initiator Request
Recv: IKE_SA_INIT Responder Response
Send: IKE_AUTH Initiator Request
Recv: IKE_AUTH Responder Response

Therefore there is INFORMATIONNAL:
Send: INFORMATIONAL Initiator Request
Recv: INFORMATIONAL Responder  Request
Send: INFORMATIONAL Initiator Response
At this moment, distant host redo the request and localhost resend the
response:
Recv: INFORMATIONAL Responder  Request
Send: INFORMATIONAL Initiator Response
Send: INFORMATIONAL Initiator Request
etc..
and the tunnel can't be used

I don't know what happen, can you help me?

Philippe

Re: [strongSwan] IKE signature scheme RSA_EMSA_PKCS1_SHA1 not acceptable

[Jafar Al-Gharaibeh]

Binarus,

    Did you manage to increase the logging level and get more 
information? That would be helpful in determining what is going on.


  --Jafar

On 08/21/2018 01:11 AM, Binarus wrote:

Jafar,

thank you very much again.

On 20.08.2018 23:20, Jafar Al-Gharaibeh wrote:


The issue does have something to do with non-matching proposals. It is
just that for signature schemes prior to version 5.3  the signature
constraints were not enforced. In your configuration you have :

    leftauth=rsa-4096-sha512
    rightauth=rsa-4096-sha512


   That means you expect the certificates at both ends to use use at
least 4096 RSA keys  and sha512 for signature schemes. You had the
setting all the time but it wasn't being enforced prior to 5.3, but now
it is. Instead of fixing it by turning

signature_authentication_constraints

off, I would generate new certificates with that strength if you want it
that strong, or just lower your constraints in left/rightauth to match
your existing certs. see left/rightauth at [1].

Perhaps I have been not clear enough, but I believe that in my previous
post I have described how I created the certificates when initially
configuring that VPN. To quote myself (from my previous post):

"Furthermore, when initially configuring the VPN between me and my
client (about 2 years ago), I have newly created *all* certificates
involved from scratch, using RSA 4096 and SHA-512."

To be sure that I am not making a fool of myself now, I just have
checked all certificates again (openssl x509 -in .crt
-text -noout). I did that check not only with each certificate I have
installed at my side, but also with the CA certificate and each
certificate which is installed in the client's device.

For each certificate, the output of the command mentioned above included
the following lines (among others, leading spaces removed):

Signature Algorithm: sha512WithRSAEncryption
Public-Key: (4096 bit)

So I think that your statement from your last post from yesterday is
correct, and that there actually is more to the story. But what?
Probably it is related to RFC 7427 ...

Thank you very much,

Binarus

Re: [strongSwan] IKE signature scheme RSA_EMSA_PKCS1_SHA1 not acceptable

[Jafar Al-Gharaibeh]

Binarus,  BTW, that was my quick assessment, so there might be more to 
the story :-).


--Jafar


On 2018-08-20 16:20, Jafar Al-Gharaibeh wrote:

On 08/20/2018 02:35 PM, Binarus wrote:
However, since I was absolutely sure that nobody at my client's site 
had changed their router's configuration, I have done further 
research. Among others, I have studied my 
/etc/strongswan.d/charon.conf again and came across a setting which 
looked highly suspicious to me:


signature_authentication_constraints = yes

Entering "signature_authentication_constraints" into Google 
immediately lead to this article:


https://www.strongswan.org/blog/2015/03/30/strongswan-5.3.0-released.html

After having read the second section of that article, I turned off the 
setting mentioned above (i.e. set it to no), and now it works as 
before.


So it seems that the issue didn't have anything to do with 
non-matching proposals, but with that setting, which seems to have 
been introduced (or seems to have been assigned another default value) 
with version 5.3.0. This explains why my old configuration with the 
old version 5.2.1 worked, but the same configuration with the new 
version 5.5.1 didn't.

  The issue does have something to do with non-matching proposals. It
is just that for signature schemes prior to version 5.3  the signature
constraints were not enforced. In your configuration you have :

   leftauth=rsa-4096-sha512
   rightauth=rsa-4096-sha512


  That means you expect the certificates at both ends to use use at
least 4096 RSA keys  and sha512 for signature schemes. You had the
setting all the time but it wasn't being enforced prior to 5.3, but
now it is. Instead of fixing it by turning

signature_authentication_constraints

off, I would generate new certificates with that strength if you want
it that strong, or just lower your constraints in left/rightauth to
match your existing certs. see left/rightauth at [1].

Regards,
Jafar


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




While my urgent and immediate problem is solved now, I still have a 
hard time actually understanding what that article section is talking 
about. I would be grateful if somebody could explain the issue for 
people who are not full-time professional cryptographers. 
Specifically, I have not fully understood the following sentences yet:


"Key types and hash algorithms specified in rightauth are now also 
checked against IKEv2 signature schemes. If such constraints are used 
for certificate chain validation in existing configurations, in 
particular with peers that don't support RFC 7427, it may be necessary 
to disable this feature with the 
charon.signature_authentication_constraints setting, because the 
signature scheme used in classic IKEv2 public key authentication may 
not be strong enough."


I believe I have configured the strongest rightauth and leftauth 
scheme the router at the client's site supports, which probably is the 
strongest scheme commonly used with RSA (at least, I haven't heard of 
SHA768 or SHA1024 yet, or that SHA3 or RSA8192 are currently being 
supported by more than a few exotic router / VPN devices). 
Furthermore, when initially configuring the VPN between me and my 
client (about 2 years ago), I have newly created *all* certificates 
involved from scratch, using RSA 4096 and SHA-512.


So what exactly does StrongSwan (charon) expect here (i.e. what would 
it consider strong enough), and how do I configure it (in case I 
decide to re-enable signature_authentication_constraints)? A simple 
explanation would be very nice; otherwise, probably we (I assume that 
I am not the only person who hasn't fully understood that section) 
will have to study RFC 7427, which we'd like to avoid :-).


Thank you very much in advance,

Binarus




--Jafar




On 08/18/2018 10:26 AM, Binarus wrote:

Dear all,

I am getting the error message mentioned above when trying to 
connect to
a client's site. Of course, I have tried to research if there 
already
has been a similar problem, and have found exactly one appropriate 
thread:


https://lists.strongswan.org/pipermail/users/2018-March/012351.html

Unfortunately, my situation is different; in my case, something else
seems to cause the problem. Having said this:

- It happened after the upgrade from Debian jessie (Debian 8) to 
Debian

stretch (Debian 9), i.e. after the upgrade from StrongSwan 5.2.1 to
StrongSwan 5.5.1)

- I definitely have copied the whole configuration (including
certificates and so on) from the old system to the new one (AFTER 
having
installed the new StrongSwan version in the new system). I have 
double
checked multiple times (applying different methods) that nothing is 
missing.


- With the old system, I definitely could connect to the client's 
site

without any problem with exact that configuration.

If it matters, the VPN Gateway at the client's side is a Lancom 
router
(I don't know the exact type, but it is newer one, 

Re: [strongSwan] IKE signature scheme RSA_EMSA_PKCS1_SHA1 not acceptable

[Jafar Al-Gharaibeh]

On 08/20/2018 02:35 PM, Binarus wrote:

However, since I was absolutely sure that nobody at my client's site had 
changed their router's configuration, I have done further research. Among 
others, I have studied my /etc/strongswan.d/charon.conf again and came across a 
setting which looked highly suspicious to me:

signature_authentication_constraints = yes

Entering "signature_authentication_constraints" into Google immediately lead to 
this article:

https://www.strongswan.org/blog/2015/03/30/strongswan-5.3.0-released.html

After having read the second section of that article, I turned off the setting 
mentioned above (i.e. set it to no), and now it works as before.

So it seems that the issue didn't have anything to do with non-matching 
proposals, but with that setting, which seems to have been introduced (or seems 
to have been assigned another default value) with version 5.3.0. This explains 
why my old configuration with the old version 5.2.1 worked, but the same 
configuration with the new version 5.5.1 didn't.
  The issue does have something to do with non-matching proposals. It 
is just that for signature schemes prior to version 5.3  the signature 
constraints were not enforced. In your configuration you have :


   leftauth=rsa-4096-sha512
   rightauth=rsa-4096-sha512


  That means you expect the certificates at both ends to use use at 
least 4096 RSA keys  and sha512 for signature schemes. You had the 
setting all the time but it wasn't being enforced prior to 5.3, but now 
it is. Instead of fixing it by turning


signature_authentication_constraints

off, I would generate new certificates with that strength if you want it 
that strong, or just lower your constraints in left/rightauth to match 
your existing certs. see left/rightauth at [1].


Regards,
Jafar


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




While my urgent and immediate problem is solved now, I still have a hard time 
actually understanding what that article section is talking about. I would be 
grateful if somebody could explain the issue for people who are not full-time 
professional cryptographers. Specifically, I have not fully understood the 
following sentences yet:

"Key types and hash algorithms specified in rightauth are now also checked against 
IKEv2 signature schemes. If such constraints are used for certificate chain validation in 
existing configurations, in particular with peers that don't support RFC 7427, it may be 
necessary to disable this feature with the charon.signature_authentication_constraints 
setting, because the signature scheme used in classic IKEv2 public key authentication may 
not be strong enough."

I believe I have configured the strongest rightauth and leftauth scheme the 
router at the client's site supports, which probably is the strongest scheme 
commonly used with RSA (at least, I haven't heard of SHA768 or SHA1024 yet, or 
that SHA3 or RSA8192 are currently being supported by more than a few exotic 
router / VPN devices). Furthermore, when initially configuring the VPN between 
me and my client (about 2 years ago), I have newly created *all* certificates 
involved from scratch, using RSA 4096 and SHA-512.

So what exactly does StrongSwan (charon) expect here (i.e. what would it 
consider strong enough), and how do I configure it (in case I decide to 
re-enable signature_authentication_constraints)? A simple explanation would be 
very nice; otherwise, probably we (I assume that I am not the only person who 
hasn't fully understood that section) will have to study RFC 7427, which we'd 
like to avoid :-).

Thank you very much in advance,

Binarus




--Jafar




On 08/18/2018 10:26 AM, Binarus wrote:

Dear all,

I am getting the error message mentioned above when trying to connect to
a client's site. Of course, I have tried to research if there already
has been a similar problem, and have found exactly one appropriate thread:

https://lists.strongswan.org/pipermail/users/2018-March/012351.html

Unfortunately, my situation is different; in my case, something else
seems to cause the problem. Having said this:

- It happened after the upgrade from Debian jessie (Debian 8) to Debian
stretch (Debian 9), i.e. after the upgrade from StrongSwan 5.2.1 to
StrongSwan 5.5.1)

- I definitely have copied the whole configuration (including
certificates and so on) from the old system to the new one (AFTER having
installed the new StrongSwan version in the new system). I have double
checked multiple times (applying different methods) that nothing is missing.

- With the old system, I definitely could connect to the client's site
without any problem with exact that configuration.

If it matters, the VPN Gateway at the client's side is a Lancom router
(I don't know the exact type, but it is newer one, and I am absolutely
sure that they didn't any changes to it while I was upgrading my system,
and to stress it again, the old system / StrongSwan version could
connect to that device 

Re: [strongSwan] IKE signature scheme RSA_EMSA_PKCS1_SHA1 not acceptable

[Jafar Al-Gharaibeh]

Binarus,

    Obviously the client proposal doesn't match what your server expect 
regardless of what you think has changed or not changed.
  To debug this better increase your logging level bu adding the 
following under your config setup section:


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

  That would allow you to see more information about the exchange.

--Jafar




On 08/18/2018 10:26 AM, Binarus wrote:

Dear all,

I am getting the error message mentioned above when trying to connect to
a client's site. Of course, I have tried to research if there already
has been a similar problem, and have found exactly one appropriate thread:

https://lists.strongswan.org/pipermail/users/2018-March/012351.html

Unfortunately, my situation is different; in my case, something else
seems to cause the problem. Having said this:

- It happened after the upgrade from Debian jessie (Debian 8) to Debian
stretch (Debian 9), i.e. after the upgrade from StrongSwan 5.2.1 to
StrongSwan 5.5.1)

- I definitely have copied the whole configuration (including
certificates and so on) from the old system to the new one (AFTER having
installed the new StrongSwan version in the new system). I have double
checked multiple times (applying different methods) that nothing is missing.

- With the old system, I definitely could connect to the client's site
without any problem with exact that configuration.

If it matters, the VPN Gateway at the client's side is a Lancom router
(I don't know the exact type, but it is newer one, and I am absolutely
sure that they didn't any changes to it while I was upgrading my system,
and to stress it again, the old system / StrongSwan version could
connect to that device without problems).

This is my /etc/ipsec.conf (sensitive data has been changed, and lines
which are commented out have been left away):


config setup

conn %default
   mobike=no

conn myclient
   ikelifetime=10800s
   keylife=3600s
   rekeymargin=9m
   keyingtries=1
   type=tunnel
   keyexchange=ikev2
   mobike=no
   ike=aes256-sha512-modp4096!
   esp=aes256-sha512-modp4096!
   left=.hopto.org
   leftauth=rsa-4096-sha512
   leftid="/CN=.hopto.org"
   leftsubnet=192.168.20.0/24
   leftfirewall=no
   leftcert=mycompany-client.crt
   right=.zapto.org
   rightauth=rsa-4096-sha512
   rightid="/CN=.zapto.org"
   rightsubnet=192.168.0.0/24
   auto=add


This is the error message (sensitive data changed in the same way as
with ipsec.conf):

root@charon:/etc# /etc/init.d/ipsec restart
[ ok ] Restarting ipsec (via systemctl): ipsec.service.
root@charon:/etc# ipsec up myclient
initiating IKE_SA myclient[3] to 79.192.42.125
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP)
N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
sending packet: from 87.185.83.87[500] to 79.192.42.125[500] (714 bytes)
received packet: from 79.192.42.125[500] to 87.185.83.87[500] (713 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ ]
received 1 cert requests for an unknown ca
sending cert request for "CN=ca.clientsite.local"
authentication of 'CN=.hopto.org' (myself) with RSA
signature successful
sending end entity cert "CN=.hopto.org"
establishing CHILD_SA myclient
generating IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) CERTREQ IDr
AUTH SA TSi TSr N(EAP_ONLY) ]
sending packet: from 87.185.83.87[500] to 79.192.42.125[500] (2048 bytes)
received packet: from 79.192.42.125[500] to 87.185.83.87[500] (1984 bytes)
parsed IKE_AUTH response 1 [ IDr CERT AUTH TSi TSr N(INIT_CONTACT) SA ]
received end entity cert "CN=.zapto.org"
   using certificate "CN=.zapto.org"
   using trusted ca certificate "CN=ca.clientsite.local"
checking certificate status of "CN=.zapto.org"
certificate status is not available
   reached self-signed root ca with a path length of 0
authentication of 'CN=.zapto.org' with RSA signature
successful
IKE signature scheme RSA_EMSA_PKCS1_SHA1 not acceptable
selected peer config 'myclient' inacceptable: constraint checking failed
no alternative config found
generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
sending packet: from 87.185.83.87[500] to 79.192.42.125[500] (96 bytes)
establishing connection 'myclient' failed
root@charon:/etc#


Does anybody have an idea?

Thank you very much in advance,

Binarus

Re: [strongSwan] Route based VPN Strongswan IPsec tunnel

[Jafar Al-Gharaibeh]

Kaushal,

    See [1] for a detailed for an exampling building from sources on 
Ubuntu. I recommend installing whatever version your distro provides. 
Also start with a simple example with pre-shared keys like [2].


--Jafar

[1] 
https://www.digitalocean.com/community/tutorials/how-to-set-up-an-ikev2-vpn-server-with-strongswan-on-ubuntu-16-04

[2] https://www.strongswan.org/testing/testresults/ikev2/rw-psk-ipv4/


On 7/24/2018 1:08 PM, Kaushal Shriyan wrote:

Hi,

Are there any steps to set up route based VPN using Strongswan IPsec 
tunnel?


Thanks in Advance.

Best Regards,

Kaushal

Re: [strongSwan] Strongswan 5.6.3 rekey every 30 seconds

[Jafar Al-Gharaibeh]

Doug,

   Check your configuration, if you have:

uniqueids=yes
auto=start
closeaction=restart

Then that is the cause of the issue. That is a bad combination that gets 
you in an infinite rekey loop.


--Jafar


On 7/24/2018 5:02 AM, Noel Kuntze wrote:

Hi,

You can use charon.delete_rekeyed = yes. But the better solution is to check 
the logs of the CISCO side to understand why it is doing that.

Kind regards

Noel

On 24.07.2018 05:29, Doug Tucker wrote:

Have an issue I've never seen before.  Connecting to a remote Cisco router.  
Have verified settings on the cisco, our rekey options look the same.  We get 
an established connection, then 30 seconds later a rekey happens and it 
installs under the new one.  This goes on forever.  Here are the logs  showing 
the original and 1 rekey.  If allowed to continue the number of SA increments 
as such:


Connections:
     sph-main:  x.x.x.x...x.x.x.x  IKEv1, dpddelay=15s
     sph-main:   local:  [x.x.x.x] uses pre-shared key authentication
     sph-main:   remote: [x.x.x.x] uses pre-shared key authentication
     sph-main:   child:  x.x.0.0/16 === x.x.x.x/28 TUNNEL, dpdaction=clear
Routed Connections:
     sph-main{1}:  ROUTED, TUNNEL, reqid 1
     sph-main{1}:   x.x.0.0/16 === x.x.x.x/28
Security Associations (1 up, 0 connecting):
     sph-main[1]: ESTABLISHED 3 minutes ago, x.x.x.x[x.x.x.x]...x.x.x.x[x.x.x.x]
     sph-main[1]: IKEv1 SPIs: 6a4fba86489e9e61_i a244a0079084bf87_r*, 
pre-shared key reauthentication in 7 hours
     sph-main[1]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536
     sph-main{2}:  REKEYED, TUNNEL, reqid 1, expires in 7 hours
     sph-main{2}:   x.x.0.0/16 === x.x.x.x/28
     sph-main{3}:  REKEYED, TUNNEL, reqid 1, expires in 7 hours
     sph-main{3}:   x.x.0.0/16 === x.x.x.x/28
     sph-main{4}:  REKEYED, TUNNEL, reqid 1, expires in 7 hours
     sph-main{4}:   x.x.0.0/16 === x.x.x.x/28
     sph-main{5}:  REKEYED, TUNNEL, reqid 1, expires in 7 hours
     sph-main{5}:   x.x.0.0/16 === x.x.x.x/28
     sph-main{6}:  REKEYED, TUNNEL, reqid 1, expires in 7 hours
     sph-main{6}:   x.x.0.0/16 === x.x.x.x/28
     sph-main{7}:  REKEYED, TUNNEL, reqid 1, expires in 7 hours
     sph-main{7}:   x.x.0.0/16 === x.x.x.x/28
     sph-main{8}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c781d0ed_i 
d0a8e566_o
     sph-main{8}:  AES_CBC_128/HMAC_SHA1_96/MODP_1536, 0 bytes_i, 0 bytes_o, 
rekeying in 7 hours
     sph-main{8}:   x.x.0.0/16 === x.x.x.x/28

Here are my logs:


Jul 24 03:17:31 ip-x-x-x-x journal: Suppressed 379 messages from 
/user.slice/user-x0.slice
Jul 24 03:17:31 ip-x-x-x-x charon: 11[NET] received packet: from x.x.x.x[500] 
to x.x.x.x[500] (34x bytes)
Jul 24 03:17:31 ip-x-x-x-x charon: 11[ENC] parsed ID_PROT request 0 [ KE No V V 
V NAT-D NAT-D ]
Jul 24 03:17:31 ip-x-x-x-x charon: 11[IKE] received DPD vendor ID
Jul 24 03:17:31 ip-x-x-x-x charon: 11[ENC] received unknown vendor ID: 
9f:xx:1d:9b:4x:9f:9e:61:5e:40:3x:7e:a5:6a:96:1f
Jul 24 03:17:31 ip-x-x-x-x charon: 11[IKE] received XAuth vendor ID
Jul 24 03:17:31 ip-x-x-x-x charon: 11[IKE] local host is behind NAT, sending 
keep alives
Jul 24 03:17:31 ip-x-x-x-x charon: 11[ENC] generating ID_PROT response 0 [ KE 
No NAT-D NAT-D ]
Jul 24 03:17:31 ip-x-x-x-x charon: 11[NET] sending packet: from x.x.x.x[500] to 
x.x.x.x[500] (30x bytes)
Jul 24 03:17:31 ip-x-x-x-x charon: 12[NET] received packet: from x.x.x.x[4500] 
to x.x.x.x[4500] (10x bytes)
Jul 24 03:17:31 ip-x-x-x-x charon: 12[ENC] parsed ID_PROT request 0 [ ID HASH 
N(INITIAL_CONTACT) ]
Jul 24 03:17:31 ip-x-x-x-x charon: 12[CFG] looking for pre-shared key peer 
configs matching x.x.x.x...x.x.x.x[x.x.x.x]
Jul 24 03:17:31 ip-x-x-x-x charon: 12[CFG] selected peer config "sph-main"
Jul 24 03:17:31 ip-x-x-x-x charon: 12[IKE] IKE_SA sph-main[1] established 
between x.x.x.x[13.251.151.1x]...x.x.x.x[x.x.x.x]
Jul 24 03:17:31 ip-x-x-x-x charon: 12[IKE] scheduling reauthentication in 2x02xs
Jul 24 03:17:31 ip-x-x-x-x charon: 12[IKE] maximum IKE_SA lifetime 2x56xs
Jul 24 03:17:31 ip-x-x-x-x charon: 12[ENC] generating ID_PROT response 0 [ ID 
HASH ]
Jul 24 03:17:31 ip-x-x-x-x charon: 12[NET] sending packet: from x.x.x.x[4500] 
to x.x.x.x[4500] (76 bytes)
Jul 24 03:17:31 ip-x-x-x-x charon: 14[NET] received packet: from x.x.x.x[4500] 
to x.x.x.x[4500] (3x0 bytes)
Jul 24 03:17:31 ip-x-x-x-x charon: 14[ENC] parsed QUICK_MODE request 225x9x7323 
[ HASH SA No KE ID ID ]
Jul 24 03:17:31 ip-x-x-x-x charon: 14[IKE] received 460x00 lifebytes, 
configured 0
Jul 24 03:17:31 ip-x-x-x-x charon: 14[ENC] generating QUICK_MODE response 
225x9x7323 [ HASH SA No KE ID ID ]
Jul 24 03:17:31 ip-x-x-x-x charon: 14[NET] sending packet: from x.x.x.x[4500] 
to x.x.x.x[4500] (396 bytes)
Jul 24 03:17:31 ip-x-x-x-x charon: 15[NET] received packet: from x.x.x.x[4500] 
to x.x.x.x[4500] (60 bytes)
Jul 24 03:17:31 ip-x-x-x-x charon: 15[ENC] parsed QUICK_MODE request 225x9x7323 
[ HASH ]
Jul 24 03:17:31 ip-x-x-x-x charon: 15[IKE] CHILD_SA sph-main{2} 

Re: [strongSwan] Sudden issues with Windows 10 clients

[Jafar Al-Gharaibeh]

Tobias,

   My next question then is:

   In the case of  aesgcm algorithms where the integrity is built into 
the encryption algorithm, How does that map to prf algorithms ?  Do yo 
have to explicitly configure prf in that case? or are those mapped too? 
I didn't see such mapping in wiki pages.


Thanks,
Jaafr


On 2018-05-14 04:16, Tobias Brunner wrote:

Hi Jafar,


     Thanks for the correction.   What I meant to say is :

              The PRF algorithm is derived from the integrity 
algorithm,

but only if a DH group is also configured.

  Correct?


No, the DH group has nothing to do with the PRF or the integrity
algorithm.  And for IKE proposals you always have to configure at least
one DH group.

Regards,
Tobias

Re: [strongSwan] Sudden issues with Windows 10 clients

[Jafar Al-Gharaibeh]

Hi Houman,

  The information on the Wiki is probably old, and it is not wrong 
anyway.

3des is broken and shouldn't be used if the client can do better.

  The behavior I see in the log this time is very different from the 
previous
email. Last time we could see a complete and successful negotiation 
leading
to established connections. That is why I asked you to run "ipsec 
statusall".
This time around, the client doesn't seem to be getting responses from 
your server.
you can see multiple IKE_SA_INIT packets received, indicating the client 
is not

seeing the responses.

Since This is a completely different behavior, it is hard to draw 
conclusions.
The best way to debug is to have strongSwan at both ends so you can see 
complete

logs both ends.

--Jafar



On 2018-05-12 05:15, Houman wrote:

Hello Jafar,

Thank you for the final proposals. I have entered them and it works
great with iOS and OSX. I have no Windows to test it yet.

The only reason I had picked 3des-shal1, was because the StrongSwan
Wiki claims this was needed for Mac (OSX)
https://wiki.strongswan.org/projects/strongswan/wiki/AppleClients.
But I can see it works even without that.

My user in Iran still can't connect successfully. I have followed your
instructions. I have tailed the syslog below, hence this is all I can
see:

May 12 11:03:07 vpn-server charon: 02[NET] received packet: from
91.99.xxx.xxx[500] to 172.31.xxx.xxx[500] (604 bytes)

May 12 11:03:07 vpn-server charon: 02[ENC] parsed IKE_SA_INIT request
0 [ SA KE No N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]

May 12 11:03:07 vpn-server charon: 02[IKE] 91.99.xxx.xxx is initiating
an IKE_SA

May 12 11:03:07 vpn-server charon: 02[IKE] local host is behind NAT,
sending keep alives

May 12 11:03:07 vpn-server charon: 02[IKE] remote host is behind NAT

May 12 11:03:07 vpn-server charon: 02[ENC] generating IKE_SA_INIT
response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP)
N(MULT_AUTH) ]

May 12 11:03:07 vpn-server charon: 02[NET] sending packet: from
172.31.xxx.xxx[500] to 91.99.xxx.xxx[500] (448 bytes)

May 12 11:03:13 vpn-server charon: 11[NET] received packet: from
91.99.xxx.xxx[500] to 172.31.xxx.xxx[500] (604 bytes)

May 12 11:03:13 vpn-server charon: 11[ENC] parsed IKE_SA_INIT request
0 [ SA KE No N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]

May 12 11:03:13 vpn-server charon: 11[IKE] received retransmit of
request with ID 0, retransmitting response

May 12 11:03:13 vpn-server charon: 11[NET] sending packet: from
172.31.xxx.xxx[500] to 91.99.xxx.xxx[500] (448 bytes)

May 12 11:03:16 vpn-server charon: 12[NET] received packet: from
91.99.xxx.xxx[500] to 172.31.xxx.xxx[500] (604 bytes)

May 12 11:03:16 vpn-server charon: 12[ENC] parsed IKE_SA_INIT request
0 [ SA KE No N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]

May 12 11:03:16 vpn-server charon: 12[IKE] received retransmit of
request with ID 0, retransmitting response

May 12 11:03:16 vpn-server charon: 12[NET] sending packet: from
172.31.xxx.xxx[500] to 91.99.xxx.xxx[500] (448 bytes)

May 12 11:03:27 vpn-server charon: 10[IKE] sending keep alive to
91.99.xxx.xxx[500]

May 12 11:03:37 vpn-server charon: 05[JOB] deleting half open IKE_SA
after timeout

I have also executed ipsec statusall

Status of IKE charon daemon (strongSwan 5.3.5, Linux 4.4.0-1057-aws,
x86_64):

  uptime: 68 minutes, since May 12 09:55:31 2018

  malloc: sbrk 1773568, mmap 0, used 572416, free 1201152

  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0,
scheduled: 1

  loaded plugins: charon test-vectors aes rc2 sha1 sha2 md4 md5 random
nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp
dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm attr
kernel-netlink resolve socket-default connmark farp stroke updown
eap-identity eap-sim eap-sim-pcsc eap-aka eap-aka-3gpp2
eap-simaka-pseudonym eap-simaka-reauth eap-md5 eap-gtc eap-mschapv2
eap-dynamic eap-radius eap-tls eap-ttls eap-peap eap-tnc xauth-generic
xauth-eap xauth-pam xauth-noauth tnc-tnccs tnccs-20 tnccs-11
tnccs-dynamic dhcp lookip error-notify certexpire led addrblock unity

Virtual IP pools (size/online/offline):

  10.10.10.0/24 [5]: 254/0/1

Listening IP addresses:

  172.31.xxx.xxx

Connections:

 roadwarrior:  %any...%any  IKEv2, dpddelay=180s

 roadwarrior:   local:  [vpn1.xxx.com [1]] uses public key
authentication

 roadwarrior:cert:  "CN=vpn1.xxx.com [1]"

 roadwarrior:   remote: uses EAP_MSCHAPV2 authentication with EAP
identity '%any'

 roadwarrior:   child:  0.0.0.0/0 [2] === dynamic TUNNEL,
dpdaction=clear

Security Associations (0 up, 0 connecting):

  none

I can't quite see from this if they have blocked ESP or not. But I
suspect this is the case.

Many Thanks for your help,

Houman

Re: [strongSwan] Can anyone explain VPN oddity

[Jafar Al-Gharaibeh]

 TLS, session=
May 11 18:07:19 jodywhitesides dovecot: imap-login: Login:
user=, method=PLAIN, rip=67.177.12.59, lip=138.68.251.157,
mpid=7065, TLS, session=
May 11 18:07:19 jodywhitesides dovecot: imap-login: Login:
user=, method=PLAIN, rip=67.177.12.59,
lip=138.68.251.157, mpid=7066, TLS, session=
May 11 18:07:19 jodywhitesides dovecot: imap(onrecords): Logged out
in=38 out=489
May 11 18:07:19 jodywhitesides dovecot: imap(dancindeeraudio): Logged
out in=38 out=489
May 11 18:07:19 jodywhitesides dovecot: imap(musicteam): Logged out
in=38 out=489
May 11 18:07:19 jodywhitesides dovecot: imap(jody): Logged out in=38
out=489
May 11 18:07:19 jodywhitesides dovecot: imap(singleoftheday): Logged
out in=38 out=489
May 11 18:08:11 jodywhitesides charon: 11[IKE] sending keep alive to
172.58.38.179[47188]
May 11 18:08:11 jodywhitesides charon: 04[NET] sending packet: from
138.68.251.157[4500] to 172.58.38.179[47188]
May 11 18:08:13 jodywhitesides charon: 03[NET] received packet: from
172.58.38.179[47188] to 138.68.251.157[4500]
May 11 18:08:13 jodywhitesides charon: 03[NET] waiting for data on
sockets
May 11 18:08:13 jodywhitesides charon: 03[NET] received packet: from
172.58.38.179[47188] to 138.68.251.157[4500]
May 11 18:08:13 jodywhitesides charon: 03[NET] waiting for data on
sockets
May 11 18:08:13 jodywhitesides charon: 08[NET] received packet: from
172.58.38.179[47188] to 138.68.251.157[4500] (76 bytes)
May 11 18:08:13 jodywhitesides charon: 08[ENC] parsed INFORMATIONAL_V1
request 1401124821 [ HASH D ]
May 11 18:08:13 jodywhitesides charon: 08[IKE] received DELETE for ESP
CHILD_SA with SPI 0e8240c6
May 11 18:08:13 jodywhitesides charon: 08[IKE] closing CHILD_SA ios{3}
with SPIs ca4b4cf3_i (39562 bytes) 0e8240c6_o (72023 bytes) and TS
0.0.0.0/0 === 10.10.10.2/32
May 11 18:08:13 jodywhitesides kernel: [80968.117023] audit: type=1400
audit(1526083693.693:1036): apparmor="DENIED" operation="open"
profile="/usr/lib/ipsec/charon" name="/proc/7076/fd/" pid=7076
comm="charon" requested_mask="r" denied_mask$
May 11 18:08:13 jodywhitesides vpn: - C=US, O=JW Server VPN,
CN=138.68.251.157 10.10.10.2/32 == 172.58.38.179 -- 138.68.251.157 ==
0.0.0.0/0
May 11 18:08:13 jodywhitesides charon: 05[NET] received packet: from
172.58.38.179[47188] to 138.68.251.157[4500] (92 bytes)
May 11 18:08:13 jodywhitesides charon: 05[ENC] parsed INFORMATIONAL_V1
request 2091759899 [ HASH D ]
May 11 18:08:13 jodywhitesides charon: 05[IKE] received DELETE for
IKE_SA ios[3]
May 11 18:08:13 jodywhitesides charon: 05[IKE] deleting IKE_SA ios[3]
between 138.68.251.157[138.68.251.157]...172.58.38.179[C=US, O=JW
Server VPN, CN=138.68.251.157]
May 11 18:08:13 jodywhitesides charon: 05[IKE] IKE_SA ios[3] state
change: ESTABLISHED => DELETING
May 11 18:08:13 jodywhitesides charon: 05[IKE] IKE_SA ios[3] state
change: DELETING => DELETING
May 11 18:08:13 jodywhitesides charon: 05[IKE] IKE_SA ios[3] state
change: DELETING => DESTROYING

Jody


On May 11, 2018, at 5:26 PM, Jafar Al-Gharaibeh <ja...@atcorp.com>
wrote:

Jody,
It is really hard to guess what the problem is without
information/logs.
In most situations where I had this issue (OK on WiFi but not OK
on cell) it turned out to be MTU related.
I am almost certain that the problem you are seeing is caused by
broken PMTU.
See the references below for some insight and possible solutions.

Regards,
Jafar

[1]


https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling#MTUMSS-issues

[2]


https://www.zeitgeist.se/2013/11/26/mtu-woes-in-ipsec-tunnels-how-to-fix/

[3] https://wiki.strongswan.org/issues/1025
[4]  https://wiki.strongswan.org/issues/632#note-14

On 5/11/2018 5:21 PM, Jody Whitesides wrote:


I have a working VPN that can connect to the internet at large.
That when a device is connected via WIFI it can also connect to
email and websites hosted on the same server as the VPN. However,
when a device is connected via a cellular connection to the VPN,
it can connect to the internet at large, but cannot connect to
email and websites on the same server.

Can anyone explain why this would occur? What is the difference
between a wild WIFI connection and a mobile cellular connection
that would cause the VPN to react differently to its host server?

Thank you,
Jody




Links:
--
[1] http://pj-in-x1a.1e100.net

Re: [strongSwan] Can anyone explain VPN oddity

[Jafar Al-Gharaibeh]

Jody,
    It is really hard to guess what the problem is without 
information/logs.
   In most situations where I had this issue (OK on WiFi but not OK on 
cell) it turned out to be MTU related.
    I am almost certain that the problem you are seeing is caused by 
broken PMTU.

   See the references below for some insight and possible solutions.

Regards,
Jafar

[1] 
https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling#MTUMSS-issues
[2] 
https://www.zeitgeist.se/2013/11/26/mtu-woes-in-ipsec-tunnels-how-to-fix/

[3] https://wiki.strongswan.org/issues/1025
[4] https://wiki.strongswan.org/issues/632#note-14



On 5/11/2018 5:21 PM, Jody Whitesides wrote:

I have a working VPN that can connect to the internet at large. That when a 
device is connected via WIFI it can also connect to email and websites hosted 
on the same server as the VPN. However, when a device is connected via a 
cellular connection to the VPN, it can connect to the internet at large, but 
cannot connect to email and websites on the same server.

Can anyone explain why this would occur? What is the difference between a wild 
WIFI connection and a mobile cellular connection that would cause the VPN to 
react differently to its host server?

Thank you,
Jody

Re: [strongSwan] Sudden issues with Windows 10 clients

[Jafar Al-Gharaibeh]

thentication of 
'vpn1.xxx.com <http://vpn1.xxx.com>' (myself) with RSA signature 
successful


May 11 07:57:45 vpn-server charon: 04[IKE] sending end entity cert 
"CN=vpn1.xxx.com <http://vpn1.xxx.com>"


May 11 07:57:45 vpn-server charon: 04[IKE] sending issuer cert "C=US, 
O=Let's Encrypt, CN=Let's Encrypt Authority X3"


May 11 07:57:45 vpn-server charon: 04[ENC] generating IKE_AUTH 
response 1 [ IDr CERT CERT AUTH EAP/REQ/ID ]


May 11 07:57:45 vpn-server charon: 04[NET] sending packet: from 
172.31.xxx.xxx[4500] to 109.230.xxx.xx[1024] (3616 bytes)


May 11 07:57:45 vpn-server charon: 02[NET] received packet: from 
109.230.xxx.xx[1024] to 172.31.xxx.xxx[4500] (96 bytes)


May 11 07:57:45 vpn-server charon: 02[ENC] parsed IKE_AUTH request 2 [ 
EAP/RES/ID ]


May 11 07:57:45 vpn-server charon: 02[IKE] received EAP identity 'houmie'

May 11 07:57:45 vpn-server charon: 02[IKE] initiating EAP_MSCHAPV2 
method (id 0x6C)


May 11 07:57:45 vpn-server charon: 02[ENC] generating IKE_AUTH 
response 2 [ EAP/REQ/MSCHAPV2 ]


May 11 07:57:45 vpn-server charon: 02[NET] sending packet: from 
172.31.xxx.xxx[4500] to 109.230.xxx.xx[1024] (112 bytes)


May 11 07:57:45 vpn-server charon: 03[NET] received packet: from 
109.230.xxx.xx[1024] to 172.31.xxx.xxx[4500] (144 bytes)


May 11 07:57:45 vpn-server charon: 03[ENC] parsed IKE_AUTH request 3 [ 
EAP/RES/MSCHAPV2 ]


May 11 07:57:45 vpn-server charon: 03[ENC] generating IKE_AUTH 
response 3 [ EAP/REQ/MSCHAPV2 ]


May 11 07:57:45 vpn-server charon: 03[NET] sending packet: from 
172.31.xxx.xxx[4500] to 109.230.xxx.xx[1024] (144 bytes)


May 11 07:57:45 vpn-server charon: 01[NET] received packet: from 
109.230.xxx.xx[1024] to 172.31.xxx.xxx[4500] (80 bytes)


May 11 07:57:45 vpn-server charon: 01[ENC] parsed IKE_AUTH request 4 [ 
EAP/RES/MSCHAPV2 ]


May 11 07:57:45 vpn-server charon: 01[IKE] EAP method EAP_MSCHAPV2 
succeeded, MSK established


May 11 07:57:45 vpn-server charon: 01[ENC] generating IKE_AUTH 
response 4 [ EAP/SUCC ]


May 11 07:57:45 vpn-server charon: 01[NET] sending packet: from 
172.31.xxx.xxx[4500] to 109.230.xxx.xx[1024] (80 bytes)


May 11 07:57:46 vpn-server charon: 11[NET] received packet: from 
109.230.xxx.xx[1024] to 172.31.xxx.xxx[4500] (112 bytes)


May 11 07:57:46 vpn-server charon: 11[ENC] parsed IKE_AUTH request 5 [ 
AUTH ]


May 11 07:57:46 vpn-server charon: 11[IKE] authentication of 
'192.168.1.103' with EAP successful


May 11 07:57:46 vpn-server charon: 11[IKE] authentication of 
'vpn1.xxx.com <http://vpn1.xxx.com>' (myself) with EAP


May 11 07:57:46 vpn-server charon: 11[IKE] IKE_SA roadwarrior[4] 
established between 172.31.xxx.xxx[vpn1.xxx.com 
<http://vpn1.xxx.com>]...109.230.xxx.xx[192.168.1.103]


May 11 07:57:46 vpn-server charon: 11[IKE] peer requested virtual IP %any

May 11 07:57:46 vpn-server charon: 11[CFG] reassigning offline lease 
to 'houmie'


May 11 07:57:46 vpn-server charon: 11[IKE] assigning virtual IP 
10.10.10.1 to peer 'houmie'


May 11 07:57:46 vpn-server charon: 11[IKE] peer requested virtual IP %any6

May 11 07:57:46 vpn-server charon: 11[IKE] no virtual IP found for 
%any6 requested by 'houmie'


May 11 07:57:46 vpn-server charon: 11[IKE] CHILD_SA roadwarrior{2} 
established with SPIs caa2d799_i 8f5ab10c_o and TS 0.0.0.0/0 
<http://0.0.0.0/0> === 10.10.10.1/32 <http://10.10.10.1/32>


May 11 07:57:46 vpn-server charon: 11[ENC] generating IKE_AUTH 
response 5 [ AUTH CPRP(ADDR DNS DNS) SA TSi TSr N(MOBIKE_SUP) 
N(NO_ADD_ADDR) ]


May 11 07:57:46 vpn-server charon: 11[NET] sending packet: from 
172.31.xxx.xxx[4500] to 109.230.xxx.xx[1024] (256 bytes)











On 10 May 2018 at 21:52, John Connett <j...@skylon.demon.co.uk 
<mailto:j...@skylon.demon.co.uk>> wrote:


Don't know if this might be related:


https://support.microsoft.com/en-gb/help/4103721/windows-10-update-kb4103721

<https://support.microsoft.com/en-gb/help/4103721/windows-10-update-kb4103721>

"Addresses an issue that prevents certain VPN apps from working on
builds of Windows 10, version 1803. These apps were developed
using an SDK version that precedes Windows 10, version 1803, and
use the public RasSetEntryProperties API".

Regards
--
John Connett


    *From:* Users <users-boun...@lists.strongswan.org
<mailto:users-boun...@lists.strongswan.org>> on behalf of Jafar
Al-Gharaibeh <ja...@atcorp.com <mailto:ja...@atcorp.com>>
*Sent:* 10 May 2018 21:33
*To:* Houman
*Cc:* users@lists.strongswan.org <mailto:users@lists.strongswan.org>
*Subject:* Re: [strongSwan] Sudden issues with Windows 10 clients
Hi Houman,

 Similar to the Windows problem you had earlier, you don't have
the correct combination of configured algorithms. look at the logs:

    May 10 20:26:48 vpn-server charon: 12[IKE

Re: [strongSwan] Sudden issues with Windows 10 clients

[Jafar Al-Gharaibeh]

ay 10 20:10:58 vpn-server charon: 12[ENC] generating IKE_AUTH 
response 5 [ AUTH CPRP(ADDR DNS DNS) SA TSi TSr N(MOBIKE_SUP) 
N(NO_ADD_ADDR) ]


May 10 20:10:58 vpn-server charon: 12[NET] sending packet: from 
172.31.xxx.xxx[4500] to 88.98.xxx.xxx[39065] (228 bytes)



The config that is working for my iphone is this:

config setup

  strictcrlpolicy=yes

  uniqueids=never

conn roadwarrior

  auto=add

  compress=no

  type=tunnel

  keyexchange=ikev2

  fragmentation=yes

  forceencaps=yes

ike=aes256gcm16-sha256-ecp521,aes256-sha256-ecp384,aes256-3des-sha1-modp1024!

esp=aes256gcm16-sha256,aes256-3des-sha256-sha1!

  dpdaction=clear

  dpddelay=180s

  rekey=no

  left=%any

  leftid=@vpn1.xxx.com <http://vpn1.xxx.com>

  leftcert=cert.pem

  leftsendcert=always

  leftsubnet=0.0.0.0/0 <http://0.0.0.0/0>

  right=%any

  rightid=%any

  rightauth=eap-mschapv2

  eap_identity=%any

  rightdns=8.8.8.8,8.8.4.4

  rightsourceip=10.10.10.0/24 <http://10.10.10.0/24>

  rightsendcert=never


Please let me know if you see any obvious problem. But I strongly 
believe they have blocked the IKEV2 traffic...


Many Thanks,
Houman



On 9 May 2018 at 15:40, Jafar Al-Gharaibeh <ja...@atcorp.com 
<mailto:ja...@atcorp.com>> wrote:


Hi Tobias,

    Thanks for the correction.   What I meant to say is :

             The PRF algorithm is derived from the integrity
algorithm, but only if a DH group is also configured.

 Correct?

Regards,
Jafar


On 5/9/2018 2:21 AM, Tobias Brunner wrote:

Hi Jafar,

No need to configure a prf, it is already assumed when you
configured a DH group; so you can drop prfsha256.

Small correction, the PRF algorithm, if not configured
explicitly, is
not derived from the DH group, but the integrity algorithm, in
this case
sha256.

Regards,
Tobias

Re: [strongSwan] Sudden issues with Windows 10 clients

[Jafar Al-Gharaibeh]

Hi Tobias,

    Thanks for the correction.   What I meant to say is :

             The PRF algorithm is derived from the integrity algorithm, 
but only if a DH group is also configured.


 Correct?

Regards,
Jafar

On 5/9/2018 2:21 AM, Tobias Brunner wrote:

Hi Jafar,


  No need to configure a prf, it is already assumed when you
configured a DH group; so you can drop prfsha256.

Small correction, the PRF algorithm, if not configured explicitly, is
not derived from the DH group, but the integrity algorithm, in this case
sha256.

Regards,
Tobias

Re: [strongSwan] Sudden issues with Windows 10 clients

[Jafar Al-Gharaibeh]

Houman,

 No need to configure a prf, it is already assumed when you 
configured a DH group; so you can drop prfsha256. And as Christian 
suggested, if all your clients support strong encryption  drop all weak 
algorithms/proposals from  the server end i.e 3des, sha1, modp1024. I 
can't believe that  Microsoft still in 2018 offer these as the default 
options and expects users to go tinker with obscured registery keys  to 
enable stronger options.


For ESP, I'd connect the Windows client and see what the offered 
proposals in the logs at the server side, just as you did with ike. You 
can then limit the proposals at the server end to the good ones. If I 
remember well, AES256 was an option, but esp didn't allow a DH group so 
you might need to drop that, but I could be wrong.


Cheers,
Jafar


On 5/8/2018 1:55 PM, Houman wrote:

Thank you both Christian and Jafar for the clear proposals.

So yes, if I wanted to support Windows 10, iOS/OSX and Linux with the 
stronger set of encryption. Do I set *aes256-sha256-prfsha256-modp2048 
*into *ike* only?  Or both in *ike* and *esp*?


This part wasn't quite clear to me.

Yeah, I have already set [NegotiateDH2048_AES256] in Windows 10.

Many Thanks,
Houman



On 8 May 2018 at 08:40, Christian Salway <christian.sal...@naimuri.com 
<mailto:christian.sal...@naimuri.com>> wrote:


The problem with Windows (10 at least) is that it offers the
weakest ciphers first, so you should remove sha1 and 3des.

The minimum proposals you should have and which are compatible
with Windows 10, OSX, IOS and Linux are the following.

*proposals = aes256-sha256-prfsha256-modp2048-modp1024*

Although I would recommend adding the Windows 10 registry key
[NegotiateDH2048_AES256] to use strong ciphers and then you can
remove MODP1024


<http://www.naimuri.com>


On 7 May 2018, at 15:50, Jafar Al-Gharaibeh <ja...@atcorp.com
<mailto:ja...@atcorp.com>> wrote:

Houman,

  The Windows client proposals do not match your configured
proposals. Your Windows client expect DG group 15 (MODP2048),
where as you have:

aes256-3des-sha1-modp1024

change that to:

aes256-3des-sha1-modp2048

I'd also add sha256 at least before sha1 (deemed insecure). If
you still have other clients expecting modp1024, make it:

aes256-3des-sha256-sha1-modp2048-modp1024

That should get you covered.

Regards,
Jafar


On 5/7/2018 8:17 AM, Houman wrote:

Hello,

Until a week ago a user with Windows 10 had no issue connecting
to the StrongSwan server. But now out of the blue, he can't
connect to the StrongSwan server anymore.

The log on the server is:

May  7 12:31:06 vpn-p1 charon: 08[IKE] received proposals
inacceptable
May  7 12:31:06 vpn-p1 charon: 08[ENC] generating IKE_SA_INIT
response 0 [ N(NO_PROP) ]
May  7 12:31:06 vpn-p1 charon: 08[NET] sending packet: from
xxx.x.xx.92[500] to 91.98.xxx.xxx[500] (36 bytes)
May  7 12:32:09 vpn-p1 systemd[1]: Started Session 35 of user root.
May  7 12:46:21 vpn-p1 systemd[1]: Starting Cleanup of Temporary
Directories...
May  7 12:46:21 vpn-p1 systemd-tmpfiles[7016]:
[/usr/lib/tmpfiles.d/var.conf:14] Duplicate line for path
"/var/log", ignoring.
May  7 12:46:21 vpn-p1 systemd[1]: Started Cleanup of Temporary
Directories.
May  7 13:00:13 vpn-p1 systemd[1]: Starting Certbot...
May  7 13:00:13 vpn-p1 systemd[1]: Started Certbot.
May  7 13:08:20 vpn-p1 systemd[1]: Started Session 36 of user root.
May  7 13:11:27 vpn-p1 charon: 12[NET] received packet: from
91.98.xxx.xxx[500] to xxx.x.xx.92[500] (624 bytes)
May  7 13:11:27 vpn-p1 charon: 12[ENC] parsed IKE_SA_INIT
request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) V V V V ]
May  7 13:11:27 vpn-p1 charon: 12[IKE] received MS NT5
ISAKMPOAKLEY v9 vendor ID
May  7 13:11:27 vpn-p1 charon: 12[IKE] received MS-Negotiation
Discovery Capable vendor ID
May  7 13:11:27 vpn-p1 charon: 12[IKE] received
Vid-Initial-Contact vendor ID
May  7 13:11:27 vpn-p1 charon: 12[ENC] received unknown vendor
ID: 01:52:8b:bb:c0:06:96:12:18:49:ab:9a:1c:5b:2a:51:00:00:00:02
May  7 13:11:27 vpn-p1 charon: 12[IKE] 91.98.xxx.xxx is
initiating an IKE_SA
May  7 13:11:27 vpn-p1 charon: 12[CFG] received proposals:
IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048,
IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048,
IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_2048
May  7 13:11:27 vpn-p1 charon: 12[CFG] configured proposals:
IKE:AES_GCM_16_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_521,
IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_384,
IKE:AES_CBC_256/3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
May  7 13:11:27 vpn-p1 charon: 12[IKE] remote host is behind NAT
May  7 13:11:27 vpn-p1 charon: 12[IKE] received proposals
   

Re: [strongSwan] policy mismatch

[Jafar Al-Gharaibeh]

[1] worked for me in the past. I also came across [2] which allows more 
options but I couldn't get that to work. I changed the 
encryption/integrity algorithms. I restated windows, but the proposal 
sent by windows didn't seem to be affected by changes using [2].


Regards,
Jafar

[1] 
https://wiki.strongswan.org/projects/strongswan/wiki/Windows7#AES-256-CBC-and-MODP2048

[2] https://wiki.strongswan.org/projects/strongswan/wiki/WindowsVista


On 5/2/2018 3:40 AM, ccsalway wrote:

Thats what I meant by using stronger ciphers and adding the two DHG’s in the 
proposal.



On 2 May 2018, at 09:37, Tobias Brunner  wrote:

Hi Christian,


For the record, the IKE proposals that work for OSX and Windows (with
weak or strong ciphers enabled) is as follows

aes256-sha256-prfsha256-modp2048-modp1024

If you want to use a stronger DH group with Windows clients see [1].

Regards,
Tobias

[1]
https://wiki.strongswan.org/projects/strongswan/wiki/Windows7#AES-256-CBC-and-MODP2048

Re: [strongSwan] Tunnel established, but 'no acceptable ENCRYPTION_ALGORITHM found'

[Jafar Al-Gharaibeh]

Very Helpful,

Thanks,
Jafar

On 5/2/2018 3:22 AM, Tobias Brunner wrote:

Hi Jafar,


      Makes sense, but just to understand what is going on and know how
to read the logs, are you saying that each "ESP:" prefix signifies a
separate proposal that is parsed independently (log below)? A single
proposal might have one or more algorithms separated by slashes, correct ?

Yes, they each are separate proposals that were all contained in the
same SA payload sent by the client (see section 3.3 of RFC 7296 [1] for
an illustration).  During proposal selection they are treated separately
(i.e. we can't pick and choose algorithms from different proposals).
And for each transform type (encryption, integrity, DH etc.) multiple
algorithms may be contained in each proposal (in the log and status
output separated with /).

When configuring it you'd separate proposals with commas and the
algorithms with dashes. For instance,


ESP:AES_GCM_16_128/AES_GCM_16_256/CHACHA20_POLY1305_256/NO_EXT_SEQ,
ESP:AES_CBC_128/HMAC_SHA2_256_128/NO_EXT_SEQ,
ESP:AES_CBC_256/HMAC_SHA2_384_192/NO_EXT_SEQ,
ESP:AES_CBC_128/AES_CBC_192/AES_CBC_256/HMAC_SHA1_96/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/NO_EXT_SEQ

would be configured like this in swanctl.conf:

esp_proposals =
aes128gcm16-aes256gcm16-chacha20poly1305,aes128-sha256,aes256-sha384,aes128-aes192-aes256-sha1-sha256-sha384-sha512

Regards,
Tobias

[1] https://tools.ietf.org/html/rfc7296#section-3.3

Re: [strongSwan] policy mismatch

[Jafar Al-Gharaibeh]

Good to know!
Thanks,
Jafar

On 5/2/2018 3:11 AM, Tobias Brunner wrote:

AFAIK, strongSwan accepts  the first  proposed algorithm that is also
configured configured locally.

The behavior depends on the charon.prefer_configured_proposals setting
(enabled by default).  If enabled, the first local proposal accepted by
the client's proposals is used (similarly for the algorithms in the
proposals, where the local order is preferred), if it's disabled, the
first proposal sent by the client that is accepted the local proposals
will be selected (again, similar for the algorithms in the proposals).

Regards,
Tobias

Re: [strongSwan] policy mismatch

[Jafar Al-Gharaibeh]

The selection is not based on "best", but rather on the order of 
algorithms at the initiator side first and the responder side second.  
AFAIK, strongSwan accepts  the first  proposed algorithm that is also 
configured configured locally. The first algorithm proposed by windows 
and also accepted at your server is


Windows: "IKE:AES_GCM_16_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024"
strongSwan:   proposals = 
aes256gcm16-aes128gcm16-sha384-sha256-prfsha384-prfsha256-modp1024


If you want the better algorithm, then move it first in your windows 
configuration, or  change strongSwan to only accept the algorithms you 
prefer, i.e drop "-aes128gcm16"


proposals = aes256gcm16-sha384-sha256-prfsha384-prfsha256-modp1024

Regards,
Jafar

On 5/1/2018 4:59 PM, Christian Salway wrote:

*version: strongSwan 5.6.2*

When I connect from Windows 10, strongSwan replies with a different 
policy than requested, causing a policy mismatch


```
connections {
   default {
      version = 2
      send_cert = always
      encap = yes
      pools = pool1
      unique = replace
      proposals = 
aes256gcm16-aes128gcm16-sha384-sha256-prfsha384-prfsha256-modp1024

      local {
         id = vpnserver
         certs = vpnserver.crt
      }
      remote {
         auth = eap-mschapv2
         eap_id = %any
      }
      children {
         net {
            local_ts = 10.0.0.0/20
            inactivity = 1h
         }
      }
   }
}
```

When Windows connects, strongSwan gives it the wrong policy and hence 
Windows 10 reports a*policy match error*


May  1 21:53:12 08[CFG] *received proposals*: 
IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, 
IKE:3DES_CBC/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, 
IKE:3DES_CBC/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024, 
IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, 
IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, 
IKE:AES_CBC_128/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024, 
IKE:AES_CBC_192/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, 
IKE:AES_CBC_192/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, 
IKE:AES_CBC_192/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024, 
IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, 
IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, 
IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024, 
IKE:AES_GCM_16_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, 
IKE:AES_GCM_16_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, 
IKE:AES_GCM_16_128/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024, 
IKE:AES_GCM_16_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, 
IKE:AES_GCM_16_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, 
IKE:AES_GCM_16_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024
May  1 21:53:12 08[CFG] *configured proposals*: 
IKE:AES_GCM_16_256/AES_GCM_16_128/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_256/MODP_1024
May  1 21:53:12 08[CFG] selected proposal: 
IKE:*AES_GCM_16_128/PRF_HMAC_SHA2_256/MODP_1024*


Expected response (I'm guessing) 
*AES_GCM_16_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024 
*(although I dont know why it doesnt chose the better ciphers).

Re: [strongSwan] Tunnel established, but 'no acceptable ENCRYPTION_ALGORITHM found'

[Jafar Al-Gharaibeh]

Tobias,

    Makes sense, but just to understand what is going on and know how 
to read the logs, are you saying that each "ESP:" prefix signifies a 
separate proposal that is parsed independently (log below)? A single 
proposal might have one or more algorithms separated by slashes, correct ?


Thanks,
Jafar

received proposals: 
ESP:AES_GCM_16_128/AES_GCM_16_256/CHACHA20_POLY1305_256/NO_EXT_SEQ, 
ESP:AES_CBC_128/HMAC_SHA2_256_128/NO_EXT_SEQ, 
ESP:AES_CBC_256/HMAC_SHA2_384_192/NO_EXT_SEQ, 
ESP:AES_CBC_128/AES_CBC_192/AES_CBC_256/HMAC_SHA1_96/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/NO_EXT_SEQ




On 5/1/2018 3:08 AM, Tobias Brunner wrote:

Hi,


I see an error in the strongswan
logs and I'm not sure what is going on here, and what I should do to
correct this:

There is nothing to correct as the connection gets successfully
established.  If you have a closer look at the log you see that the
client sends not one, but four ESP proposals.  The first one contains
only AEAD algorithms (AES-GCM etc.), which won't match your configured
proposal, hence, the "no acceptable ENCRYPTION_ALGORITHM found" message.
  Then the second proposal is tried and that matches your configured
proposal and is selected.

Regards,
Tobias

Re: [strongSwan] Tunnel established, but 'no acceptable ENCRYPTION_ALGORITHM found'

[Jafar Al-Gharaibeh]

It is weird! As you pointed out, right after the ''no acceptable... " 
line, you have "proposal matches", and obviously that works.  What is  
your config config on the phone?


Sun Apr 29 15:47:19 2018 daemon.info : 06[CFG] selecting proposal:
Sun Apr 29 15:47:19 2018 daemon.info : 06[CFG]   no acceptable 
ENCRYPTION_ALGORITHM found

Sun Apr 29 15:47:19 2018 daemon.info : 06[CFG] selecting proposal:
Sun Apr 29 15:47:19 2018 daemon.info : 06[CFG]   proposal matches:
...

--Jafar



On 4/29/2018 3:40 PM, G. S. wrote:
I have an ikev2 roadwarrior setup with public key authentication 
between my android phone with strongswan android client, and my home 
router(WAN IP: host.dyndns.org, lan ip: 192.168.1.1) in gateway mode 
(running openwrt + strongSwan 5.6.2, Linux 4.14.34, armv7l). I can 
connect and transmit/receive data just fine between the roadwarrior - 
gateway - lan, and roadwarrior - gateway - internet.  I see an error 
in the strongswan logs and I'm not sure what is going on here, and 
what I should do to correct this:



Sun Apr 29 15:47:19 2018 daemon.info : 06[CFG]   candidate 
"androidphone" with prio 15+3
Sun Apr 29 15:47:19 2018 daemon.info : 06[CFG] found matching child 
config "androidphone" with prio 18

Sun Apr 29 15:47:19 2018 daemon.info : 06[CFG] selecting proposal:
Sun Apr 29 15:47:19 2018 daemon.info : 06[CFG]   no acceptable 
ENCRYPTION_ALGORITHM found

...
...
...
Sun Apr 29 15:47:19 2018 daemon.info : 06[CFG] selected proposal: 
ESP:AES_CBC_128/HMAC_SHA2_256_128/NO_EXT_SEQ





Here is how I generated and signed the keys, my config, and full 
system log:


ipsec pki --gen --outform pem > caKey.pem
ipsec pki --self --in caKey.pem --dn "C=CA, O=none, CN=My-CA-Auth" 
--san="My-CA-Auth" --ca --outform pem > caCert.pem

ipsec pki --gen --outform pem > userKey.pem
ipsec pki --pub --in userKey.pem | ipsec pki --issue --cacert 
caCert.pem --cakey caKey.pem --dn "C=CA, O=none, CN=androidphone" 
--san "androidph...@host.dyndns.org"  --flag clientAuth --outform pem 
> userCert.pem

ipsec pki --gen --outform pem > serverKey.pem
ipsec pki --pub --in serverKey.pem | ipsec pki --issue --cacert 
caCert.pem --cakey caKey.pem --dn "C=CA, O=none, CN=host.dyndns.org" 
--san="host.dyndns.org" --flag serverAuth --outform pem > serverCert.pem





IPSEC.CONF

config setup
    charondebug="ike 2, knl 3, cfg 3"

conn %default
    ikelifetime=60m
    keylife=20m
    rekeymargin=3m
    keyingtries=1
    keyexchange=ikev2
    dpddelay=30
    dpdtimeout=120
    dpdaction=clear

conn androidphone
    mobike=yes
    leftfirewall=yes
    left=host.dyndns.org
    leftid="C=CA, O=none, CN=host.dyndns.org"
    leftsubnet=0.0.0.0/0,::/0
    leftcert=serverCert.pem
    rightcert=userCert.pem
    right=%any
    rightsourceip=10.10.10.2,fec3::/120
    rightid="C=CA, O=none, CN=androidphone"
    rightauth=pubkey
    leftauth=pubkey
    auto=start
    rightdns=192.168.1.1




SYSTEM LOG:

Sun Apr 29 15:47:19 2018 daemon.info : 14[NET] received packet: from 
25.142.133.53[24076] to 213.100.100.31[500] (704 bytes)
Sun Apr 29 15:47:19 2018 daemon.info : 14[ENC] parsed IKE_SA_INIT 
request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) 
N(REDIR_SUP) ]
Sun Apr 29 15:47:19 2018 daemon.info : 14[CFG] looking for an ike 
config for 213.100.100.31...25.142.133.53
Sun Apr 29 15:47:19 2018 daemon.info : 14[CFG] ike config match: 1052 
(213.100.100.31 25.142.133.53 IKEv2)
Sun Apr 29 15:47:19 2018 daemon.info : 14[CFG]   candidate: 
host.dyndns.org...%any, prio 1052
Sun Apr 29 15:47:19 2018 daemon.info : 14[CFG] found matching ike 
config: host.dyndns.org...%any with prio 1052
Sun Apr 29 15:47:19 2018 daemon.info : 14[IKE] 25.142.133.53 is 
initiating an IKE_SA
Sun Apr 29 15:47:19 2018 authpriv.info : 14[IKE] 25.142.133.53 is 
initiating an IKE_SA
Sun Apr 29 15:47:19 2018 daemon.info : 14[IKE] IKE_SA (unnamed)[5] 
state change: CREATED => CONNECTING

Sun Apr 29 15:47:19 2018 daemon.info : 14[CFG] selecting proposal:
Sun Apr 29 15:47:19 2018 daemon.info : 14[CFG]   proposal matches
Sun Apr 29 15:47:19 2018 daemon.info : 14[CFG] received proposals: 
IKE:AES_CBC_128/AES_CBC_192/AES_CBC_256/3DES_CBC/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/HMAC_SHA1_96/AES_XCBC_96/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_HMAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/CURVE_25519/MODP_3072/MODP_4096/MODP_8192/MODP_2048, 
IKE:AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256/CHACHA20_POLY1305_256/AES_GCM_12_128/AES_GCM_12_192/AES_GCM_12_256/AES_GCM_8_128/AES_GCM_8_192/AES_GCM_8_256/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_HMAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/CURVE_25519/MODP_3072/MODP_4096/MODP_8192/MODP_2048
Sun Apr 29 15:47:19 2018 daemon.info : 14[CFG] configured proposals: 

Re: [strongSwan] ssh and http through IPSec

[Jafar Al-Gharaibeh]

Hi Sujoy,

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


--Jafar


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

Hi Christopher,


 Thanks for the response. I want to access the CentOS IPSec server 
which is the having tunneling enable from other system through SSH.
In the mean time other OpenWRT client should also be able cur/wget 
through the tunnel. Both SSH and http fails while tunnel is established.



Tried with the following but doesn't works.
https://wiki.strongswan.org/issues/2351
https://serverfault.com/questions/601143/ssh-not-working-over-ipsec-tunnel-strongswan


Thanks
Sujoy


On Monday 05 March 2018 11:46 AM, Christopher Bachner wrote:

Hi Sujoy,

Do you route all traffic through the ipsec tunnel at the moment?

Or is your goal to access the CentOS sever through ipsec?

Cheers,

Christopher

On Mar 5, 2018 07:05, Sujoy <sujo...@mindlogicx.com> wrote:

Hi Jafar,

 I have successfully establish connection with tunneling between
OpenWRT client and CentOS as StrongSwan server. Now I am facing
one issue. How to enable ssh and http through IPSec tunnel in
StrongSwan.



Thanks
Sujoy

On Friday 23 February 2018 09:05 PM, Jafar Al-Gharaibeh wrote:

Sujoy,

You have to send me the logs from both ends. It is hard to
know what is the problem with no logs.

--Jafar

On 2/21/2018 8:58 AM, Sujoy wrote:

Thanks Jafar, for giving this information. Please let me
know if anything else is required. The client OS is
Openwrt, so no logs are available.


*Server Config*

config setup
    charondebug="ike 3, net 3, mgr 3, esp 3, chd 3,
dmn 3, cfg 3, knl 3"
    strictcrlpolicy=no
    uniqueids=no
conn %default
conn tunnel #
   left=%any
   right=%any
   ike=aes256-sha1-modp2048
   esp=aes256-sha1
   keyingtries=1
   keylife=20
   dpddelay=30s
   dpdtimeout=150s
   dpdaction=restart
   authby=psk
   auto=start
   keyexchange=ikev2
   type=tunnel

# /etc/ipsec.secrets - strongSwan IPsec secrets file
: PSK "XXX"



   [host@VPNTEST ~]# firewall-cmd --list-all
FirewallD is not running
[host@VPNTEST ~]# sestatus
SELinux status: disabled
[host@VPNTEST ~]# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination



*Client config and status*

    config setup

    charondebug="ike 3, net 3, mgr 3, esp 3, chd 3,
dmn 3, cfg 3, knl 3"
    strictcrlpolicy=no
    uniqueids=no
conn %default
conn tunnel #
   left=%any
   #right=192.168.10.40
   right=182.156.253.59
   ike=aes256-sha1-modp2048
   esp=aes256-sha1
   keyingtries=1
   keylife=20
   dpddelay=30s
   dpdtimeout=150s
   dpdaction=restart
   authby=psk
   auto=start
   keyexchange=ikev2
   type=tunnel

# /etc/ipsec.secrets - strongSwan IPsec secrets file
: PSK "XXX"


root@Device_BD2009:~# ipsec statusall
no files found matching '/etc/strongswan.d/*.conf'
Status of IKE charon daemon (strongSwan 5.3.3, Linux
3.10.49, mips):
  uptime: 22 minutes, since Feb 21 14:31:43 2018
  malloc: sbrk 196608, mmap 0, used 157560, free 39048
  worker threads: 11 of 16 idle, 5/0/0/0 working, job
queue: 0/0/0/0, scheduled: 5
  loaded plugins: charon aes des rc2 sha1 sha2 md5 random
nonce x509 revocation constraints pubkey pkcs1 pkcs7
pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp
xcbc cmac hmac curl attr kernel-netlink resolve
socket-default stroke updown eap-identity eap-md5
xauth-generic
Listening IP addresses:
  192.168.20.100
  192.168.10.1
  fd70:5f2:3744::1
Connections:
  tunnel:  %any...X.X.X.X  IKEv2, dpddelay=30s
  tunnel:   local:  use

Re: [strongSwan] Configuration Error: received message ID 0, expected 1. Ignored

[Jafar Al-Gharaibeh]

From the logs, box1 received "Auth Failed" response from box 2. You 
have to inspect the logs on box 2 to see why it is failing to 
authenticate box 1.


--Jafar


On 2/23/2018 4:26 AM, Anne Ambe wrote:

Hi,
I have been struggling for the past week to configure an ipsec tunnel 
between two fedora19 boxes using strongswan version  5.1.3
I tried to follow the configuration for net2net with PSK found on this 
link 
https://www.strongswan.org/testing/testresults/ikev2/net2net-psk/index.html.

Here is my configuration:

*Box1: *
*ipsec.conf:

*config setup
conn %default
    ikelifetime=60m
    keylife=20m
    rekeymargin=3m
    keyingtries=1
    authby=secret
    keyexchange=ikev2
    mobike=no

conn fed1_fed2
    left=192.168.aa.bb
    leftsubnet=192.168.x.0/24
    leftid=@fed1
    leftfirewall=no
    right=192.168.aa.cc
    rightsubnet=192.168.y.0/24
    rightid=@fed2
    auto=add*
Box 2:

ipsec.conf

*config setup*
*conn %default
    ikelifetime=60m
    keylife=20m
    rekeymargin=3m
    keyingtries=1
    authby=secret
    keyexchange=ikev2
    mobike=no

conn fed1_fed2
    left=192.168.aa.cc
    leftsubnet=192.168.y.0/24
    leftid=@fed2
    leftfirewall=no
    right=192.168.aa.bb
    rightsubnet=192.168.x.0/24
    rightid=@fed1
    auto=add*

Common on box1 and box 2

strongswan.conf
*charon {
  load = random nonce aes sha1 sha2 gmp curve25519 hmac stroke 
kernel-netlink socket-default updown

  multiple_authentication = no
}*
*
**ipsec.secret
**@fed1 @fed2 : PSK 0sblahblahblah**

when i try to bring  up this tunnel from box1 this i get this error
**initiating IKE_SA fed1_fed2[1] to 192.168.aa.cc
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
sending packet: from 192.168.aa.bb[500] to 192.168.aa.cc[500] (652 bytes)
received packet: from 192.168.aa.cc[500] to 192.168.aa.bb[500] (376 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No V ]
received unknown vendor ID: 4f:45:76:79:5c:6b:67:7a:57:71:5c:73
authentication of 'fed1' (myself) with pre-shared key
establishing CHILD_SA fed1_fed2
generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi 
TSr N(EAP_ONLY) ]

sending packet: from 192.168.aa.bb[500] to 192.168.aa.cc[500] (364 bytes)
received packet: from 192.168.aa.cc[500] to 192.168.aa.bb[500] (36 bytes)
parsed IKE_SA_INIT response 0 [ N(AUTH_FAILED) ]
*received message ID 0, expected 1. Ignored***

**I am very new to strongswan.Please any guidance will be very much 
appreciated.**


Thanks

Anne
**

 
	Virus-free. www.avast.com 
 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: [strongSwan] parsed CREATE_CHILD_SA response 2 [ N(TS_UNACCEPT) ], received TS_UNACCEPTABLE notify, no CHILD_SA built

[Jafar Al-Gharaibeh]

Sujoy,

   It is really hard to help you if don't give us full information only 
sending us one picture at a time. Please use test files, they are easier 
to navigate than screen shots. Your last question below is a repeat to a 
question that I answered before.  If you want proper diagnose of the 
problem please send the configuration files,logs, routing table at both 
ends. see 8 at:


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

Make sure to increase the debug level in your ipsec.conf files at both 
ends, something like:


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


Regards,
Jafar


On 2/20/2018 8:00 AM, Sujoy wrote:

Hi Jafar,

I am able to establish tunnel when I try to connect from LAN IP. But 
with same configuration(Firewall setting) and same OS version it 
failed to establish tunnel with *nated public IP*.


What means parsed "failed to establish CHILD_SA, keeping IKE_SA". 
Please let me know if you have any idea regarding this issue.

Re: [strongSwan] received TS_UNACCEPTABLE notify, no CHILD_SA built

[Jafar Al-Gharaibeh]

On 2/16/2018 3:39 AM, Sujoy wrote:


The config file is same but then also it failed by saying "unable to 
install inbound and outbound IPsec SA (SAD) in kernel failed to 
establish CHILD_SA, keeping IKE_SA".




It is failing with the error "IPsec SA: unsupported mode". That means 
transport (USE_TRANSP  one line above) mode is not supported. This is 
due to using kernel-libipsec plugin (look at the loaded plugins list) 
which  doesn't not implement transport mode as far as I  know. Either 
disable that plugin or switch back to tunnel mode.

Re: [strongSwan] Scepclien failed to generate certificate

[Jafar Al-Gharaibeh]

I would turn on debugging and see what is happening.
Add "*--debug*/level/" to your command. The highest debug level is 4.

--Jafar


On 2/14/2018 1:46 AM, Boris Levin wrote:

Hi,

Im new to scepclient feature, im trying to get certificate and 
currently with no success.


im using the exmples provided in scepclient man:

ipsec scepclient --out caCert --url * -f - finishes 
successfully and generates 3 cert files under cacerts dir.



ipsec scepclient --out pkcs1=localKey.der --out cert==localCert.der 
--dn 'C=CH, CN=John Doe' -k 2048 -p password--url ** --in 
cacert-enc=caCert-ra-2.der --in cacert-sig=caCert-ra-1.der -f


this command hangs on:

*building pkcs7 request*
*
*
what am i missing?
*
*
note: im building my kernel from sources suing buildroot.

BR.

--

Re: [strongSwan] pki --verify Command

[Jafar Al-Gharaibeh]

Just to be clear, please note the behavior I described below is not 
limited to  pki --verify dir, or even pki --verify. The daemon itself 
behaves the same way. It doesn't use the local crl if a url is embedded 
in the certificate itself.


--Jafar


On 2/12/2018 9:28 AM, Jafar Al-Gharaibeh wrote:

Tobias,

 I've just tested  the pki-verify-dirs branch, it works perfectly. 
Thank you again.


  I noticed when testing that if the certificate has a crl uri, pki 
verify only uses that even if I supply a --crl command option.



pki --verify --in /etc/ipsec.d/certs/mars_revoked.crt 
--cacert=/etc/ipsec.d/cacerts/ --crl=/etc/ipsec.d/crls/crr.crl

  using certificate "C=US, O=ATC, CN=mars"
  using trusted intermediate ca certificate "C=US, O=ATC, CN=CRRMaster3"
checking certificate status of "C=US, O=ATC, CN=mars"
  fetching crl from 'http://192.168.225.142/crls/crr.crl' ...
crl fetching failed
certificate status is not available
  using trusted intermediate ca certificate "C=US, O=ATC, CN=CRRMaster2"
checking certificate status of "C=US, O=ATC, CN=CRRMaster3"
certificate status is not available
  using trusted ca certificate "C=US, O=ATCorp, CN=CRRMaster"
checking certificate status of "C=US, O=ATC, CN=CRRMaster2"
certificate status is not available
  reached self-signed root ca with a path length of 2
certificate trusted, lifetimes valid, revocation checking failed


If I place the the crl on the server, it works by pulling the crl 
directly from there:


pki --verify --in /etc/ipsec.d/certs/mars_revoked.crt 
--cacert=/etc/ipsec.d/cacerts/ --crl=/etc/ipsec.d/crls/crr.crl

  using certificate "C=US, O=ATC, CN=mars"
  using trusted intermediate ca certificate "C=US, O=ATC, CN=CRRMaster3"
checking certificate status of "C=US, O=ATC, CN=mars"
  fetching crl from 'http://192.168.225.142/crls/crr.crl' ...
  using trusted intermediate ca certificate "C=US, O=ATC, CN=CRRMaster2"
  reached self-signed root ca with a path length of 0
  using trusted certificate "C=US, O=ATC, CN=CRRMaster3"
  crl correctly signed by "C=US, O=ATC, CN=CRRMaster3"
  crl is valid: until Feb 14 10:37:00 2018
certificate was revoked on Jan 15 16:37:16 UTC 2018, reason: 
affiliation changed

certificate untrusted


If I omit the crl option completely no crl check takes place as expected:

pki --verify --in /etc/ipsec.d/certs/mars_revoked.crt 
--cacert=/etc/ipsec.d/cacerts/

  using certificate "C=US, O=ATC, CN=mars"
  using trusted intermediate ca certificate "C=US, O=ATC, CN=CRRMaster3"
  using trusted intermediate ca certificate "C=US, O=ATC, CN=CRRMaster2"
  using trusted ca certificate "C=US, O=ATCorp, CN=CRRMaster"
  reached self-signed root ca with a path length of 2
certificate trusted, lifetimes valid


The crl command line options forces a crl check but the locally 
provided crl is completely ignored even though it is the same crl on 
the server.

Is that to be expected?

Thank you in advance
Jafar






On 2/12/2018 8:43 AM, Jafar Al-Gharaibeh wrote:

Hi Tobias,

On 2/12/2018 8:34 AM, Tobias Brunner wrote:
I did write a script that does that but I thought it is very 
inefficient
since you have to sweep through CAs/CRLs with pki --print to figure 
out

the correct chain in order to use them with pki --verify.

You can just pass it all the CA certs/CRLs you (or rather the daemon)
trust.  Unless you have e.g. configs with CA cert constraints there is
not really a need to pass the exact chain to figure out whether a
certificate is valid and trusted by the daemon.

Good to know!




Thanks for
letting me know abot pki-verify-dirs. Sounds like what I'm looking 
for.

I wish I knew it exists before wasting time on scripting :-).

It didn't, I quickly put that together this morning :-)


Well, I initially assumed it did, but when I looked at the branches I 
have locally I didn't find it. I knew you've must just added it. 
thanks! :-)



Is that branch going to be merged any time soon?

Probably not with the upcoming release, but maybe the next one.

Now that I know you've just added it, I see why it is not yet in! :-)

Regards,
Jafar

Re: [strongSwan] pki --verify Command

[Jafar Al-Gharaibeh]

Tobias,

 I've just tested  the pki-verify-dirs branch, it works perfectly. 
Thank you again.


  I noticed when testing that if the certificate has a crl uri, pki 
verify only uses that even if I supply a --crl command option.



pki --verify --in /etc/ipsec.d/certs/mars_revoked.crt 
--cacert=/etc/ipsec.d/cacerts/ --crl=/etc/ipsec.d/crls/crr.crl

  using certificate "C=US, O=ATC, CN=mars"
  using trusted intermediate ca certificate "C=US, O=ATC, CN=CRRMaster3"
checking certificate status of "C=US, O=ATC, CN=mars"
  fetching crl from 'http://192.168.225.142/crls/crr.crl' ...
crl fetching failed
certificate status is not available
  using trusted intermediate ca certificate "C=US, O=ATC, CN=CRRMaster2"
checking certificate status of "C=US, O=ATC, CN=CRRMaster3"
certificate status is not available
  using trusted ca certificate "C=US, O=ATCorp, CN=CRRMaster"
checking certificate status of "C=US, O=ATC, CN=CRRMaster2"
certificate status is not available
  reached self-signed root ca with a path length of 2
certificate trusted, lifetimes valid, revocation checking failed


If I place the the crl on the server, it works by pulling the crl 
directly from there:


pki --verify --in /etc/ipsec.d/certs/mars_revoked.crt 
--cacert=/etc/ipsec.d/cacerts/ --crl=/etc/ipsec.d/crls/crr.crl

  using certificate "C=US, O=ATC, CN=mars"
  using trusted intermediate ca certificate "C=US, O=ATC, CN=CRRMaster3"
checking certificate status of "C=US, O=ATC, CN=mars"
  fetching crl from 'http://192.168.225.142/crls/crr.crl' ...
  using trusted intermediate ca certificate "C=US, O=ATC, CN=CRRMaster2"
  reached self-signed root ca with a path length of 0
  using trusted certificate "C=US, O=ATC, CN=CRRMaster3"
  crl correctly signed by "C=US, O=ATC, CN=CRRMaster3"
  crl is valid: until Feb 14 10:37:00 2018
certificate was revoked on Jan 15 16:37:16 UTC 2018, reason: affiliation 
changed

certificate untrusted


If I omit the crl option completely no crl check takes place as expected:

pki --verify --in /etc/ipsec.d/certs/mars_revoked.crt 
--cacert=/etc/ipsec.d/cacerts/

  using certificate "C=US, O=ATC, CN=mars"
  using trusted intermediate ca certificate "C=US, O=ATC, CN=CRRMaster3"
  using trusted intermediate ca certificate "C=US, O=ATC, CN=CRRMaster2"
  using trusted ca certificate "C=US, O=ATCorp, CN=CRRMaster"
  reached self-signed root ca with a path length of 2
certificate trusted, lifetimes valid


The crl command line options forces a crl check but the locally provided 
crl is completely ignored even though it is the same crl on the server.

Is that to be expected?

Thank you in advance
Jafar






On 2/12/2018 8:43 AM, Jafar Al-Gharaibeh wrote:

Hi Tobias,

On 2/12/2018 8:34 AM, Tobias Brunner wrote:
I did write a script that does that but I thought it is very 
inefficient

since you have to sweep through CAs/CRLs with pki --print to figure out
the correct chain in order to use them with pki --verify.

You can just pass it all the CA certs/CRLs you (or rather the daemon)
trust.  Unless you have e.g. configs with CA cert constraints there is
not really a need to pass the exact chain to figure out whether a
certificate is valid and trusted by the daemon.

Good to know!




Thanks for
letting me know abot pki-verify-dirs. Sounds like what I'm looking for.
I wish I knew it exists before wasting time on scripting :-).

It didn't, I quickly put that together this morning :-)


Well, I initially assumed it did, but when I looked at the branches I 
have locally I didn't find it. I knew you've must just added it. 
thanks! :-)



Is that branch going to be merged any time soon?

Probably not with the upcoming release, but maybe the next one.

Now that I know you've just added it, I see why it is not yet in! :-)

Regards,
Jafar

Re: [strongSwan] pki --verify Command

[Jafar Al-Gharaibeh]

Hi Tobias,

On 2/12/2018 8:34 AM, Tobias Brunner wrote:

I did write a script that does that but I thought it is very inefficient
since you have to sweep through CAs/CRLs with pki --print to figure out
the correct chain in order to use them with pki --verify.

You can just pass it all the CA certs/CRLs you (or rather the daemon)
trust.  Unless you have e.g. configs with CA cert constraints there is
not really a need to pass the exact chain to figure out whether a
certificate is valid and trusted by the daemon.

Good to know!




Thanks for
letting me know abot pki-verify-dirs. Sounds like what I'm looking for.
I wish I knew it exists before wasting time on scripting :-).

It didn't, I quickly put that together this morning :-)


Well, I initially assumed it did, but when I looked at the branches I 
have locally I didn't find it. I knew you've must just added it. thanks! :-)



Is that branch going to be merged any time soon?

Probably not with the upcoming release, but maybe the next one.

Now that I know you've just added it, I see why it is not yet in! :-)

Regards,
Jafar

Re: [strongSwan] pki --verify Command

[Jafar Al-Gharaibeh]

Hi Tobias,

On 2/12/2018 6:37 AM, Tobias Brunner wrote:

Hi Jafar,


2- "pki --verify --in certfile "  change it to use the "default" trust
store if no additional arguments  are supplied

There is no "default" trust store.  It very much depends on the
configuration backend used by the daemon from where certificates are
loaded automatically (if at all).


I understand the limitation here, that is why I quoted  "default"




Independent of the first choice above, we can add new commands line
options to point to the paths of where
CA/crls are stored:
3-"pki --verify --in certfile --capath path-to-ca's --crlpath path-to-crls

4-Or we can change existing options --cacert and --crl such the if the
supplied argument is a directory we treat them as such and load whatever
CA's CRLs needed for verification.

Both are simple enough to implement, the latter can be found in the
pki-verify-dirs branch.  I guess you could also just wrap calls to pki
--verify with a script and add --cacert/crl arguments as appropriate
(then you'd have more control if the CA certs and CRLs are e.g. stored
in the same directory with different file extensions).


I did write a script that does that but I thought it is very inefficient 
since you have to sweep through CAs/CRLs with pki --print to figure out 
the correct chain in order to use them with pki --verify.  Thanks for 
letting me know abot pki-verify-dirs. Sounds like what I'm looking for. 
I wish I knew it exists before wasting time on scripting :-).


Is that branch going to be merged any time soon?

Cheers,
Jafar

Re: [strongSwan] pki --verify Command

[Jafar Al-Gharaibeh]

Hi Andreas,

    Thank you for the clarification. I agree as a user you wouldn't 
need this very often, but it comes in handy in some cases.


If I were to implement this, do you thing the existing behavior should 
stay the same, unless you specify an additional argument?


So here are the options:

1- "pki --verify --in certfile"   stays the same if no additional 
arguments are supplied
2- "pki --verify --in certfile "  change it to use the "default" trust 
store if no additional arguments  are supplied


Independent of the first choice above, we can add new commands line 
options to point to the paths of where

CA/crls are stored:
3-"pki --verify --in certfile --capath path-to-ca's --crlpath path-to-crls

4-Or we can change existing options --cacert and --crl such the if the 
supplied argument is a directory we treat them as such and load whatever 
CA's CRLs needed for verification.


Personally I like 2 and 4 together. Thanks for any input in advance.

Regards,
Jafar

On 2/10/2018 2:09 AM, Andreas Steffen wrote:

Hi Jafar,

"pki --verify" is a command that is not intended to be used very often.

There are some rare cases where you might be in doubt whether a
certificate trust chain is correct and therefore might want to check
it out by usually increasing the debug level to 3.

Thus no effort has been taken to automate the verification process for
multi-level trust chains. You are free to propose and implement some
extensions to the "pki --verify" command.

Regards

Andreas

On 09.02.2018 22:10, Jafar Al-Gharaibeh wrote:

Hi,

    When invoking the "pki --verify" command, the user has to supply all
of the CA certs along the trust chain for the verification to take place
appropriately. This could be cumbersome if the trust chain is long
(>1).  If there are CRLs, they also have to be supplied as well. If the
certificate store is known (default location for example such as
/etc/ipsec.d/), shouldn't this all be done automatically? i.e, once you
know the certificate to be verified,  you can lookup the issuers all the
way up to the root CA with their associated CRLs. Is there any reason
why it doesn't work that way, other than nobody gotten around to doing it?

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

[strongSwan] pki --verify Command

[Jafar Al-Gharaibeh]

Hi,

   When invoking the "pki --verify" command, the user has to supply all 
of the CA certs along the trust chain for the verification to take place 
appropriately. This could be cumbersome if the trust chain is long 
(>1).  If there are CRLs, they also have to be supplied as well. If the 
certificate store is known (default location for example such as 
/etc/ipsec.d/), shouldn't this all be done automatically? i.e, once you 
know the certificate to be verified,  you can lookup the issuers all the 
way up to the root CA with their associated CRLs. Is there any reason 
why it doesn't work that way, other than nobody gotten around to doing it?


Regards,
Jafar

Re: [strongSwan] received TS_UNACCEPTABLE notify, no CHILD_SA built

[Jafar Al-Gharaibeh]

Can  you send the logs from the other side? the one that generates the 
TS_UNACCEPTABLE notify.


--Jafar

On 2/9/2018 12:31 AM, Sujoy wrote:


Hi Jafar/Noel,

What means " received TS_UNACCEPTABLE notify, no CHILD_SA built [IKE] 
failed to establish CHILD_SA, keeping IKE_SA" . Same error comes in 
the new installed Linux also.



root@client:~# ipsec up tunnel
initiating IKE_SA tunnel[1] to 192.168.10.40
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) 
N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]

sending packet: from 192.168.10.38[500] to 192.168.10.40[500] (464 bytes)
received packet: from 192.168.10.40[500] to 192.168.10.38[500] (456 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) 
N(HASH_ALG) N(MULT_AUTH) ]

remote host is behind NAT
no IDi configured, fall back on IP address
authentication of '192.168.10.38' (myself) with pre-shared key
establishing CHILD_SA tunnel{1}
generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi 
TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) 
N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) 
N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
sending packet: from 192.168.10.38[4500] to 192.168.10.40[4500] (368 
bytes)
received packet: from 192.168.10.40[4500] to 192.168.10.38[4500] (160 
bytes)
parsed IKE_AUTH response 1 [ IDr AUTH N(MOBIKE_SUP) N(ADD_4_ADDR) 
N(TS_UNACCEPT) ]

authentication of '192.168.10.40' with pre-shared key successful
IKE_SA tunnel[1] established between 
192.168.10.38[192.168.10.38]...192.168.10.40[192.168.10.40]

scheduling rekeying in 2642s
maximum IKE_SA lifetime 3182s
received TS_UNACCEPTABLE notify, no CHILD_SA built
failed to establish CHILD_SA, keeping IKE_SA
peer supports MOBIKE
establishing connection 'tunnel' failed



Feb  9 11:55:44 localhost charon: 14[NET] sending packet: from 
192.168.10.38[4500] to 192.168.10.40[4500] (368 bytes)
Feb  9 11:55:44 localhost charon: 16[NET] received packet: from 
192.168.10.40[4500] to 192.168.10.38[4500] (160 bytes)
Feb  9 11:55:44 localhost charon: 16[ENC] parsed IKE_AUTH response 1 [ 
IDr AUTH N(MOBIKE_SUP) N(ADD_4_ADDR) N(TS_UNACCEPT) ]
Feb  9 11:55:44 localhost charon: 16[IKE] authentication of 
'192.168.10.40' with pre-shared key successful
Feb  9 11:55:44 localhost charon: 16[IKE] IKE_SA tunnel[1] established 
between 192.168.10.38[192.168.10.38]...192.168.10.40[192.168.10.40]

Feb  9 11:55:44 localhost charon: 16[IKE] scheduling rekeying in 2642s
Feb  9 11:55:44 localhost charon: 16[IKE] maximum IKE_SA lifetime 3182s
*Feb  9 11:55:44 localhost charon: 16[IKE] received TS_UNACCEPTABLE 
notify, no CHILD_SA built**
**Feb  9 11:55:44 localhost charon: 16[IKE] failed to establish 
CHILD_SA, keeping IKE_SA*

Feb  9 11:55:44 localhost charon: 16[IKE] peer supports MOBIKE


Thanks
On Friday 09 February 2018 11:21 AM, Sujoy wrote:


Thanks Jafar, for the update. But after setting up without subnet and 
"type=tunnel or transport" it shows the same error "failed to 
establish CHILD_SA, keeping IKE_SA. What should be issue.



Thanks

On Friday 09 February 2018 01:53 AM, Jafar Al-Gharaibeh wrote:

Sujoy,

  Just to make sure everything is working OK. Try setting:

    left=192.168.10.40
    right=192.168.10.38

and

    left=192.168.10.38
    right=192.168.10.40

Comment out left/rightsubnet configs. They should default to the 
same IP addresses as left/right.


--Jafar


On 2/8/2018 12:26 AM, Sujoy wrote:
Hi Jafar,    Peer is also using strongswan 5.3.3. following is the 
configuration. We need tunnel because once it is connected in LAN 
we want to implement in WAN/Internet. Output of the 192.168.10.40 
is bellow.


    Config setup
    charondebug="all"
    uniqueids=yes
    strictcrlpolicy=yes
conn %default
conn tunnel #
    left=%any
    right=192.168.10.38
    rightsubnet=192.168.10.38/24
    ike=aes256-sha1-modp2048!
    esp=aes256-sha1-modp2048!
    keyingtries=1
    ikelifetime=1h
    lifetime=8h
    dpddelay=30
    #dpdtimeout=120
    dpdaction=restart
    authby=psk
    auto=route
    keyexchange=ikev2
    type=tunnel

root@server:~# ipsec statusall
Status of IKE charon daemon (strongSwan 5.3.3, Linux 
4.4.0-112-generic, x86_64):

  uptime: 114 minutes, since Feb 08 09:58:49 2018
  malloc: sbrk 2703360, mmap 0, used 513168, free 2190192
  worker threads: 7 of 16 idle, 5/0/4/0 working, job queue: 
0/0/0/0, scheduled: 5
  loaded plugins: charon aes kernel-libipsec des rc2 sha1 sha2 md5 
random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 
pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp xcbc cmac hmac 
curl attr kernel-netlink resolve socket-default stroke updown 
xauth-generic

Listening IP addresses:
  192.168.10.40
  10.8.0.1
Connections:
  tunnel:  %any...192.168.10.38  IKEv2, dpddelay=30s
  tunnel:   local:  uses pre-shared key authentication
  tunnel:   remote: 

Re: [strongSwan] received TS_UNACCEPTABLE notify, no CHILD_SA built

[Jafar Al-Gharaibeh]

Sujoy,

  Just to make sure everything is working OK. Try setting:

    left=192.168.10.40
    right=192.168.10.38

and

    left=192.168.10.38
    right=192.168.10.40

Comment out left/rightsubnet configs. They should default to the same IP 
addresses as left/right.


--Jafar


On 2/8/2018 12:26 AM, Sujoy wrote:
Hi Jafar,    Peer is also using strongswan 5.3.3. following is the 
configuration. We need tunnel because once it is connected in LAN we 
want to implement in WAN/Internet. Output of the 192.168.10.40 is bellow.


    Config setup
    charondebug="all"
    uniqueids=yes
    strictcrlpolicy=yes
conn %default
conn tunnel #
    left=%any
    right=192.168.10.38
    rightsubnet=192.168.10.38/24
    ike=aes256-sha1-modp2048!
    esp=aes256-sha1-modp2048!
    keyingtries=1
    ikelifetime=1h
    lifetime=8h
    dpddelay=30
    #dpdtimeout=120
    dpdaction=restart
    authby=psk
    auto=route
    keyexchange=ikev2
    type=tunnel

root@server:~# ipsec statusall
Status of IKE charon daemon (strongSwan 5.3.3, Linux 
4.4.0-112-generic, x86_64):

  uptime: 114 minutes, since Feb 08 09:58:49 2018
  malloc: sbrk 2703360, mmap 0, used 513168, free 2190192
  worker threads: 7 of 16 idle, 5/0/4/0 working, job queue: 0/0/0/0, 
scheduled: 5
  loaded plugins: charon aes kernel-libipsec des rc2 sha1 sha2 md5 
random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 
pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp xcbc cmac hmac curl 
attr kernel-netlink resolve socket-default stroke updown xauth-generic

Listening IP addresses:
  192.168.10.40
  10.8.0.1
Connections:
  tunnel:  %any...192.168.10.38  IKEv2, dpddelay=30s
  tunnel:   local:  uses pre-shared key authentication
  tunnel:   remote: [192.168.10.38] uses pre-shared key authentication
  tunnel:   child:  dynamic === 192.168.10.0/24 TUNNEL, 
dpdaction=restart

Security Associations (1 up, 0 connecting):
  tunnel[3]: ESTABLISHED 25 minutes ago, 
192.168.10.40[192.168.10.40]...192.168.10.38[192.168.10.38]
  tunnel[3]: IKEv2 SPIs: c1a42433ade9fa28_i a52cfea6d767c397_r*, 
pre-shared key reauthentication in 24 minutes
  tunnel[3]: IKE proposal: 
AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048




Thanks

On Wednesday 07 February 2018 09:06 PM, Jafar Al-Gharaibeh wrote:



On 2/7/2018 9:22 AM, Sujoy wrote:


Thanks Jafar, for the reply. But after removing subnet from the 
config also tunneling failed. Is there any issue with the version of 
strongswan 5.3.3. What means "TS_UNACCEPTABLE notify, no CHILD_SA built"


"TS_UNACCEPTABLE notify"  means the peer didn't like the proposed 
traffic selector.  The log shows that your IKE SA is up, so you don't 
have a problem there. I can't tell you what your rightsubnet should 
be unless you tell us more about the setup you have. What is your 
peer running? is it also strongSwan?


If you only want to encrypt traffic from  192.168.10.38  to 
192.168.10.40 and you don't have other subnets/hosts, you can switch 
the connection type to transport mode ("type=trasnport"). Both sides 
must agree on this. transport doesn't require left/rightsubnets.


--Jafar



   Config setup

    charondebug="all"
    uniqueids=yes
    strictcrlpolicy=yes
conn %default
conn tunnel #
    left=%any
    right=192.168.10.40
    ike=aes256-sha1-modp2048!
    esp=aes256-sha1-modp2048!
    keyingtries=1
    ikelifetime=1h
    lifetime=8h
    dpddelay=30
    #dpdtimeout=120
    dpdaction=restart
    authby=secret
    auto=route
    keyexchange=ikev2
    type=tunnel


root@client:~# ipsec up tunnel
initiating IKE_SA tunnel[1] to 192.168.10.40
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) 
N(NATD_D_IP) N(HASH_ALG) ]
sending packet: from 192.168.10.38[500] to 192.168.10.40[500] (448 
bytes)
received packet: from 192.168.10.40[500] to 192.168.10.38[500] (456 
bytes)
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) 
N(HASH_ALG) N(MULT_AUTH) ]

remote host is behind NAT
no IDi configured, fall back on IP address
authentication of '192.168.10.38' (myself) with pre-shared key
establishing CHILD_SA tunnel
generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi 
TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) 
N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) 
N(ADD_4_ADDR) N(MULT_AUTH) N(EAP_ONLY) ]
sending packet: from 192.168.10.38[4500] to 192.168.10.40[4500] (348 
bytes)
received packet: from 192.168.10.40[4500] to 192.168.10.38[4500] 
(156 bytes)
parsed IKE_AUTH response 1 [ IDr AUTH N(AUTH_LFT) N(MOBIKE_SUP) 
N(ADD_4_ADDR) N(TS_UNACCEPT) ]

authentication of '192.168.10.40' with pre-shared key successful
IKE_SA tunnel[1] established between 
192.168.10.38[192.168.10.38]...192.168.10.40[192.168.10.40]

scheduling reauthentication in 2819s
maximum IKE_

Re: [strongSwan] received TS_UNACCEPTABLE notify, no CHILD_SA built

[Jafar Al-Gharaibeh]

On 2/8/2018 2:53 AM, Tore Anderson wrote:

* Jafar Al-Gharaibeh <ja...@atcorp.com>


You can NOT have the least significant octet set to zero with a 32-bit
netmask

Sure you can. There is no fundamental difference between 192.168.10.0/32
and, say, 192.168.10.10/32. Both are equally valid, and both refer to a
single address/host.


Well, sure. We are not talking about whether this is a valid address or 
not from a pure theoretical perspective. That address doesn't get 
assigned to hosts generally. So, in the context of strongSwan config I 
doubt that what Sujoy wants unless he knows what he is doing which is 
something I pointed out in the email.


Thanks for pointing that out.
--Jafar



Tore

Re: [strongSwan] received TS_UNACCEPTABLE notify, no CHILD_SA built

[Jafar Al-Gharaibeh]

On 2/7/2018 9:22 AM, Sujoy wrote:


Thanks Jafar, for the reply. But after removing subnet from the config 
also tunneling failed. Is there any issue with the version of 
strongswan 5.3.3. What means "TS_UNACCEPTABLE notify, no CHILD_SA built"


"TS_UNACCEPTABLE notify"  means the peer didn't like the proposed 
traffic selector.  The log shows that your IKE SA is up, so you don't 
have a problem there. I can't tell you what your rightsubnet should be 
unless you tell us more about the setup you have. What is your peer 
running? is it also strongSwan?


If you only want to encrypt traffic from  192.168.10.38  to 
192.168.10.40 and you don't have other subnets/hosts, you can switch the 
connection type to transport mode ("type=trasnport"). Both sides must 
agree on this. transport doesn't require left/rightsubnets.


--Jafar



   Config setup

    charondebug="all"
    uniqueids=yes
    strictcrlpolicy=yes
conn %default
conn tunnel #
    left=%any
    right=192.168.10.40
    ike=aes256-sha1-modp2048!
    esp=aes256-sha1-modp2048!
    keyingtries=1
    ikelifetime=1h
    lifetime=8h
    dpddelay=30
    #dpdtimeout=120
    dpdaction=restart
    authby=secret
    auto=route
    keyexchange=ikev2
    type=tunnel


root@client:~# ipsec up tunnel
initiating IKE_SA tunnel[1] to 192.168.10.40
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) 
N(HASH_ALG) ]

sending packet: from 192.168.10.38[500] to 192.168.10.40[500] (448 bytes)
received packet: from 192.168.10.40[500] to 192.168.10.38[500] (456 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) 
N(HASH_ALG) N(MULT_AUTH) ]

remote host is behind NAT
no IDi configured, fall back on IP address
authentication of '192.168.10.38' (myself) with pre-shared key
establishing CHILD_SA tunnel
generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi 
TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) 
N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) 
N(MULT_AUTH) N(EAP_ONLY) ]
sending packet: from 192.168.10.38[4500] to 192.168.10.40[4500] (348 
bytes)
received packet: from 192.168.10.40[4500] to 192.168.10.38[4500] (156 
bytes)
parsed IKE_AUTH response 1 [ IDr AUTH N(AUTH_LFT) N(MOBIKE_SUP) 
N(ADD_4_ADDR) N(TS_UNACCEPT) ]

authentication of '192.168.10.40' with pre-shared key successful
IKE_SA tunnel[1] established between 
192.168.10.38[192.168.10.38]...192.168.10.40[192.168.10.40]

scheduling reauthentication in 2819s
maximum IKE_SA lifetime 3359s
*received TS_UNACCEPTABLE notify, no CHILD_SA built**
**failed to establish CHILD_SA, keeping IKE_SA*
received AUTH_LIFETIME of 2637s, scheduling reauthentication in 2097s
peer supports MOBIKE
establishing connection 'tunnel' failed


root@client:~# ipsec statusall
Status of IKE charon daemon *(strongSwan 5.3.3, Linux 
4.4.0-112-generic, x86_64)*:

  uptime: 2 minutes, since Feb 07 20:44:23 2018
  malloc: sbrk 2703360, mmap 0, used 519600, free 2183760
  worker threads: 7 of 16 idle, 5/0/4/0 working, job queue: 0/0/0/0, 
scheduled: 4
  loaded plugins: charon aes kernel-libipsec des rc2 sha1 sha2 md5 
random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 
pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp xcbc cmac hmac curl 
attr kernel-netlink resolve socket-default stroke updown xauth-generic

Listening IP addresses:
  192.168.10.38
  192.168.3.107

Connections:
  tunnel:  %any...192.168.10.40  IKEv2, dpddelay=30s
  tunnel:   local:  uses pre-shared key authentication
  tunnel:   remote: [192.168.10.40] uses pre-shared key authentication
  tunnel:   child:  dynamic === dynamic TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):
  tunnel[1]: ESTABLISHED 2 minutes ago, 
192.168.10.38[192.168.10.38]...192.168.10.40[192.168.10.40]
  tunnel[1]: IKEv2 SPIs: 175dcf9cdcf11b38_i* 9cc05896738a5e45_r, 
pre-shared key reauthentication in 32 minutes
  tunnel[1]: IKE proposal: 
AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048


Thanks

On Wednesday 07 February 2018 08:31 PM, Jafar Al-Gharaibeh wrote:

Sujoy,

  Are you sure about

   rightsubnet=192.168.10.0/32

 This subnet gets you nothing unless you know that it has a special 
meaning in the config that I'm not aware of. You can have the least 
significant octet set to zero with a 32-bit netmask. What is the 
rightsubnet that you are trying to protect? is it all 
192.168.10.0/24? or just  one host like 192.168.10.100?


--Jafar



On 2/7/2018 12:44 AM, Sujoy wrote:


Hi Noel,

Still cannot establish tunnel. logs doesn't show anything. Can 
someone help to solve this.


Client configuration

config setup

    charondebug="all"
    uniqueids=yes
    strictcrlpolicy=no
conn %default
conn tunnel #
    left=%any
    right=192.168.10.40
    rightsubnet=192.168.10.0/32
    ike=aes128-md5-modp1536
  

Re: [strongSwan] received TS_UNACCEPTABLE notify, no CHILD_SA built

[Jafar Al-Gharaibeh]

On 2/7/2018 9:01 AM, Jafar Al-Gharaibeh wrote:

You can have the least significant octet set to zero with a 32-bit netmask


Sorry, this should read:

You can NOT have the least significant octet set to zero with a 32-bit 
netmask

Re: [strongSwan] received TS_UNACCEPTABLE notify, no CHILD_SA built

[Jafar Al-Gharaibeh]

Sujoy,

  Are you sure about

   rightsubnet=192.168.10.0/32

 This subnet gets you nothing unless you know that it has a special 
meaning in the config that I'm not aware of. You can have the least 
significant octet set to zero with a 32-bit netmask. What is the 
rightsubnet that you are trying to protect? is it all 192.168.10.0/24? 
or just  one host like  192.168.10.100?


--Jafar



On 2/7/2018 12:44 AM, Sujoy wrote:


Hi Noel,

Still cannot establish tunnel. logs doesn't show anything. Can someone 
help to solve this.


Client configuration

config setup

    charondebug="all"
    uniqueids=yes
    strictcrlpolicy=no
conn %default
conn tunnel #
    left=%any
    right=192.168.10.40
    rightsubnet=192.168.10.0/32
    ike=aes128-md5-modp1536
    esp=aes128-sha1
    keyingtries=%forever
    ikelifetime=1h
    lifetime=8h
    dpddelay=30
    #dpdtimeout=120
    #dpdaction=restart
    authby=secret
    auto=start
    keyexchange=ikev2
    type=tunnel
    mobike=no
    #pfs=no
    reauth=no

Server setup

config setup

    charondebug="all"
    uniqueids=yes
    strictcrlpolicy=no
conn %default
conn tunnel #conn %default
conn tunnel #
    left=%any
    right=192.168.10.40
    rightsubnet=192.168.10.0/32
    ike=aes128-md5-modp1536
    esp=aes128-sha1
    keyingtries=%forever
    ikelifetime=1h
    lifetime=8h
    dpddelay=30
    #dpdtimeout=120
    #dpdaction=restart
    authby=secret
    auto=start
    keyexchange=ikev2
    type=tunnel
    mobike=no
    #pfs=no
    reauth=no


root@client:~# *ipsec up tunnel*
initiating IKE_SA tunnel[2] to 192.168.10.40
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) 
N(HASH_ALG) ]

sending packet: from 192.168.10.38[500] to 192.168.10.40[500] (1064 bytes)
received packet: from 192.168.10.40[500] to 192.168.10.38[500] (38 bytes)
parsed IKE_SA_INIT response 0 [ N(INVAL_KE) ]
peer didn't accept DH group MODP_2048, it requested MODP_1536
initiating IKE_SA tunnel[2] to 192.168.10.40
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) 
N(HASH_ALG) ]

sending packet: from 192.168.10.38[500] to 192.168.10.40[500] (1000 bytes)
received packet: from 192.168.10.40[500] to 192.168.10.38[500] (392 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) 
N(HASH_ALG) N(MULT_AUTH) ]

remote host is behind NAT
no IDi configured, fall back on IP address
authentication of '192.168.10.38' (myself) with pre-shared key
establishing CHILD_SA tunnel
generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi 
TSr N(MULT_AUTH) N(EAP_ONLY) ]
sending packet: from 192.168.10.38[4500] to 192.168.10.40[4500] (332 
bytes)
received packet: from 192.168.10.40[4500] to 192.168.10.38[4500] (108 
bytes)

parsed IKE_AUTH response 1 [ IDr AUTH N(TS_UNACCEPT) ]
authentication of '192.168.10.40' with pre-shared key successful
IKE_SA tunnel[2] established between 
192.168.10.38[192.168.10.38]...192.168.10.40[192.168.10.40]

scheduling rekeying in 2525s
maximum IKE_SA lifetime 3065s
*received TS_UNACCEPTABLE notify, no CHILD_SA built**
**failed to establish CHILD_SA, keeping IKE_SA**
**establishing connection 'tunnel' failed*
root@client:~#


Ipsec statusall

Status of IKE charon daemon (*strongSwan 5.3.3, Linux 
4.4.0-112-generic, x86_64*):

  uptime: 41 seconds, since Feb 07 12:08:32 2018
  malloc: sbrk 2703360, mmap 0, used 519216, free 2184144
  worker threads: 7 of 16 idle, 5/0/4/0 working, job queue: 0/0/0/0, 
scheduled: 2
  loaded plugins: charon aes kernel-libipsec des rc2 sha1 sha2 md5 
random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 
pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp xcbc cmac hmac curl 
attr kernel-netlink resolve socket-default stroke updown xauth-generic

Listening IP addresses:
  192.168.10.38
  192.168.3.107

Connections:
  tunnel:  %any...192.168.10.40  IKEv2
  tunnel:   local:  uses pre-shared key authentication
  tunnel:   remote: [192.168.10.40] uses pre-shared key authentication
  tunnel:   child:  dynamic === 192.168.10.0/32 TUNNEL
Security Associations (1 up, 0 connecting):
  tunnel[1]: ESTABLISHED 41 seconds ago, 
192.168.10.38[192.168.10.38]...192.168.10.40[192.168.10.40]
  tunnel[1]: IKEv2 SPIs: 53b251675b863a7d_i* 57d33cd8149f729f_r, 
rekeying in 41 minutes
  tunnel[1]: IKE proposal: 
AES_CBC_128/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1536



On Tuesday 16 January 2018 11:23 PM, Noel Kuntze wrote:

Hi,

Check the logs of the remote side.
It means the remote peer did not like the proposed traffic selector. It was 
probably outside of the network range that its own configuration allows, 
meaning narrowing failed.

Kind regards

Noel


On 16.01.2018 07:25, Sujoy wrote:

Hi Noel,

Same strongswan 5.3.3 configuration working in my VM(client) to desktop server. 
But not working from my OpenWRT to Global IP 

Re: [strongSwan] Authentication failure on server side

[Jafar Al-Gharaibeh]

Mugur,

    You can log the IP and a lot more by properly configuring your 
strongSwan logging options:


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

Regards,
Jafar



On 1/30/2018 10:40 AM, Abulius, Mugur (Nokia - FR/Paris-Saclay) wrote:

Hello,
A Linux server should log all successful and unsuccessful IKE authentication 
requests from clients.
Does the up-down script gets invoked on the server side (which is always 
responder), if the authentication with a client fails?
If the up-down script is not invoked, there is any way to determine on server 
side from which IP address the authentication request was rejected?
Thank you
Mugur

Re: [strongSwan] "signal of type SIGINT received. Shutting down" ?

[Jafar Al-Gharaibeh]

On 1/25/2018 11:35 AM, Hoggins! wrote:

I'm just trying to make sure that I'm able to fine select different
types of traffic on outbound UDP 4500 (we use NAT-T), and right now it
seems that I'm still also catching "data" packets.


If you set the DSCP bit for the IKE packets you should be able to use 
that with "tc",  which I'm assuming you use for traffic shaping, to set 
the priority high to get them through. You mentioned that you use


ikedscp=101110

Which should be all you need in strongSwan config. The other part is 
getting  tc configuration right to make sure it does what you think it 
does.  You don't need iptables rules.


--Jafar

Re: [strongSwan] "signal of type SIGINT received. Shutting down" ?

[Jafar Al-Gharaibeh]

We have the same situation, traffic shaping/capping.  Whether  it is an 
IKE packet
any other control packet, it is up to you (traffic shaping) to decide 
what happens at the NIC, and which
packets get routed first or how it is done. So yes, you are doing it 
right, and that is exactly

how we handle it here.

Regards,
Jafar

On 1/25/2018 9:28 AM, Hoggins! wrote:

Following the little diary of my experiments, here is what i believe I
found :

Because I'm doing traffic shaping at the output of my NIC (HTB with hard
capping), I believe that when there is a lot of outbound traffic in the
StrongSwan tunnel, it also clogs the available bandwidth for the whole
link, and... well, is it the DPD mechanism that can't get through fast
enough anymore, triggering a restart ? That's when bad things happen.

So I guess I should be able to define a specific prio for the packets
responsible for DPD / IKE. For that, I'm using the value ikedscp=101110
in my ipsec.conf, matching with an iptables rule to push the DSCP 0x2e
packets through a priority lane. But am I doing it right ?
Is there a better way ? What could I match to be sure that all the
signalling packets have a higher priority than the data packets ?

Thanks !

     Hoggins!

Le 20/01/2018 à 18:24, Hoggins! a écrit :

I think I'm getting closer to what I'm looking for.

So this event happens because I have dpdaction=restart. At least that's
what I found.
Problem is that with auto=route, if there is any connection drop, the
tunnel is never reestablished again, hence the dpdaction=restart, which
was obviously a workaround for me.

So I guess I need to understand why :
     - when there is excessive latency on the link, the tunnel fails
(should I work on the replay_window parameter ? The StrongSwan "server"
audit daemon complains with an "MAC_IPSEC_EVENT op=SA-replayed-pkt")
     - why, after having failed, the tunnel is not reestablished, why the
traps are not catching anything

     Hoggins!

Re: [strongSwan] TFC with compression

[Jafar Al-Gharaibeh]

The whole point of TFC is to make all packets have the same length so 
that an outside observer
can't infer anything from the size of the packets in the flow. 
Compression changes the size of
every packet so you end up with non-equal size packets anyway. 
Compression defeats the purpose
of TFC. Furthermore, if you really care about bandwidth and you use 
compression then TFC is a bad idea
in the first place since it adds a considerable overhead.  The other 
case of applying TFC after compression

doesn't make sense at all.

Regards,
Jafar

On 1/25/2018 9:30 AM, Stefan Xenon wrote:

Hi!
I enabled TFC in ipsec.conf and traced the traffic with Wireshark. I
noticed that TFC only seems to work when compression is disabled (in
which case packed length is identical). Is there a way to use both TFC
and compression at the same time? If not, what is the reason behind this
limitation? Thank you for your help.

Best regards,
Stefan

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 <http://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 <ja...@atcorp.com 
<mailto:ja...@atcorp.com>>:


Yusuf,

  Have you tried deleting "rightsubnet=0.0.0.0/0
<http://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 <http://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
<http://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
<noel.kuntze+strongswan-users-ml@thermi.consulting
<mailto:noel.kuntze+strongswan-users-ml@thermi.consulting>>:

Hello,

It's because you set "rightsubnet=0.0.0.0/0
<http://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 <http://172.30.1.1/25>
<http://172.30.1.1/25>
>       leftauth=psk
>       leftfirewall=no
>       right=%any
>       rightsubnet=0.0.0.0/0 <http://0.0.0.0/0>
<http://0.0.0.0/0>
>       rightsourceip=10.254.0.0/24 <http://10.254.0.0/24>
<http://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     primar

Re: [strongSwan] IPSec Tunnel IP

[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 
>:


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

Re: [strongSwan] DN vs SAN fields

[Jafar Al-Gharaibeh]

Will do, and report any findings.
Thanks Noel.

--Jafar


On 12/9/2017 5:05 PM, Noel Kuntze wrote:

No, you're probably doing something wrong.
Configure logging with the configuration on the HelpRequests[1] page and read 
it after you did your testing.

Kind regards

Noel

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

On 08.12.2017 23:13, Jafar Al-Gharaibeh wrote:

The configurations below were at the responder side. After trying different 
options at the initiator side  changing  the leftid I tracked the issue or the 
behavior to how the default leftid is selected at the initiator side. The 
documentation says that the leftid defaults to the DN of the configured 
certificate. That is the case in most of my testing even if I configure SAN 
fields, unless I configure a SAN field of type IP address. The leftid in that 
case defaults to the IP address instead if the DN.  Is that to be expected?

Thanks,
Jafar

On 12/8/2017 2:27 PM, Jafar Al-Gharaibeh wrote:

I have two certificates
certA.pem with DN set to "CN=strongswan"
certB.pem with DN set to "CN=strongswan" and one san field set to "IP:2.2.2.2"


If I use certA.pem in a config like the following, it works (i.e I can get the 
connection up and running):
conn vpn
    left=1.1.1.1
    right=2.2.2.2
    rightcert=certA.pem
rightid="CN=strongswan"


If I switch to use certB.pem then it fails if everything else stays the same 
even though the DN is exactly the same.:
conn vpn
    left=1.1.1.1
    right=2.2.2.2
    rightcert=certB.pem
    rightid="CN=strongswan"


If I change the rightid to the match the IP address in the san field then it 
works again:
conn vpn
    left=1.1.1.1
    right=2.2.2.2
rightcert=certB.pem
rightid=2.2.2.2


It is as if the san field is present  then it is preferred over the DN and  it 
is the only one matched.  The documentation of left/rightid says the id is 
matched against the DN OR any san field, but this is not what I see in my 
setup. Is this expected ? What am I missing?


Thanks in advance,
Jafar

Re: [strongSwan] No private key found

[Jafar Al-Gharaibeh]

Can  you share your config/secret files ?

--Jafar


On 12/11/2017 9:17 AM, rajeev nohria wrote:
Anyone can help in this issue, I have setup the id with Subject id.  
Still have this issue. Is anything else I am missing?

Thanks,
Rajeev

On Tue, Nov 14, 2017 at 12:44 PM, rajeev nohria > wrote:



Not sure what is wrong here,  Can you let me know if  I am missing
something here.



16[KNL] creating acquire job for policy
fc00:cada:c406:607::1001/128[tcp/43005] ===
fc00:cada:c406::200/128[tcp/8190] with reqid {2}

2017-11-13 15:58:56,001-HalTransport.py-94-INFO-Start a agent
transport interface, path = [/tmp/Hal/agent/client/1/push]

15[IKE] initiating IKE_SA rpdfc00:cada:c406::200[1] to
fc00:cada:c406::200

15[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP)
N(NATD_D_IP) N(HASH_ALG) N(REDIR_SUP) ]

15[NET] sending packet: from fc00:cada:c406:607::1001[500] to
fc00:cada:c406::200[500] (456 bytes)

10[NET] received packet: from fc00:cada:c406::200[500] to
fc00:cada:c406:607::1001[500] (453 bytes)

10[ENC] parsed IKE_SA_INIT response 0 [ SA KE No CERTREQ ]

10[IKE] received cert request for "C=US, O=CableLabs, OU=TEST Root
CA01, CN=TEST CableLabs Root Certification Authority"

10[IKE] received 1 cert requests for an unknown ca

10[IKE] sending cert request for "C=US, O=CableLabs, OU=TEST
Device CA01, CN=TEST CableLabs Device Certification Authority"

10[IKE] sending cert request for "C=US, O=CableLabs, OU=TEST Root
CA01, CN=TEST CableLabs Root Certification Authority"

10[IKE] no private key found for 'C=US, O=ARRIS Group, Inc.,
OU=DCA Remote Device Certificate, CN=FF:FF:05:E6:E6:20'

13[KNL] creating delete job for CHILD_SA
ESP/0x/fc00:cada:c406::200

08[JOB] CHILD_SA ESP/0x/fc00:cada:c406::200 not found for
delete

06[KNL] creating acquire job for policy
fc00:cada:c406:607::1001/128[tcp/39047] ===
fc00:cada:c406::200/128[tcp/8190] with reqid {2}

16[IKE] initiating IKE_SA rpdfc00:cada:c406::200[2] to
fc00:cada:c406::200

16[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP)
N(NATD_D_IP) N(HASH_ALG) N(REDIR_SUP) ]

16[NET] sending packet: from fc00:cada:c406:607::1001[500] to
fc00:cada:c406::200[500] (456 bytes)

11[NET] received packet: from fc00:cada:c406::200[500] to
fc00:cada:c406:607::1001[500] (453 bytes)

11[ENC] parsed IKE_SA_INIT response 0 [ SA KE No CERTREQ ]

11[IKE] received cert request for "C=US, O=CableLabs, OU=TEST Root
CA01, CN=TEST CableLabs Root Certification Authority"

11[IKE] received 1 cert requests for an unknown ca

11[IKE] sending cert request for "C=US, O=CableLabs, OU=TEST
Device CA01, CN=TEST CableLabs Device Certification Authority"

11[IKE] sending cert request for "C=US, O=CableLabs, OU=TEST Root
CA01, CN=TEST CableLabs Root Certification Authority"

11[IKE] no private key found for 'C=US, O=ARRIS Group, Inc.,
OU=DCA Remote Device Certificate, CN=FF:FF:05:E6:E6:20

root@plnx_aarch64:~# ip -s xfrm state

src fc00:cada:c406:607::1001 dst fc00:cada:c406::200

    proto esp spi 0x(0) reqid 2(0x0002) mode transport

    replay-window 0 seq 0x0002 flag  (0x)

    anti-replay context: seq 0x0, oseq 0x0, bitmap 0x

    sel src fc00:cada:c406:607::1001/128 dst
fc00:cada:c406::200/128 proto tcp sport 39047 dport 8190 uid 0

    lifetime config:

limit: soft (INF)(bytes), hard (INF)(bytes)

limit: soft (INF)(packets), hard (INF)(packets)

expire add: soft 0(sec), hard 165(sec)

expire use: soft 0(sec), hard 0(sec)

    lifetime current:

0(bytes), 0(packets)

  add 2017-11-13 16:01:42 use -

    stats:

replay-wind

root@plnx_aarch64:~# ip -s xfrm policy

src fc00:cada:c406::200/128 dst fc00:cada:c406:607::1001/128 proto
tcp uid 0

    dir in action allow index 88 priority 234336 share any
flag (0x)

    lifetime config:

limit: soft (INF)(bytes), hard (INF)(bytes)

limit: soft (INF)(packets), hard (INF)(packets)

expire add: soft 0(sec), hard 0(sec)

expire use: soft 0(sec), hard 0(sec)

    lifetime current:

0(bytes), 0(packets)

  add 2017-11-13 15:58:55 use -

    tmpl src :: dst ::

proto esp spi 0x(0) reqid 2(0x0002) mode transport

level required share any

enc-mask  auth-mask  comp-mask


src fc00:cada:c406:607::1001/128 dst fc00:cada:c406::200/128 proto
tcp uid 0

    dir out action allow index 81 priority 234336 share any
flag (0x)

    lifetime config:

limit: soft (INF)(bytes), hard (INF)(bytes)

  limit: soft (INF)(packets), hard (INF)(packets)

[strongSwan] DN vs SAN fields

[Jafar Al-Gharaibeh]

I have two certificates
certA.pem with DN set to "CN=strongswan"
certB.pem with DN set to "CN=strongswan" and one san field set to 
"IP:2.2.2.2"



If I use certA.pem in a config like the following, it works (i.e I can 
get the connection up and running):

conn vpn
   left=1.1.1.1
   right=2.2.2.2
   rightcert=certA.pem
rightid="CN=strongswan"


If I switch to use certB.pem then it fails if everything else stays the 
same even though the DN is exactly the same.:

conn vpn
   left=1.1.1.1
   right=2.2.2.2
   rightcert=certB.pem
   rightid="CN=strongswan"


If I change the rightid to the match the IP address in the san field 
then it works again:

conn vpn
   left=1.1.1.1
   right=2.2.2.2
rightcert=certB.pem
rightid=2.2.2.2


It is as if the san field is present  then it is preferred over the DN 
and  it is the only one matched.  The documentation of left/rightid says 
the id is matched against the DN OR any san field, but this is not what 
I see in my setup. Is this expected ? What am I missing?



Thanks in advance,
Jafar

Re: [strongSwan] Fwd: Re: Validating Local Host Own Certificate

[Jafar Al-Gharaibeh]

To make this even more obvious, the name of such config item should 
refer to "local" as :


"StrictLocalCert=yes" or "EnforceValidLocalCert=yes"

On 12/7/2017 11:17 AM, Jafar Al-Gharaibeh wrote:

Hi Andreas,

   I agree with you completely.  I wasn't suggesting to change the 
default behavior, sorry I didn't make that clear. I was thinking of 
adding a new connection configuration item like "StrictCert=yes" or 
"EnforceValidCert=yes" to achieve the new behavior. The default for 
such a new config would be still be no.


Kind Regards,
Jafar


On 12/7/2017 10:47 AM, Andreas Steffen wrote:

Hi Jafar,

I don't see any sense in strongSwan verifying local certificates.
At the extreme people are using self-signed certificates where there
is no trust chain at all both for the local and the remote end.
In that case trust has to be established over out-of-band channels.

You are free to patch strongSwan to add the desired functionality.
This is what open source software is all about. But we are not going to
integrate your patch into our master repository for the reasons
mentioned above.

There are a lot of external tools which allow you to check a trust 
chain, among them the strongSwan "pki --verify" command which even

checks the revocation status of the certificate via CRL or OCSP servers.

Best regards

Andreas

On 07.12.2017 17:25, Jafar Al-Gharaibeh wrote:

Andreas, Tobias,

   I would like to have this functionality, i.e, validating all certs
even local ones and only use them if they are valid. I can easily do
this via a script externally and prevent strongSwan from using them by
stashing them in a non standard location for example. But I would 
rather

do it properly through strongSwan if possible. Is there anything that
would make no a good idea or a technical reason that would make this
hard to do?  If the answer is no, then I will work on a patch to do
this. Please let me know.

Thanks,

Jafar

     Forwarded Message 

Subject: Re: [strongSwan] Validating Local Host Own Certificate
Date: Thu, 7 Dec 2017 08:37:34 +0100
From:     Andreas Steffen <andreas.stef...@strongswan.org>
To: Jafar Al-Gharaibeh <ja...@atcorp.com>, 
users@lists.strongswan.org




Hi Jafar,

locally loaded certificates are always trusted.

Regards

Andreas

On 07.12.2017 07:44, Jafar Al-Gharaibeh wrote:

Hi,

    I have noticed that when configuring the local certificate in a
connection via :

    leftcert=cert.pem

   The certificate is loaded and trusted without validating it through
CA/trust-chains. Is this behavior documented anywhere? digging through
documentation I only found old email references  to this. Is this the
expected behavior? Is there a way to force one's own certificate
validation when loaded/used? i.e/ cert.pem above has to be validated
through a CA tustchain.

Thanks,
Jafar


--
==
Andreas steffenandreas.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]==

Re: [strongSwan] Fwd: Re: Validating Local Host Own Certificate

[Jafar Al-Gharaibeh]

Hi Andreas,

   I agree with you completely.  I wasn't suggesting to change the 
default behavior, sorry I didn't make that clear. I was thinking of 
adding a new connection configuration item like "StrictCert=yes" or 
"EnforceValidCert=yes" to achieve the new behavior. The default for such 
a new config would be still be no.


Kind Regards,
Jafar


On 12/7/2017 10:47 AM, Andreas Steffen wrote:

Hi Jafar,

I don't see any sense in strongSwan verifying local certificates.
At the extreme people are using self-signed certificates where there
is no trust chain at all both for the local and the remote end.
In that case trust has to be established over out-of-band channels.

You are free to patch strongSwan to add the desired functionality.
This is what open source software is all about. But we are not going to
integrate your patch into our master repository for the reasons
mentioned above.

There are a lot of external tools which allow you to check a trust 
chain, among them the strongSwan "pki --verify" command which even

checks the revocation status of the certificate via CRL or OCSP servers.

Best regards

Andreas

On 07.12.2017 17:25, Jafar Al-Gharaibeh wrote:

Andreas, Tobias,

   I would like to have this functionality, i.e, validating all certs
even local ones and only use them if they are valid. I can easily do
this via a script externally and prevent strongSwan from using them by
stashing them in a non standard location for example. But I would rather
do it properly through strongSwan if possible. Is there anything that
would make no a good idea or a technical reason that would make this
hard to do?  If the answer is no, then I will work on a patch to do
this. Please let me know.

Thanks,

Jafar

     Forwarded Message 

Subject: Re: [strongSwan] Validating Local Host Own Certificate
Date: Thu, 7 Dec 2017 08:37:34 +0100
From: Andreas Steffen <andreas.stef...@strongswan.org>
To: Jafar Al-Gharaibeh <ja...@atcorp.com>, 
users@lists.strongswan.org




Hi Jafar,

locally loaded certificates are always trusted.

Regards

Andreas

On 07.12.2017 07:44, Jafar Al-Gharaibeh wrote:

Hi,

    I have noticed that when configuring the local certificate in a
connection via :

    leftcert=cert.pem

   The certificate is loaded and trusted without validating it through
CA/trust-chains. Is this behavior documented anywhere? digging through
documentation I only found old email references  to this. Is this the
expected behavior? Is there a way to force one's own certificate
validation when loaded/used? i.e/ cert.pem above has to be validated
through a CA tustchain.

Thanks,
Jafar


--
==
Andreas steffenandreas.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]==

[strongSwan] Validating Local Host Own Certificate

[Jafar Al-Gharaibeh]

Hi,

   I have noticed that when configuring the local certificate in a 
connection via :


   leftcert=cert.pem

  The certificate is loaded and trusted without validating it through 
CA/trust-chains. Is this behavior documented anywhere? digging through 
documentation I only found old email references  to this. Is this the 
expected behavior? Is there a way to force one's own certificate 
validation when loaded/used? i.e/ cert.pem above has to be validated 
through a CA tustchain.


Thanks,
Jafar

Re: [strongSwan] RNGs and OpenSSL

[Jafar Al-Gharaibeh]

Thanks Noel!,

  Going back to the config options, what exactly is engine_id here:

charon.plugins.openssl.engine_id [pkcs11]
   ENGINE ID to use in the OpenSSL plugin.


Thanks,
Jafar

On 11/9/2017 2:56 PM, Noel Kuntze wrote:

That those are all the options you can set.

The first plugin that provides a feature is used. rdrand will only be used as 
PRNG, if it is loaded earlier than openssl.

If a plugin uses another plugin's PRNG implementation depends on the exact code.

On 09.11.2017 21:42, Jafar Al-Gharaibeh wrote:

What about?

what if I enable rdrand above does that  become  the default for all random 
numbers used by strongswan ignoring OpenSSL's RNG?

Does enabling those other RNG plugins have any effect on OpenSSL itself? I.e is 
there  a way to set OpenSSL's RNG directly from Strongswan?



On 11/9/2017 2:39 PM, Noel Kuntze wrote:

Correct.

On 09.11.2017 21:38, Jafar Al-Gharaibeh wrote:

Noel,

    Thank you for the quick response. I did search through the documentation 
and also the source code, but didn't find definitive answers to my questions. 
Do you  have some pointers?

I did see this in the man page which addresses my last question:

   charon.plugins.openssl.engine_id [pkcs11]
    ENGINE ID to use in the OpenSSL plugin.

charon.plugins.openssl.fips_mode [0]
    Set OpenSSL FIPS mode: disabled(0), enabled(1), Suite B 
enabled(2).


So, are these the only available options?

Thank you in advance,
Jafar

On 11/9/2017 2:29 PM, Noel Kuntze wrote:

Use the power of documentation (man pages).

On 09.11.2017 21:22, Jafar Al-Gharaibeh wrote:

Hi,

     I am compiling  StrongSwan with these options:

--enable-openssl    #enables the OpenSSL crypto plugin.
#--enable-rdrand  # don't enable Intel RDRAND random generator plugin.
--disable-random    #disable RNG implementation on top of /dev/(u)random.

Looking through the code, OpenSSL plugin itself provides an RNG plugin so I 
thought the above configuration
will make sure I'm using the OpenSSL RNG.  Is my assumption correct?

what if I enable rdrand above does that  become  the default for all random 
numbers used by strongswan ignoring OpenSSL's RNG?

Does enabling those other RNG plugins have any effect on OpenSSL itself? I.e is 
there  a way to set OpenSSL's RNG directly from Strongswan?

For OpenSSL (and other plugins), where do I find a list of all supported 
configuration options? for example I found the following example on strongswan 
website, what other  options I can set/unset there?

charon {
   load_modular = yes
   interfaces_use = eth0
   plugins {
   openssl {
    fips_mode = 0
   }
   include strongswan.d/charon/*.conf
   }
}



Many Thanks,
Jafar

Re: [strongSwan] RNGs and OpenSSL

[Jafar Al-Gharaibeh]

What about?

what if I enable rdrand above does that  become  the default for all random 
numbers used by strongswan ignoring OpenSSL's RNG?

Does enabling those other RNG plugins have any effect on OpenSSL itself? I.e is 
there  a way to set OpenSSL's RNG directly from Strongswan?



On 11/9/2017 2:39 PM, Noel Kuntze wrote:

Correct.

On 09.11.2017 21:38, Jafar Al-Gharaibeh wrote:

Noel,

   Thank you for the quick response. I did search through the documentation and 
also the source code, but didn't find definitive answers to my questions. Do 
you  have some pointers?

I did see this in the man page which addresses my last question:

  charon.plugins.openssl.engine_id [pkcs11]
   ENGINE ID to use in the OpenSSL plugin.

charon.plugins.openssl.fips_mode [0]
   Set OpenSSL FIPS mode: disabled(0), enabled(1), Suite B 
enabled(2).


So, are these the only available options?

Thank you in advance,
Jafar

On 11/9/2017 2:29 PM, Noel Kuntze wrote:

Use the power of documentation (man pages).

On 09.11.2017 21:22, Jafar Al-Gharaibeh wrote:

Hi,

    I am compiling  StrongSwan with these options:

--enable-openssl    #enables the OpenSSL crypto plugin.
#--enable-rdrand  # don't enable Intel RDRAND random generator plugin.
--disable-random    #disable RNG implementation on top of /dev/(u)random.

Looking through the code, OpenSSL plugin itself provides an RNG plugin so I 
thought the above configuration
will make sure I'm using the OpenSSL RNG.  Is my assumption correct?

what if I enable rdrand above does that  become  the default for all random 
numbers used by strongswan ignoring OpenSSL's RNG?

Does enabling those other RNG plugins have any effect on OpenSSL itself? I.e is 
there  a way to set OpenSSL's RNG directly from Strongswan?

For OpenSSL (and other plugins), where do I find a list of all supported 
configuration options? for example I found the following example on strongswan 
website, what other  options I can set/unset there?

charon {
  load_modular = yes
  interfaces_use = eth0
  plugins {
  openssl {
   fips_mode = 0
  }
  include strongswan.d/charon/*.conf
  }
}



Many Thanks,
Jafar

[strongSwan] RNGs and OpenSSL

[Jafar Al-Gharaibeh]

Hi,

  I am compiling  StrongSwan with these options:

--enable-openssl    #enables the OpenSSL crypto plugin.
#--enable-rdrand  # don't enable Intel RDRAND random generator plugin.
--disable-random    #disable RNG implementation on top of /dev/(u)random.

Looking through the code, OpenSSL plugin itself provides an RNG plugin 
so I thought the above configuration

will make sure I'm using the OpenSSL RNG.  Is my assumption correct?

what if I enable rdrand above does that  become  the default for all 
random numbers used by strongswan ignoring OpenSSL's RNG?


Does enabling those other RNG plugins have any effect on OpenSSL itself? 
I.e is there  a way to set OpenSSL's RNG directly from Strongswan?


For OpenSSL (and other plugins), where do I find a list of all supported 
configuration options? for example I found the following example on 
strongswan website, what other  options I can set/unset there?


charon {
load_modular = yes
interfaces_use = eth0
plugins {
openssl {
 fips_mode = 0
}
include strongswan.d/charon/*.conf
}
}




Many Thanks,
Jafar

Re: [strongSwan] Failure connecting VICI socket: permission denied

[Jafar Al-Gharaibeh]

Terry,

    From the limited information you are giving, my guess is that nhrpd 
doesn't have permissions to access the VICI socket. nhrpd is probably 
configured as  part of FRR/Quagga  with permissions to access  
/var/run/frr or /var/run/quagga only. Whereas the vici socket, according to


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

is: unix:///var/run/charon.vici

Give nhrpd permissions to access to this file and you should be good to.

--Jafar


On 11/7/2017 10:06 AM, Chengcheng Fu wrote:



Hi,

I’m trying to setup nhrpd with strongswan, and I’m getting this error 
message.


Failure connecting VICI socket: permission denied


I wonder if there is a way to test the VICI socket and see if it’s 
running properly?



Regards,


Terry

Re: [strongSwan] Rule Priorities Across Connections

[Jafar Al-Gharaibeh]

Thanks Noel!

 I did go through the source code and found out the exact details. For 
the record and to keep this archived, the short summary is:


==>  High Priority
     Masks  :  The most specific subnet mask for both source and 
destination has higher priority over anything else. The masks of both 
the src and dst carry the same priority weight
 Port      :  if masks are equal ports takes precedence over 
protocol
 Protocol   : if everything else is equal,  rules with protocol set 
take precedence.

==> Low Priority

Applying this to my examples bellow:

Example 1:

Connection 1 :
                    rightsubnet=10.0.0.1/32

Connection 2 :
                     rightsubnet=10.0.0.0/24[udp]


udp packet going to 10.0.0.1 will use connection 1 because it has more specific 
mask.


Example 2:

Connection 1 :
                    leftsubnet=10.0.0.1/32
    rightsubnet=192.168.0.0/24
 
Connection 2 :

    leftsubnet=10.0.0.0/24
    rightsubnet=192.168.0.1/32

For a packet going from 10.0.0.1 to 192.168.0.1: no clear answer. The tow rules are 
"entangled" and has the same priority. I tested this and the result is 
ambiguous and is different from one run to another depending on the order of operations 
and when the connections come up. My conclusion is that this is a bad setup.  It should 
be simply written as (for example):


Connection 1 :
                    leftsubnet=10.0.0.1/32
    rightsubnet=192.168.0.1/32
 
Connection 2 :

    leftsubnet=10.0.0.0/24
    rightsubnet=192.168.0.0/24



--Jafar


On 10/11/2017 9:41 AM, Noel Kuntze wrote:

The prioritiy is determined by the (obviously named) priority field in the 
security policies. Charon calculates the priority based on the prefix length 
and if protocol selectors are given.
You need to read the source code to find out what exactly it does.

On 10.10.2017 21:38, Jafar Al-Gharaibeh wrote:

Is the behavior documented anywhere?

Thanks,
Jafar

On 10/5/2017 11:24 AM, Jafar Al-Gharaibeh wrote:

Hi,

     I know that the most specific rule is applied a given traffic if multiple 
overlapping rules exist. But How is the priority determined when rules are 
specific in different ways Like the cases below. Not sure if this is a 
strongSwan question or a OS Kernel question  as it seems this is more of how 
the Linux  kernel handles it for example, but I hope someone here can shed some 
light on this subject.

Example 1:

Connection 1 :
                     rightsubnet=10.0.0.1/32

Connection 2 :
                      rightsubnet=10.0.0.0/24[udp]

If a udp packet is going to 10.0.0.1, which connection config will be use? Does 
the priority starts with subnet where the most specific subnet takes precedence 
before moving to protocols/ports?

What is the priority between the protocols and ports themselves?


Example 2:

Connection 1 :
                     leftsubnet=10.0.0.1/32
     rightsubnet=192.168.0.0/24
  
Connection 2 :

     leftsubnet=10.0.0.0/24
     rightsubnet=192.168.0.1/32

For a packet going from 10.0.0.1 to 192.168.0.1,  based on the source 
connection 1 has higher priority, but based on the destination connection 2 has 
a higher priority. How is this handled?

Regards,
Jafar
  

Re: [strongSwan] IKE Ciphers in relation to ESP Ciphers

[Jafar Al-Gharaibeh]

Is this possible to do in strongSwan currently ? I didn't find any 
documentation regarding this.  I might look into adding this capability 
if it doesn't currently exist.


Thanks,
Jafar


On 10/5/2017 1:42 PM, Jafar Al-Gharaibeh wrote:

Hi,

  Is there a way to force  child SAs not have ciphers that are 
stronger (in term of bits) than the the IKE SA that created them. In 
other words, I want to be able to force IKE encryption to be always 
stronger or equal than that of Child SAs. I know this can be achieved  
by configuring IKE ciphers such that the lowest strength cipher is 
stronger or equal   to that of any esp cipher, but that is very 
limiting. Having the ability to do this at run time gives the peers 
more flexibility and more ciphers options to pick from and only make 
the decision per connection.


Regards,
Jafar

Re: [strongSwan] Rule Priorities Across Connections

[Jafar Al-Gharaibeh]

Is the behavior documented anywhere?

Thanks,
Jafar

On 10/5/2017 11:24 AM, Jafar Al-Gharaibeh wrote:

Hi,

    I know that the most specific rule is applied a given traffic if 
multiple overlapping rules exist. But How is the priority determined 
when rules are specific in different ways Like the cases below. Not 
sure if this is a strongSwan question or a OS Kernel question  as it 
seems this is more of how the Linux  kernel handles it for example, 
but I hope someone here can shed some light on this subject.


Example 1:

Connection 1 :
                    rightsubnet=10.0.0.1/32

Connection 2 :
                     rightsubnet=10.0.0.0/24[udp]

If a udp packet is going to 10.0.0.1, which connection config will be 
use? Does the priority starts with subnet where the most specific 
subnet takes precedence before moving to protocols/ports?


What is the priority between the protocols and ports themselves?


Example 2:

Connection 1 :
                    leftsubnet=10.0.0.1/32
    rightsubnet=192.168.0.0/24

Connection 2 :
    leftsubnet=10.0.0.0/24
    rightsubnet=192.168.0.1/32

For a packet going from 10.0.0.1 to 192.168.0.1,  based on the source 
connection 1 has higher priority, but based on the destination 
connection 2 has a higher priority. How is this handled?


Regards,
Jafar

[strongSwan] IKE Ciphers in relation to ESP Ciphers

[Jafar Al-Gharaibeh]

Hi,

  Is there a way to force  child SAs not have ciphers that are stronger 
(in term of bits) than the the IKE SA that created them. In other words, 
I want to be able to force IKE encryption to be always stronger or equal 
than that of Child SAs. I know this can be achieved  by configuring IKE 
ciphers such that the lowest strength cipher is stronger or equal   to 
that of any esp cipher, but that is very limiting. Having the ability to 
do this at run time gives the peers more flexibility and more ciphers 
options to pick from and only make the decision per connection.


Regards,
Jafar

[strongSwan] Rule Priorities Across Connections

[Jafar Al-Gharaibeh]

Hi,

    I know that the most specific rule is applied a given traffic if 
multiple overlapping rules exist. But How is the priority determined 
when rules are specific in different ways Like the cases below. Not sure 
if this is a strongSwan question or a OS Kernel question  as it seems 
this is more of how the Linux  kernel handles it for example, but I hope 
someone here can shed some light on this subject.


Example 1:

Connection 1 :
                    rightsubnet=10.0.0.1/32

Connection 2 :
                     rightsubnet=10.0.0.0/24[udp]

If a udp packet is going to 10.0.0.1, which connection config will be 
use? Does the priority starts with subnet where the most specific subnet 
takes precedence before moving to protocols/ports?


What is the priority between the protocols and ports themselves?


Example 2:

Connection 1 :
                    leftsubnet=10.0.0.1/32
    rightsubnet=192.168.0.0/24

Connection 2 :
    leftsubnet=10.0.0.0/24
    rightsubnet=192.168.0.1/32

For a packet going from 10.0.0.1 to 192.168.0.1,  based on the source 
connection 1 has higher priority, but based on the destination 
connection 2 has a higher priority. How is this handled?


Regards,
Jafar

Re: [strongSwan] nonce Length

[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

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