Re: [strongSwan] strict crl policy

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

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

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

Re: [strongSwan] strongSwan, FRR, NHRP

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

Re: [strongSwan] Cannot load private key

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

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

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

Re: [strongSwan] Frequent childsa close and open

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

Re: [strongSwan] Problem initilizig ipsec tunnel

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

Re: [strongSwan] IKE signature scheme RSA_EMSA_PKCS1_SHA1 not acceptable

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

Re: [strongSwan] IKE signature scheme RSA_EMSA_PKCS1_SHA1 not acceptable

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

Re: [strongSwan] IKE signature scheme RSA_EMSA_PKCS1_SHA1 not acceptable

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

Re: [strongSwan] IKE signature scheme RSA_EMSA_PKCS1_SHA1 not acceptable

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

Re: [strongSwan] Route based VPN Strongswan IPsec tunnel

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]

Re: [strongSwan] Strongswan 5.6.3 rekey every 30 seconds

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 =

Re: [strongSwan] Sudden issues with Windows 10 clients

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.

Re: [strongSwan] Sudden issues with Windows 10 clients

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

Re: [strongSwan] Can anyone explain VPN oddity

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

Re: [strongSwan] Can anyone explain VPN oddity

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

Re: [strongSwan] Sudden issues with Windows 10 clients

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

Re: [strongSwan] Sudden issues with Windows 10 clients

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 th

Re: [strongSwan] Sudden issues with Windows 10 clients

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

Re: [strongSwan] Sudden issues with Windows 10 clients

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 clien

Re: [strongSwan] policy mismatch

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

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

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

Re: [strongSwan] policy mismatch

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

Re: [strongSwan] policy mismatch

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

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

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 ?

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

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

Re: [strongSwan] ssh and http through IPSec

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 O

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

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

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

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

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

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

Re: [strongSwan] Scepclien failed to generate certificate

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

Re: [strongSwan] pki --verify Command

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

Re: [strongSwan] pki --verify Command

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 eve

Re: [strongSwan] pki --verify Command

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

Re: [strongSwan] pki --verify Command

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

Re: [strongSwan] pki --verify Command

sions 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

[strongSwan] pki --verify Command

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

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

e 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  

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

.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

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

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

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

.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: Sujo

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

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

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

Re: [strongSwan] Authentication failure on server side

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

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

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

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

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

Re: [strongSwan] TFC with compression

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.

Re: [strongSwan] IPSec Tunnel IP

ing "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-Gha

Re: [strongSwan] IPSec Tunnel IP

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

Re: [strongSwan] DN vs SAN fields

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

Re: [strongSwan] No private key found

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

[strongSwan] DN vs SAN fields

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   

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

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 t

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

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

[strongSwan] Validating Local Host Own Certificate

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

Re: [strongSwan] RNGs and OpenSSL

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

Re: [strongSwan] RNGs and OpenSSL

/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

[strongSwan] RNGs and OpenSSL

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

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

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

Re: [strongSwan] Rule Priorities Across Connections

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

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

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

Re: [strongSwan] Rule Priorities Across Connections

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

[strongSwan] IKE Ciphers in relation to ESP Ciphers

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

[strongSwan] Rule Priorities Across Connections

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

Re: [strongSwan] nonce Length

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,

Re: [strongSwan] nonce Length

]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