Re: [strongSwan] IPSec / IKEv2, IP-(Re)assignment problem
Am 20.05.19 um 14:59 schrieb Tobias Brunner: > Hi Sven, > > You explicitly disabled handling of INITIAL_CONTACT notifies with > uniqueids=never. So existing IKE_SAs with the same client identity will > not be terminated when a new IKE_SA is created, which also means the > existing virtual IP is not released. Since the same virtual IP can't be > assigned to multiple clients, a new virtual IP is allocated instead. > > Also, reducing the DPD timeout on servers with mobile clients is not > that good an idea as it prevents clients from roaming between networks > (or being without connectivity for a while due to other reasons) and > updating the exiting IKE_SA via MOBIKE afterwards. Hello Tobias! Thanks for the answer. We set "uniqueids" to "never" to allow simultaneous connections with the same user account. For instance a simultaneous login from the iPhone and the iPad. If this "uniqueness" is only determined by the login username and not further data (like a mac address or name of the connecting device), I see that this will not work. Or do you have any other ideas to make this work? Regards Sven Anders -- Sven Anders () UTF-8 Ribbon Campaign /\ Support plain text e-mail ANDURAS intranet security AG Messestrasse 3 - 94036 Passau - Germany Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. - Benjamin Franklin <>
[strongSwan] IPSec / IKEv2, IP-(Re)assignment problem
Hello!
We are using strongswan to connect iPhones and iPads via IPSec with IKEv2.
The authentication and connection works fine.
We configured two IP pools: a dynamic and a static pool.
The static pool entries look like:
192.168.220.1=john@domainname.com
The (first) assignment of the static or dynamic IPs worked as expected.
Now we are experiencing a IP (re)assigning problem and hope you can help.
If a mobile device, which is connected with the correctly assigned static
IP address, leaves the reception area of the Wifi or LTE cell, the
device tries to reconnect and receives now a dynamic IP.
This only happens, if the time between disconnection and reconnect is
shorter than ~30 seconds.
You can emulate this by disabling and re-enabling the "mobile data" on the
iPhone.
We expected, that the devices will get the same IP after reconnection.
We tried to play with the retransmission values
(https://wiki.strongswan.org/projects/strongswan/wiki/Retransmission)
and tried to play the the DPD-Values (as far as they apply to IKEv2).
Can you help?
Regards
Sven
--
Here are the full configs:
ipsec.conf:
config setup
uniqueids=never
conn rw-base
fragmentation=yes
dpdtimeout=90s
dpddelay=30s
dpdaction=clear
conn rw-config
also=rw-base
reauth=no
rekey=no
ike=aes256-sha2_256-prfsha256-modp1024-modp2048,aes256gcm16-prfsha384-modp3072!
esp=aes256-sha2_256-prfsha256,aes256-sha1,aes256gcm16-modp3072!
leftsubnet=10.0.0.0/8 # Split tunnel config
leftid="vpn.domainname.net"
leftcert=vpn.domainname.net.pem
leftsendcert=always
left=217.6.20.66
lefthostaccess=yes
rightdns=10.1.3.10, 10.1.3.11
rightsourceip=%static, %dynamic
conn ikev2-pubkey
also=rw-config
keyexchange=ikev2
auto=route
strongswan.conf:
charon {
load_modular = yes
plugins {
include strongswan.d/charon/*.conf
}
# Do not install routes or virtual IPs.
install_routes = no
install_virtual_ip = no
# Test values
retransmit_jitter = 0
retransmit_limit = 0
retransmit_timeout = 4.0
retransmit_tries = 1
# Benchmark crypto algorithms and order them by efficiency.
crypto_test { bench = yes }
# Configure additional plugins.
plugins {
attr-sql { database = sqlite:///var/lib/ipsec/ippool.sqlite3 }
attr {
# Split tunnel
dns = 10.1.3.10, 10.1.3.11
25 = domain.local
}
}
}
}
The pools were created with:
ipsec pool --add dynamic --start 192.168.3.20 --end 192.168.3.254 --timeout 4h
ipsec pool --add static --addresses static.ippool --timeout 0
--
Sven Anders () UTF-8 Ribbon Campaign
/\ Support plain text e-mail
ANDURAS intranet security AG
Messestrasse 3 - 94036 Passau - Germany
Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55
Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
- Benjamin Franklin
<>
Re: [strongSwan] Problem: "unable to install policy -the same policy for reqid XXXX exists "
Am 28.11.18 um 11:31 schrieb Tobias Brunner: > Hi Sven, > >> So the problem is known? > > Not really, but maybe something changed that avoids the issue, and I > don't particularly fancy debugging old versions. > >> Which version should I use at least. Will 5.6.3 be enough or >> should I use 5.7.1 instead? > > If you consider updating, use the latest. I will do it, but it will take some time until we can deploy it to the customer... >> There are many request and the log file is very long. > > So? > >> What kind of message do you expect or what should I search for? > > For instance, messages around refcount changes of the policies. You can > also post it somewhere for us to have a look at. Thank you, I will send you a link to download it. If anybody want the log output too, to analyse it, I will send you the link. Regards Sven Anders -- Sven Anders () UTF-8 Ribbon Campaign /\ Support plain text e-mail ANDURAS intranet security AG Messestrasse 3 - 94036 Passau - Germany Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. - Benjamin Franklin
Re: [strongSwan] Problem: "unable to install policy -the same policy for reqid XXXX exists "
Am 23.11.18 um 11:11 schrieb Tobias Brunner: > Hi Sven, > >> We are using strongSwan 5.6.2 on a Linux kernel 4.1.39. > > Try using a newer strongSwan version. So the problem is known? Which version should I use at least. Will 5.6.3 be enough or should I use 5.7.1 instead? >> The installed policy (in this case) is the following: >> >> src 10.0.0.0/8 dst 192.168.3.67/32 >> dir out priority 379519 ptype main >> tmpl src 217.6.20.66 dst 84.160.101.118 >> proto esp spi 0x0f95ddf2 reqid 4388 mode tunnel > > Use the full log to see why it may have been left there. That log > snippet you added is not really useful. There are many request and the log file is very long. What kind of message do you expect or what should I search for? >> I already tried to change "auto=add" to "auto=route", which I found in a >> description >> of a similar problem, but that changed nothing... > > auto=route makes no sense on a gateway for roadwarriors. Ok, just read about it in another similar problem and this was one idea to solve it (the race condition?)... Regards Sven Anders -- Sven Anders () UTF-8 Ribbon Campaign /\ Support plain text e-mail ANDURAS intranet security AG Messestrasse 3 - 94036 Passau - Germany Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. - Benjamin Franklin <>
[strongSwan] Problem: "unable to install policy -the same policy for reqid XXXX exists "
Hello!
We are using strongSwan 5.6.2 on a Linux kernel 4.1.39.
Our problem is, that after some uptime the strongswan rejects connections with
the following message:
charon: 23422[CFG] unable to install policy 10.0.0.0/8 === 192.168.3.67/32
out for reqid 14832, the same policy for reqid 4388 exists
If we restart strongswan, the connections begin to work correctly again.
The installed policy (in this case) is the following:
src 10.0.0.0/8 dst 192.168.3.67/32
dir out priority 379519 ptype main
tmpl src 217.6.20.66 dst 84.160.101.118
proto esp spi 0x0f95ddf2 reqid 4388 mode tunnel
The connections are mainly from iPhones and are using IKEv2.
Any ideas what causes this?
Is there an option to force the replacement of an policy?
I already tried to change "auto=add" to "auto=route", which I found in a
description
of a similar problem, but that changed nothing...
Regards
Sven Anders
---8X-
Here is the configuration:
ipsec.conf:
---
config setup
uniqueids=never
charondebug = ike 2, net 2, pts 2, lib 2, tls 2, cfg 3, knl 2
conn rw-base
fragmentation=yes
dpdtimeout=90s
dpddelay=30s
dpdaction=clear
conn rw-config
also=rw-base
reauth=no
rekey=no
ike=aes256-sha2_256-prfsha256-modp1024-modp2048,aes256gcm16-prfsha384-modp3072!
esp=aes256-sha2_256-prfsha256,aes256-sha1,aes256gcm16-modp3072!
leftsubnet=10.0.0.0/8 # Split tunnel config
leftid="vpn.company.net"
leftcert=server.crt
leftsendcert=always # not "never"
left=217.6.20.66
lefthostaccess=yes
rightdns=10.1.3.10, 10.1.3.11
rightsourceip=%static, %dynamic
conn ikev2-pubkey
also=rw-config
keyexchange=ikev2
auto=route
strongswan.conf
---
charon { load_modular = yes plugins { include strongswan.d/charon/*.conf } }
include strongswan.d/*.conf
charon {
install_routes = no
install_virtual_ip = no
crypto_test { bench = yes }
plugins {
attr-sql {
database = sqlite:///var/lib/ipsec/ippool.sqlite3
}
attr {
dns = 10.1.3.10, 10.1.3.11
25 = company.local
split-include = 10.0.0.0/8
split-exclude = 0.0.0.0/0
28675 = company.local
}
}
Here is the log file:
-
Nov 23 10:11:39 2101120420063 charon: 23422[IKE] received
ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Nov 23 10:11:39 2101120420063 charon: 23422[IKE] peer supports MOBIKE
Nov 23 10:11:39 2101120420063 charon: 23422[IKE] authentication of
'vpn.company.net' (myself) with RSA signature successful
Nov 23 10:11:39 2101120420063 charon: 23422[IKE] IKE_SA ikev2-pubkey[18259]
established between 217.6.20.66[vpn.company.net]...188.238.227
.128[joko.cl...@company.fi]
Nov 23 10:11:39 2101120420063 charon: 23422[IKE] IKE_SA ikev2-pubkey[18259]
state change: CONNECTING => ESTABLISHED
Nov 23 10:11:39 2101120420063 charon: 23422[IKE] sending end entity cert "C=DE,
ST=BY, O=Company, CN=vpn.company.net"
Nov 23 10:11:39 2101120420063 charon: 23422[IKE] peer requested virtual IP %any
Nov 23 10:11:39 2101120420063 charon: 23422[CFG] no available address found in
pool 'static'
Nov 23 10:11:39 2101120420063 charon: 23422[CFG] acquired new lease for address
192.168.3.67 in pool 'dynamic'
Nov 23 10:11:39 2101120420063 charon: 23422[IKE] assigning virtual IP
192.168.3.67 to peer 'joko.cl...@company.fi'
Nov 23 10:11:39 2101120420063 charon: 23422[IKE] peer requested virtual IP %any6
Nov 23 10:11:39 2101120420063 charon: 23422[IKE] no virtual IP found for %any6
requested by 'joko.cl...@company.fi'
Nov 23 10:11:39 2101120420063 charon: 23422[IKE] building INTERNAL_IP4_DNS
attribute
Nov 23 10:11:39 2101120420063 charon: 23422[IKE] building INTERNAL_IP4_DNS
attribute
Nov 23 10:11:39 2101120420063 charon: 23422[IKE] building (25) attribute
Nov 23 10:11:39 2101120420063 charon: 23422[IKE] building UNITY_SPLITDNS_NAME
attribute
Nov 23 10:11:39 2101120420063 charon: 23422[IKE] building INTERNAL_IP4_DNS
attribute
Nov 23 10:11:39 2101120420063 charon: 23422[IKE] building INTERNAL_IP4_DNS
attribute
Nov 23 10:11:39 2101120420063 charon: 23422[CFG] looking for a child config for
0.0.0.0/0 ::/0 === 0.0.0.0/0 ::/0
Nov 23 10:11:39 2101120420063 charon: 23422[CFG] proposing traffic selectors
for us:
Nov 23 10:11:39 2101120420063 charon: 23422[CFG] 10.0.0.0/8
Nov 23 10:11:39 2101120420063 charon: 23422[CFG] proposing traffic selectors
for other:
Nov 23 10:11:39 2101120420063 charon: 23422[CFG] 192.168.3.67/32
Nov 23 10:11:39 2101120420063 charon: 23422[CFG] candidate "ikev2-pubkey"
with prio 2+2
Nov 23 10:11:39 2101120420063 charon: 23422[CFG] found matching child config
"ikev2-pubkey" with prio 4
Nov 23 10:11:39 2101120420063 charon: 23422[CFG] selecting proposal
Re: [strongSwan] Problems with CRLs
Am 13.09.18 um 10:55 schrieb Tobias Brunner: > Hi Sven, > >> can nobody help me with this issue? > > What more is there? You already had a look a the source code and found > it's not supported, so... Maybe a second look? It's not my source code, so I could be wrong. And I think it's not an "it's not supported issue" rather than an "it's an error issue". If anybody will confirm this, I would open a bug for it. > And regarding the first one, there is an in-memory certificate/CRL cache > (may be flushed with the `ipsec purge*` commands). I will look into it. Thanks! Sven -- Sven Anders () UTF-8 Ribbon Campaign /\ Support plain text e-mail ANDURAS intranet security AG Messestraße 3 - 94036 Passau - Germany Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 Rechtsform: Aktiengesellschaft - Sitz: Passau - Amtsgericht: Passau HRB 6032 Mitglieder des Vorstands: Dipl.-Inf. Sven Anders, Dipl.-Inf. Marcus Junker Vorsitzender des Aufsichtsrats: RA Mark Peters <>
Re: [strongSwan] Problems with CRLs
Hello!
can nobody help me with this issue?
Or isn't the question worth it?
Regards
Sven
Am 27.08.18 um 23:32 schrieb Sven Anders:
> Am 22.08.2018 um 17:48 schrieb Sven Anders:
>> Hello!
>>
>> We are experiencing two problems when using CRLs.
>> Our Linux systems runs strongSwan 5.6.2.
>>
>>
>> 1) Because we want a hourly update of CRLs and the standard CRLs timeout
>>is 7 days, we created a cronjob, that fetches the latest CRL every hour.
>>
>> This CRL file is named:
>>
>> /etc/ipsec.d/crls/COMPANY-SUB-CA01.crl
>>
>> For a test, I additionally enabled CRL caching, but this did not
>> make any difference:
>>
>> charon {
>> cache_crls = yes
>> }
>>
>>
>> Here is the problematic run:
>>
>> Aug 22 16:54:44 2101120420063 charon: 15510[CFG] rereading crls from
>> '/etc/ipsec.d/crls'
>> Aug 22 16:54:44 2101120420063 charon: 15510[CFG] loaded crl from
>> '/etc/ipsec.d/crls/0dff165cefbd2ddfb18f27e9215a4897b79f3008.crl'
>> Aug 22 16:54:44 2101120420063 charon: 15510[LIB] crl #75 is not newer -
>> existing crl #75 retained
>> Aug 22 16:54:44 2101120420063 charon: 15510[CFG] loaded crl from
>> '/etc/ipsec.d/crls/2d07eba139f0caad8a5ef7b87d542c46bbcd48ab.crl'
>> Aug 22 16:54:44 2101120420063 charon: 15510[LIB] crl #02 is not newer -
>> existing crl #02 retained
>> Aug 22 16:54:44 2101120420063 charon: 15510[CFG] loaded crl from
>> '/etc/ipsec.d/crls/48db6c1436fcdce1dc14b91619344b669e4dee6c.crl'
>> Aug 22 16:54:44 2101120420063 charon: 15510[LIB] crl #01:62:32 is not
>> newer - existing crl #01:62:32 retained
>> Aug 22 16:54:44 2101120420063 charon: 15510[CFG] loaded crl from
>> '/etc/ipsec.d/crls/COMPANY-SUB-CA01.crl'
>> Aug 22 16:54:44 2101120420063 charon: 15510[LIB] crl #77 is newer -
>> existing crl #75 replaced
>>
>> As you can see here, the manually updated CRL is newer (#77) and strongSwan
>> replaces the old one (#75) by this new version. This seems to be correct.
>>
>> In the new (#77) CRL I have the following entry:
>>
>> Serial Number: 250075E60D6340C615C22D00010075
>> Revocation Date: Aug 22 16:49:00 2018 GMT
>> CRL entry extensions:
>> X509v3 CRL Reason Code:
>> Certificate Hold
>>
>> Now, if I try to connect, I get the following output and the user is
>> accepted.
>> But this is wrong, because the certificate is on hold!
>>
>> Aug 22 16:54:53 2101120420063 charon: 15504[CFG] crl is valid: until Aug
>> 30 04:58:47 2018
>> Aug 22 16:54:53 2101120420063 charon: 15504[CFG] using cached crl
>> Aug 22 16:54:53 2101120420063 charon: 15504[CFG] fetching crl from
>> 'http://ca.company-group.local/CertEnroll/COMPANY-SUB-CA01+.crl' ...
>> Aug 22 16:54:53 2101120420063 charon: 15504[LIB] sending request to
>> 'http://ca.company-group.local/CertEnroll/COMPANY-SUB-CA01+.crl'...
>> Aug 22 16:54:53 2101120420063 charon: 15504[CFG] fetching crl from
>> 'http://ca.COMPANY.net/CertEnroll/COMPANY-SUB-CA01+.crl' ...
>> Aug 22 16:54:53 2101120420063 charon: 15504[LIB] sending request to
>> 'http://ca.COMPANY.net/CertEnroll/COMPANY-SUB-CA01+.crl'...
>> Aug 22 16:54:53 2101120420063 charon: 15504[LIB] libcurl request failed
>> [60]: SSL certificate problem, verify that the CA cert is OK. Details:
>> Aug 22 16:54:53 2101120420063 charon: 15504[LIB] error:14090086:SSL
>> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
>> Aug 22 16:54:53 2101120420063 charon: 15504[CFG] crl fetching failed
>> Aug 22 16:54:53 2101120420063 charon: 15504[CFG] certificate status is good
>> Aug 22 16:54:53 2101120420063 charon: 15504[CFG] certificate "DC=local,
>> DC=company-group, CN=COMPANY-SUB-CA01" key: 4096 bit RSA
>> Aug 22 16:54:53 2101120420063 charon: 15504[CFG] using trusted ca
>> certificate "CN=COMPANY-ROOT-CA01"
>> Aug 22 16:54:53 2101120420063 charon: 15504[CFG] checking certificate
>> status of "DC=local, DC=company-group, CN=COMPANY-SUB-CA01"
>> Aug 22 16:54:53 2101120420063 charon: 15504[CFG] ocsp check skipped, no
>> ocsp found
>> Aug 22 16:54:53 2101120420063 charon: 15504[CFG] using trusted
>> certificate "CN=COMPANY-ROOT-CA01"
>> Aug 22 16:54:53 2101120420063 charon: 15504[CFG] crl correctly signed by
>> "CN=COMPANY-ROOT-CA01"
>> Aug 22 16:54:53 2101120420063 charon: 15504[CFG] crl is valid: until Jun
>> 05 21:52:45 2028
>> Aug 22 16:54:53 2101120420063
Re: [strongSwan] Problems with CRLs
Am 22.08.2018 um 17:48 schrieb Sven Anders:
> Hello!
>
> We are experiencing two problems when using CRLs.
> Our Linux systems runs strongSwan 5.6.2.
>
>
> 1) Because we want a hourly update of CRLs and the standard CRLs timeout
>is 7 days, we created a cronjob, that fetches the latest CRL every hour.
>
> This CRL file is named:
>
> /etc/ipsec.d/crls/COMPANY-SUB-CA01.crl
>
> For a test, I additionally enabled CRL caching, but this did not
> make any difference:
>
> charon {
> cache_crls = yes
> }
>
>
> Here is the problematic run:
>
> Aug 22 16:54:44 2101120420063 charon: 15510[CFG] rereading crls from
> '/etc/ipsec.d/crls'
> Aug 22 16:54:44 2101120420063 charon: 15510[CFG] loaded crl from
> '/etc/ipsec.d/crls/0dff165cefbd2ddfb18f27e9215a4897b79f3008.crl'
> Aug 22 16:54:44 2101120420063 charon: 15510[LIB] crl #75 is not newer -
> existing crl #75 retained
> Aug 22 16:54:44 2101120420063 charon: 15510[CFG] loaded crl from
> '/etc/ipsec.d/crls/2d07eba139f0caad8a5ef7b87d542c46bbcd48ab.crl'
> Aug 22 16:54:44 2101120420063 charon: 15510[LIB] crl #02 is not newer -
> existing crl #02 retained
> Aug 22 16:54:44 2101120420063 charon: 15510[CFG] loaded crl from
> '/etc/ipsec.d/crls/48db6c1436fcdce1dc14b91619344b669e4dee6c.crl'
> Aug 22 16:54:44 2101120420063 charon: 15510[LIB] crl #01:62:32 is not
> newer - existing crl #01:62:32 retained
> Aug 22 16:54:44 2101120420063 charon: 15510[CFG] loaded crl from
> '/etc/ipsec.d/crls/COMPANY-SUB-CA01.crl'
> Aug 22 16:54:44 2101120420063 charon: 15510[LIB] crl #77 is newer -
> existing crl #75 replaced
>
> As you can see here, the manually updated CRL is newer (#77) and strongSwan
> replaces the old one (#75) by this new version. This seems to be correct.
>
> In the new (#77) CRL I have the following entry:
>
> Serial Number: 250075E60D6340C615C22D00010075
> Revocation Date: Aug 22 16:49:00 2018 GMT
> CRL entry extensions:
> X509v3 CRL Reason Code:
> Certificate Hold
>
> Now, if I try to connect, I get the following output and the user is accepted.
> But this is wrong, because the certificate is on hold!
>
> Aug 22 16:54:53 2101120420063 charon: 15504[CFG] crl is valid: until Aug
> 30 04:58:47 2018
> Aug 22 16:54:53 2101120420063 charon: 15504[CFG] using cached crl
> Aug 22 16:54:53 2101120420063 charon: 15504[CFG] fetching crl from
> 'http://ca.company-group.local/CertEnroll/COMPANY-SUB-CA01+.crl' ...
> Aug 22 16:54:53 2101120420063 charon: 15504[LIB] sending request to
> 'http://ca.company-group.local/CertEnroll/COMPANY-SUB-CA01+.crl'...
> Aug 22 16:54:53 2101120420063 charon: 15504[CFG] fetching crl from
> 'http://ca.COMPANY.net/CertEnroll/COMPANY-SUB-CA01+.crl' ...
> Aug 22 16:54:53 2101120420063 charon: 15504[LIB] sending request to
> 'http://ca.COMPANY.net/CertEnroll/COMPANY-SUB-CA01+.crl'...
> Aug 22 16:54:53 2101120420063 charon: 15504[LIB] libcurl request failed
> [60]: SSL certificate problem, verify that the CA cert is OK. Details:
> Aug 22 16:54:53 2101120420063 charon: 15504[LIB] error:14090086:SSL
> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
> Aug 22 16:54:53 2101120420063 charon: 15504[CFG] crl fetching failed
> Aug 22 16:54:53 2101120420063 charon: 15504[CFG] certificate status is good
> Aug 22 16:54:53 2101120420063 charon: 15504[CFG] certificate "DC=local,
> DC=company-group, CN=COMPANY-SUB-CA01" key: 4096 bit RSA
> Aug 22 16:54:53 2101120420063 charon: 15504[CFG] using trusted ca
> certificate "CN=COMPANY-ROOT-CA01"
> Aug 22 16:54:53 2101120420063 charon: 15504[CFG] checking certificate
> status of "DC=local, DC=company-group, CN=COMPANY-SUB-CA01"
> Aug 22 16:54:53 2101120420063 charon: 15504[CFG] ocsp check skipped, no
> ocsp found
> Aug 22 16:54:53 2101120420063 charon: 15504[CFG] using trusted
> certificate "CN=COMPANY-ROOT-CA01"
> Aug 22 16:54:53 2101120420063 charon: 15504[CFG] crl correctly signed by
> "CN=COMPANY-ROOT-CA01"
> Aug 22 16:54:53 2101120420063 charon: 15504[CFG] crl is valid: until Jun
> 05 21:52:45 2028
> Aug 22 16:54:53 2101120420063 charon: 15504[CFG] using cached crl
> Aug 22 16:54:53 2101120420063 charon: 15504[CFG] certificate status is good
> Aug 22 16:54:53 2101120420063 charon: 15504[CFG] certificate
> "CN=COMPANY-ROOT-CA01" key: 4096 bit RSA
> Aug 22 16:54:53 2101120420063 charon: 15504[CFG] reached self-signed root
> ca with a path length of 1
> Aug 22 16:54:53 2101120420063 charon: 15504[IKE] authentication of
> 'testu...@company.de' with RSA signatu
[strongSwan] Problems with CRLs
B-CA01+.crl' ... And the delta CRL has an entry with reason "remove from crl" in it. Aug 22 16:01:43 2101120420063 charon: 30400[CFG] using trusted certificate "DC=local, DC=company-group, CN=COMPANY-SUB-CA01" Aug 22 16:01:43 2101120420063 charon: 30400[CFG] crl correctly signed by "DC=local, DC=company-group, CN=COMPANY-SUB-CA01" Aug 22 16:01:43 2101120420063 charon: 30400[CFG] crl is valid: until Aug 29 04:02:43 2018 Aug 22 16:01:43 2101120420063 charon: 30400[CFG] using cached crl Aug 22 16:01:43 2101120420063 charon: 30400[CFG] certificate "DC=local, DC=company-group, CN=COMPANY-SUB-CA01" key: 4096 bit RSA Aug 22 16:01:43 2101120420063 charon: 30400[CFG] using trusted ca certificate "CN=COMPANY-ROOT-CA01" Aug 22 16:01:43 2101120420063 charon: 30400[CFG] certificate "CN=COMPANY-ROOT-CA01" key: 4096 bit RSA Aug 22 16:01:43 2101120420063 charon: 30400[CFG] reached self-signed root ca with a path length of 0 Aug 22 16:01:43 2101120420063 charon: 30400[CFG] using trusted certificate "DC=local, DC=company-group, CN=COMPANY-SUB-CA01" Aug 22 16:01:43 2101120420063 charon: 30400[CFG] crl correctly signed by "DC=local, DC=company-group, CN=COMPANY-SUB-CA01" Aug 22 16:01:43 2101120420063 charon: 30400[CFG] crl is valid: until Aug 24 04:11:38 2018 Aug 22 16:01:43 2101120420063 charon: 30400[CFG] certificate was revoked on Aug 22 14:01:35 UTC 2018, reason: remove from crl Aug 22 16:01:43 2101120420063 charon: 30400[CFG] using cached crl Aug 22 16:01:43 2101120420063 charon: 30400[IKE] no trusted RSA public key found for 'testu...@company.de' But as you can see here, the user is denied. What happened here? Is the (delta) reason "remove from crl" misinterpreted as an revocation reason? Regards Sven Anders -- Sven Anders () UTF-8 Ribbon Campaign /\ Support plain text e-mail ANDURAS intranet security AG Messestrasse 3 - 94036 Passau - Germany Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. - Benjamin Franklin <>
Re: [strongSwan] attr-sql - case insensitive?
Am 05.07.2018 um 18:10 schrieb Tobias Brunner: > Hi Sven, > >> In other words: >> I have to change to code to make it work this way. >> At least the attr-sql plugin code. >> >> Is this correct? > > You can try and see what happens if you don't (i.e. just change the DB). > But I guess you have change some code. > > Regards, > Tobias Hello. I'm using sqlite3 here, because I only need this for static IP assignments. And I tried your idea, but the database code stores the data in a binary format (for example: X'294130303030... ). So no chance here, even if I set the data field to "TEXT NOT NULL COLLATE NOCASE". But thanks for the tips! Regards Sven Anders -- Sven Anders () UTF-8 Ribbon Campaign /\ Support plain text e-mail ANDURAS intranet security AG Messestrasse 3 - 94036 Passau - Germany Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. - Benjamin Franklin
Re: [strongSwan] attr-sql - case insensitive?
Am 04.07.2018 um 16:23 schrieb Tobias Brunner: > Hi Sven, > >> The name in the database matches the name the user configured in >> their settings. So this is very error-prone. >> >> Is it possible to match here case insensitive? >> Or any other ideas? > > The `data` column of the `identities` table in the default schema uses a > binary type (BLOB or varbinary), same goes for the queries where the > argument is of type DB_BLOB (and not DB_TEXT). So the comparison here > will always be via an exact binary match. I guess that's mostly for > ASN.1 DNs, which couldn't be stored/compared directly as text. > > I suppose, if you only use e.g. email addresses as identities (i.e. no > binary DNs) you could probably change the type of that column (e.g. to > TEXT or varchar) and when using MySQL add `collate utf8_unicode_ci` for > a case insensitive comparison. But you'd also need to change the type > in the queries (in the attr-sql plugin and the pool tool, if you use > it). At least I guess that's required, I didn't try what happens if the > argument's type doesn't exactly match that of the column. > > Another option is probably to convert the identities to text and store > and compare them as such, but that would also require several code changes. > > Regards, > Tobias Thank for the answer! In other words: I have to change to code to make it work this way. At least the attr-sql plugin code. Is this correct? Regards Sven Anders -- Sven Anders () UTF-8 Ribbon Campaign /\ Support plain text e-mail ANDURAS intranet security AG Messestrasse 3 - 94036 Passau - Germany Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. - Benjamin Franklin <>
Re: [strongSwan] Checking X509 Extended Key Usage
Hello Andreas,
I'm getting closer by using certificate policies instead of the EKUs.
In your example scenario the CA has the policy set too.
I'm a bit unsure if this is necessary, because a RFC 5280 in section
4.2.1.4 (Certificate Policies) states:
"When a CA does not wish to limit the set of policies for certification
paths that include this certificate, it MAY assert the special policy
anyPolicy, with a value of { 2 5 29 32 0 }."
Does this "MAY" mean, that a root certificate without any policy does
not limit the policy? Or SHOULD I set the special policy, iff I want
no limitation?
It's not really clear here (for me).
How does strongswan evaluate this? Does it need the policy in the root
certificate too and is this correct?
What, if I do NOT own the CA but have a Sub-CA signed by an official CA?
Can I use certification policies then?
Currently I have an user certificate with a specific policy and a
Sub-CA with a "anyPolicy" set. But I cannot connect, if I enable the
"rightcertpolicy" option...
Regards
Sven
Am 22.06.2018 um 11:39 schrieb Andreas Steffen:
> Hi Sven,
>
> the certificate policy must be contained in all certificates
> of the X.509 trust chain. See the following example scenario:
>
> https://www.strongswan.org/testing/testresults5dr/swanctl/rw-ed25519-certpol/
>
> Regards
>
> Andreas
>
> On 20.06.2018 13:41, Sven Anders wrote:
>> Am 20.06.2018 um 10:43 schrieb Andreas Steffen:
>>> Hi Sven,
>>>
>>> you can use certificate policies which are based on OIDs.
>>>
>>> With swanctl.conf:
>>>
>>> remote {
>>> auth = pubkey
>>> cert_policy =
>>> ...
>>> }
>>>
>>> or with ipsec.conf:
>>>
>>> rightcertpolicy=
>>
>> Thanks for pointing me to the right direction. I missed this in the
>> manual page.
>>
>> So the manual page states:
>>
>> left|rightcertpolicy =
>>
>> Comma separated list of certificate policy OIDs the peer's certificate
>> must have.
>> OIDs are specified using the numerical dotted representation. Not
>> supported for IKEv1 connections prior to 5.0.0.
>>
>>
>> If I use the following configuration:
>>
>> conn rw-config
>> also = rw-base
>> ike =
>> aes256-sha2_256-prfsha256-modp1024-modp2048,aes256gcm16-prfsha384-modp3072!
>> esp = aes256-sha2_256-prfsha256,aes256-sha1,aes256gcm16-modp3072!
>> leftsubnet = 10.0.0.0/8 # Split tunnel config
>> leftid = "vpn.mydomain.net" # Must match remote part on the client side
>> leftcert = server.crt# The server certificate to use
>> leftsendcert = always# not "never"
>> left = 10.0.1.99
>>
>> rightdns = 10.0.0.10, 10.0.0.11
>> rightsourceip = %static, %dynamic
>> rightcertpolicy = 1.3.6.1.5.5.7.3.2
>>
>> conn ikev2-pubkey
>> also = rw-config
>> keyexchange = ikev2
>> auto = add
>>
>> I cannot connect and I get the following output:
>>
>> 8235[CFG] ike config match: 1052 (10.0.1.99 89.28.111.222 IKEv2)
>> 8235[CFG] candidate "ikev2-pubkey", match: 20/1/1052 (me/other/ike)
>> 8235[CFG] selected peer config 'ikev2-pubkey'
>> 8235[CFG] using certificate "CN=MYNAME"
>> 8235[CFG] certificate "CN=MYNAME" key: 4096 bit RSA
>> 8235[CFG] using trusted intermediate ca certificate "DC=local,
>> DC=my-group, CN=MY-CA01"
>> 8235[CFG] certificate "DC=local, DC=my-group, CN=MY-SUB-CA01" key: 4096
>> bit RSA
>> 8235[CFG] using trusted ca certificate "CN=MY-ROOT-CA01"
>> 8235[CFG] certificate "CN=MY-ROOT-CA01" key: 4096 bit RSA
>> 8235[CFG] reached self-signed root ca with a path length of 1
>> 8235[IKE] authentication of 'MYNAME@my-group.local' with RSA signature
>> successful
>> 8235[CFG] constraint requires cert policy 1.3.6.1.5.5.7.3.2
>> 8235[CFG] selected peer config 'ikev2-pubkey' inacceptable: non-matching
>> authentication done
>> 8235[CFG] no alternative config found
>>
>> If I remove the "rightcertpolicy" line, I can connect without problems.
>>
>> Any ideas?
>>
>>> On 20.06.2018 09:49, Sven Anders wrote:
>>>> Hi Andreas,
>>>>
>>>> Am 19.06.2018 um 18:47 schrieb Andreas Steffen:
>>>>> Hi Sven,
>>>>>
>>>>> according to section 5.1.3.12. "ExtendedKeyUsage" of RFC 4945
>>>>> "The Internet IP Security PKI Profile of IKEv1/ISAKMP, I
[strongSwan] attr-sql - case insensitive?
Hello! I'm using the "attr-sql" plugin to make static user IP assignments. WRONG: The database matches the CN in the certificate. The name in the database matches the name the user configured in their settings. So this is very error-prone. Is it possible to match here case insensitive? Or any other ideas? Regards Sven Anders PS: Sorry for the first wrong posting... -- Sven Anders () UTF-8 Ribbon Campaign /\ Support plain text e-mail ANDURAS intranet security AG Messestrasse 3 - 94036 Passau - Germany Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. - Benjamin Franklin
[strongSwan] attr-sql - case insensitive?
Hello! I'm using the "attr-sql" plugin to make static user IP assignments. The database matches the CN in the certificate. Is it possible to match here case insensitive? Regards Sven Anders -- Sven Anders () UTF-8 Ribbon Campaign /\ Support plain text e-mail ANDURAS intranet security AG Messestrasse 3 - 94036 Passau - Germany Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. - Benjamin Franklin
Re: [strongSwan] Checking X509 Extended Key Usage
Am 20.06.2018 um 10:43 schrieb Andreas Steffen:
> Hi Sven,
>
> you can use certificate policies which are based on OIDs.
>
> With swanctl.conf:
>
> remote {
> auth = pubkey
> cert_policy =
> ...
> }
>
> or with ipsec.conf:
>
> rightcertpolicy=
Thanks for pointing me to the right direction. I missed this in the
manual page.
So the manual page states:
left|rightcertpolicy =
Comma separated list of certificate policy OIDs the peer's certificate must
have.
OIDs are specified using the numerical dotted representation. Not supported
for IKEv1 connections prior to 5.0.0.
If I use the following configuration:
conn rw-config
also = rw-base
ike =
aes256-sha2_256-prfsha256-modp1024-modp2048,aes256gcm16-prfsha384-modp3072!
esp = aes256-sha2_256-prfsha256,aes256-sha1,aes256gcm16-modp3072!
leftsubnet = 10.0.0.0/8 # Split tunnel config
leftid = "vpn.mydomain.net" # Must match remote part on the client side
leftcert = server.crt# The server certificate to use
leftsendcert = always# not "never"
left = 10.0.1.99
rightdns = 10.0.0.10, 10.0.0.11
rightsourceip = %static, %dynamic
rightcertpolicy = 1.3.6.1.5.5.7.3.2
conn ikev2-pubkey
also = rw-config
keyexchange = ikev2
auto = add
I cannot connect and I get the following output:
8235[CFG] ike config match: 1052 (10.0.1.99 89.28.111.222 IKEv2)
8235[CFG] candidate "ikev2-pubkey", match: 20/1/1052 (me/other/ike)
8235[CFG] selected peer config 'ikev2-pubkey'
8235[CFG] using certificate "CN=MYNAME"
8235[CFG] certificate "CN=MYNAME" key: 4096 bit RSA
8235[CFG] using trusted intermediate ca certificate "DC=local, DC=my-group,
CN=MY-CA01"
8235[CFG] certificate "DC=local, DC=my-group, CN=MY-SUB-CA01" key: 4096 bit
RSA
8235[CFG] using trusted ca certificate "CN=MY-ROOT-CA01"
8235[CFG] certificate "CN=MY-ROOT-CA01" key: 4096 bit RSA
8235[CFG] reached self-signed root ca with a path length of 1
8235[IKE] authentication of 'MYNAME@my-group.local' with RSA signature
successful
8235[CFG] constraint requires cert policy 1.3.6.1.5.5.7.3.2
8235[CFG] selected peer config 'ikev2-pubkey' inacceptable: non-matching
authentication done
8235[CFG] no alternative config found
If I remove the "rightcertpolicy" line, I can connect without problems.
Any ideas?
> On 20.06.2018 09:49, Sven Anders wrote:
>> Hi Andreas,
>>
>> Am 19.06.2018 um 18:47 schrieb Andreas Steffen:
>>> Hi Sven,
>>>
>>> according to section 5.1.3.12. "ExtendedKeyUsage" of RFC 4945
>>> "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX"
>>> the IPsec User EKU is deprecated:
>>>
>>>The CA SHOULD NOT include the ExtendedKeyUsage (EKU) extension in
>>>certificates for use with IKE. Note that there were three IPsec-
>>>related object identifiers in EKU that were assigned in 1999. The
>>>semantics of these values were never clearly defined. The use of
>>>these three EKU values in IKE/IPsec is obsolete and explicitly
>>>deprecated by this specification. CAs SHOULD NOT issue certificates
>>>for use in IKE with them. (For historical reference only, those
>>>values were id-kp-ipsecEndSystem, id-kp-ipsecTunnel, and id-kp-
>>>ipsecUser.)
>>>
>>> The only EKU flags our X.509 class supports are ocspSigning, ClientAuth,
>>> and ServerAuth.
>>
>> yes I know, that "IPsec User" is deprecated (I expected this remark would
>> come), but I used it as an example here. We want to use our own OIDs.
>>
>> Because the ExtendedKeyUsage is a just a list of OIDs and there are no
>> restrictions I know of, we use this to differentiate between classes of
>> certificates we issue.
>>
>> If this isn't supported, how can we use StrongSwan to distinguish between
>> groups of certificates without using Sub-CAs?
>> We cannot be the first with this requirement...
>>
>>> On 19.06.2018 18:22, Sven Anders wrote:
>>>>
>>>> We want to limit the usage of certificates by defining certain
>>>> "Extended Key Usage" (EKU) flags to them.
>>>>
>>>> As an example, we want to set the "IPSec User" usage (1.3.6.1.5.5.7.3.7)
>>>> and
>>>> only allow connection via IPSec, if it is set. We may use some other flags
>>>> out of our own space too.
>>>>
>>>> How can I check in StrongSwan, if a certain EKU exists?
Regards
Sven Anders
--
Sven Anders () UTF-8 Ribbon Campaign
/\ Support plain text e-mail
ANDURAS intranet security AG
Messestrasse 3 - 94036 Passau - Germany
Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55
Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
- Benjamin Franklin
Re: [strongSwan] Checking X509 Extended Key Usage
Hi Andreas, Am 19.06.2018 um 18:47 schrieb Andreas Steffen: > Hi Sven, > > according to section 5.1.3.12. "ExtendedKeyUsage" of RFC 4945 > "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX" > the IPsec User EKU is deprecated: > >The CA SHOULD NOT include the ExtendedKeyUsage (EKU) extension in >certificates for use with IKE. Note that there were three IPsec- >related object identifiers in EKU that were assigned in 1999. The >semantics of these values were never clearly defined. The use of >these three EKU values in IKE/IPsec is obsolete and explicitly >deprecated by this specification. CAs SHOULD NOT issue certificates >for use in IKE with them. (For historical reference only, those >values were id-kp-ipsecEndSystem, id-kp-ipsecTunnel, and id-kp- >ipsecUser.) > > The only EKU flags our X.509 class supports are ocspSigning, ClientAuth, > and ServerAuth. yes I know, that "IPsec User" is deprecated (I expected this remark would come), but I used it as an example here. We want to use our own OIDs. Because the ExtendedKeyUsage is a just a list of OIDs and there are no restrictions I know of, we use this to differentiate between classes of certificates we issue. If this isn't supported, how can we use StrongSwan to distinguish between groups of certificates without using Sub-CAs? We cannot be the first with this requirement... > On 19.06.2018 18:22, Sven Anders wrote: >> >> We want to limit the usage of certificates by defining certain >> "Extended Key Usage" (EKU) flags to them. >> >> As an example, we want to set the "IPSec User" usage (1.3.6.1.5.5.7.3.7) and >> only allow connection via IPSec, if it is set. We may use some other flags >> out of our own space too. >> >> How can I check in StrongSwan, if a certain EKU exists? Regards Sven Anders -- Sven Anders () UTF-8 Ribbon Campaign /\ Support plain text e-mail ANDURAS intranet security AG Messestrasse 3 - 94036 Passau - Germany Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. - Benjamin Franklin
[strongSwan] Checking X509 Extended Key Usage
Hello! We want to limit the usage of certificates by defining certain "Extended Key Usage" (EKU) flags to them. As an example, we want to set the "IPSec User" usage (1.3.6.1.5.5.7.3.7) and only allow connection via IPSec, if it is set. We may use some other flags out of our own space too. How can I check in StrongSwan, if a certain EKU exists? Regards Sven Anders -- Sven Anders () UTF-8 Ribbon Campaign /\ Support plain text e-mail ANDURAS intranet security AG Messestrasse 3 - 94036 Passau - Germany Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. - Benjamin Franklin
Re: [strongSwan] Strongswan 5.6.2: Segfault if charondebug = cfg > 2
Thanks, with -O2 it works. My previous version (5.5.1) worked with -O3 and the same compiler without problems. Is this a common problem and are there any recommendations regarding the optimization or compiler flags to use (or not to use)? Regards Sven Am 05.06.2018 um 22:16 schrieb Noel Kuntze: > Hi, > > Try with O2, not O3. > > Kind regards > > Noel > > On 05.06.2018 22:11, Sven Anders wrote: >> Hello! >> >> I'm experiencing a segmentation fault, if I set charondebug = cfg to a value >> greater than 2. >> I'm using Strongwan 5.6.2 on Linux kernel 4.1.39 on a 32 bit system. >> >> Strongswan was compiled with: >> >> ./configure CFLAGS="-g -march=core2 -O3 -fstack-protector" >> LDFLAGS="-D_FORTIFY_SOURCE=2 -fPIE -pie -Wl,-z,relro,-z,now" --prefix=/usr >> --sysconfdir=/etc --enable-aes --enable-bliss --enable-blowfish --enable-ccm >> --enable-chapoly --enable-cmac --enable-ctr --enable-des ... Mit freundlichen Grüßen Sven Anders -- Sven Anders () UTF-8 Ribbon Campaign /\ Support plain text e-mail ANDURAS intranet security AG Messestraße 3 - 94036 Passau - Germany Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 Rechtsform: Aktiengesellschaft - Sitz: Passau - Amtsgericht: Passau HRB 6032 Mitglieder des Vorstands: Dipl.-Inf. Sven Anders, Dipl.-Inf. Marcus Junker Vorsitzender des Aufsichtsrats: RA Mark Peters <>
[strongSwan] Strongswan 5.6.2: Segfault if charondebug = cfg > 2
Phones with IKEv1 and passwords on radius/DC) #conn ikev1-pubkey-xauth-radius #also=rw-config #keyexchange=ikev1 ##rightauth=pubkey #rightauth2=eap-radius #xauth=server #auto=add # this requires the xauth-generic plugin. #conn ikev1-hybrid #also=rw-config #keyexchange=ikev1 #rightauth=xauth-generic #xauth=server #- # IKEv2 #- # use IKEv2 with client certificate only conn ikev2-pubkey also=rw-config keyexchange=ikev2 auto=add ## IF you need to support several EAP methods at the same time, you need to ## use eap-dynamic and not use any other conn with eap settings. ## Add the settings for the eap-dynamic plugin to your strongswan.conf file. # #conn ikev2-eap #also=rw-config #keyexchange=ikev2 #rightauth=eap-dynamic #eap_identity=%identity #auto=add # # this requires the eap-tls plugin. #conn ikev2-eap-tls #also=rw-base #keyexchange=ikev2 #rightauth=eap-tls #eap_identity=%identity #auto=add ## this requires the eap-gtc plugin. #conn ikev2-eap-gtc #also=rw-config #keyexchange=ikev2 #rightauth=eap-gtc #eap_identity=%identity #auto=add # this requires the eap-mschapv2 plugin. # (Apple clients with cert+password usually goes here) #conn ikev2-eap-mschapv2 #also=rw-config #keyexchange=ikev2 #auto=add ## right - remote (client) side #rightauth=eap-mschapv2 #eap_identity=%identity # Use RADIUS EAP plugin #conn ikev2-eap-radius #also=rw-config #keyexchange=ikev2 #auto=add ## right - remote (client) side #rightauth=eap-radius #eap_identity=%identity Regards Sven Anders -- Sven Anders () UTF-8 Ribbon Campaign /\ Support plain text e-mail ANDURAS intranet security AG Messestrasse 3 - 94036 Passau - Germany Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. - Benjamin Franklin <>
[strongSwan] iPhone, iOS with TLS+EAP
Hello! I'm trying to get the IPSec connection of the iPhone to work with StrongSwan. Currently it runs with the old racoon (ipsec-tools) and IKEv1. In the old configuration the password is checked against the AD via the LDAP module. We want to change to StrongSwan and use IKEv2. I've got the connection running following the instructions on the web-site and many experiments. In my configuration I'm using the 'eap-mschapv2' module and specified the password in the /etc/ipsec.secret file. I have three questions: 1) Is it possible to check the EAP password without using a radius server? If so, which module must I use? 2) Can I use a IKEv2 iOS <-> StrongSwan connection verified by certificates only? 3) I experimented with the parameters and have the feeling if I use the EAP password check the certificate isn't check any longer? I replaced the CA certificate on the server with a wrong (none-matching) CA but I still can connect to the server. Do I have an error in reasoning here? I expected the connection to fail, because the server could not match the incoming certificate from the iPhone to the servers CA!? Some details: Linux strongSwan U5.5.1/K4.1.39 ipsec.conf: config setup uniqueids=no charondebug = ike 2, net 2, pts 2, lib 2, tls 2, cfg 3, knl 2 conn rw-base fragmentation=yes dpdtimeout=90s dpddelay=30s dpdaction=clear conn rw-config also=rw-base keyexchange=ikev2 reauth=no rekey=no ike=aes192gcm16-aes128gcm16-aes192-prfsha256-ecp256-ecp521,aes192-sha256-modp3072 esp=aes192gcm16-aes128gcm16-aes192-ecp256,aes192-sha256-modp3072 leftsubnet=0.0.0.0/0,::/0 leftid="ipsec.domain.net" leftcert=server.crt leftsendcert=always rightdns=10.1.3.10 #rightca="C=DE, L=Somewhere, O=Firm, OU=IT, DC=local, DC=group, CN=Firm CA" rightsourceip=172.16.252.0/24 conn ikev2-pubkey also=rw-config auto=add conn ikev2-eap-mschapv2 also=rw-config auto=add rightauth=eap-mschapv2 eap_identity=%identity ipsec.secrets: : RSA server.key user : PSK "test" user %any% : EAP "test" Regards Sven Anders -- Sven Anders <and...@anduras.de> () UTF-8 Ribbon Campaign /\ Support plain text e-mail ANDURAS intranet security AG Messestrasse 3 - 94036 Passau - Germany Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. - Benjamin Franklin <>
Re: [strongSwan] Problem with pcrypt
Am 15.09.2017 um 19:27 schrieb Noel Kuntze: > Hi, > > I guess ksoftirqd is rotating and kworker, too? If that's the case, you're > suffering from > an extremely disadvantageous distribution of ESP packets. Hmmm. I did not see all CPUs are saturated. Only two CPUs are under load and the soft-irqs are under 5%. kworker is under 5% too. > You need to set the number of RX and TX queues on the card to the number of > cores and > use RSS to distribute the SAs correctly over all queues. Bind one RX and one > TX queue to one core each. What tool to I use for this? > Then use AES based ciphers, so you can use AES-NI. You can then get line > speed per CHILD_SA. > > Pcrypt has some overhead due to synchronisation, so if your setup's > performance problem is not caused > by cipher execution time, pcrypt will not improve the situation. What bothers me is, that the throughput is decreasing. I can accept the due to synchronisation the throughput is not increasing, but decreasing? > Use aes128gcm8. aes256gcm16 causes unnecessary overhead and costs more > performance. Which ciphers do you suggest/recommend? Do you know a working configuration that I can use as a reference? > Disabling replay protection does not improve performance. Ok, I did read about this in some posting, so I tried this too. Regards Sven Anders -- Sven Anders <and...@anduras.de> () UTF-8 Ribbon Campaign /\ Support plain text e-mail ANDURAS intranet security AG Messestrasse 3 - 94036 Passau - Germany Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. - Benjamin Franklin <>
[strongSwan] Problem with pcrypt
TABLISHED 28 minutes ago,
10.10.99.1[moon.strongswan.org]...10.10.99.2[sun.strongswan.org]
net-net[1]: IKEv2 SPIs: 98a6d3eeeaf1f9c0_i* a25f94aff1cdec12_r, public key
reauthentication in 25 minutes
net-net[1]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
net-net{2}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: c0b03d25_i c07fc07c_o
net-net{2}: AES_GCM_16_256/ESN, 94353752 bytes_i, 5965332882 bytes_o,
rekeying in 11 seconds
net-net{2}: 192.168.183.0/24 === 192.168.184.0/24
net-net{3}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: c770da0f_i c8fe02d2_o
net-net{3}: AES_GCM_16_256/ESN, 0 bytes_i, 0 bytes_o, rekeying in 11
minutes
net-net{3}: 192.168.183.0/24 === 192.168.184.0/24
> ip xfrm state
src 10.10.99.1 dst 10.10.99.2
proto esp spi 0xc07fc07c reqid 1 mode tunnel
replay-window 0 flag af-unspec
aead rfc4106(gcm(aes))
0xcbcc5acbe14362c202a98286a72ea9b25f2f054435413c7097e476ed3e7c6d0b5d6c6f1d 128
anti-replay context: seq 0x0, oseq 0x3ef313, bitmap 0x
src 10.10.99.2 dst 10.10.99.1
proto esp spi 0xc0b03d25 reqid 1 mode tunnel
replay-window 0 flag af-unspec
aead rfc4106(gcm(aes))
0x58ae85c2c38b8102aabc3d8f14d62988e8935ebbc84a83eff13a3bd831a5fa1b36768b3b 128
anti-replay context: seq 0x0, oseq 0x0, bitmap 0x
> cat /proc/crypto | grep -C10 pcrypt
name : seqiv(rfc4106(gcm(aes)))
driver : seqiv(pcrypt(rfc4106-gcm-aesni))
module : seqiv
priority : 500
refcnt : 6
selftest : passed
internal : no
type : aead
async: yes
blocksize: 1
ivsize : 8
maxauthsize : 16
geniv:
name : rfc4106(gcm(aes))
driver : pcrypt(rfc4106-gcm-aesni)
module : pcrypt
priority : 500
refcnt : 6
selftest : passed
internal : no
type : aead
async: yes
blocksize: 1
ivsize : 8
maxauthsize : 16
geniv:
> cpuinfo (8 CPUs for each VM instance):
processor : 7
vendor_id : GenuineIntel
cpu family : 6
model : 79
model name : Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz
stepping: 1
microcode : 0xb1f
cpu MHz : 2197.455
cache size : 25600 KB
physical id : 14
siblings: 1
core id : 0
cpu cores : 1
apicid : 14
initial apicid : 14
fpu : yes
fpu_exception : yes
cpuid level : 20
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm
constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc
aperfmperf eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic
movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm
abm 3dnowprefetch epb fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 invpcid
rtm rdseed adx smap xsaveopt dtherm ida arat pln pts
bugs:
bogomips: 4394.91
clflush size: 64
cache_alignment : 64
address sizes : 42 bits physical, 48 bits virtual
power management:
> ip xfrm policy
src 192.168.184.0/24 dst 192.168.183.0/24
dir fwd priority 2883
tmpl src 10.10.99.2 dst 10.10.99.1
proto esp reqid 1 mode tunnel
src 192.168.184.0/24 dst 192.168.183.0/24
dir in priority 2883
tmpl src 10.10.99.2 dst 10.10.99.1
proto esp reqid 1 mode tunnel
src 192.168.183.0/24 dst 192.168.184.0/24
dir out priority 2883
tmpl src 10.10.99.1 dst 10.10.99.2
proto esp reqid 1 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0
src ::/0 dst ::/0
socket in priority 0
src ::/0 dst ::/0
socket out priority 0
src ::/0 dst ::/0
socket in priority 0
src ::/0 dst ::/0
socket out priority 0
--
Sven Anders <and...@anduras.de> () UTF-8 Ribbon Campaign
/\ Support plain text e-mail
ANDURAS intranet security AG
Messestrasse 3 - 94036 Passau - Germany
Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55
Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
- Benjamin Franklin
<>
