[strongSwan] Combined auth methods for IKEv2?
brent s.
bts at square-r00t.net
Tue Jul 13 23:22:28 CEST 2021
I'm currently trying to get IKEv2 to auth properly and having... issues.
First, I need to find out if this sort of thing is possible. I have
attached the relevant (scrubbed/redacted) conn profiles, pools, etc. for
the responder (the requester, in my test cases, is the Android
Strongswan app) along with logs of the responder and requester.
If it IS possible, what am I doing incorrectly?
The responder and requester both have certificates signed by the same CA
(an intermediate, in this case, but the chain is configured correctly as
far as I can tell).
Upon receiving a request with a valid certificate for a requestor, the
requester would then face a second auth round of EAP-Radius for a
username/password... except I get these errors on the responder:
Jul 12 22:01:08 fqdn.domain.tld charon-systemd[18204]: constraint check
failed: EAP identity '%any' required
Jul 12 22:01:08 fqdn.domain.tld charon-systemd[18204]: selected peer
config 'ikev2_fb_responder' unacceptable: non-matching authentication done
I feel like this is definitely possible, and I seem to recall an example
config that even demonstrates it, but I'm not sure what's going on.
Note that the eap-radius phase doesn't seem to even initiate as there's
nothing in the RADIUS logs.
In the attached files:
- the requester IP has been changed to 203.0.113.2
-- the requester's LAN IP has been changed to 192.0.2.2
- the responder IP has been changed to 198.51.100.2
- the FQDN of the responder has been changed to fqdn.domain.tld (and
the relevant domain references have been changed to domain.tld as such)
- the org name has been changed (certificates, etc.) to FooBar
-------------- next part --------------
########################################################################
# #
# THIS FILE IS MANAGED BY SALT - DO NOT EDIT #
# #
# The contents of this file are managed by Salt. Any changes to this #
# file may be overwritten automatically and without warning. #
########################################################################
ikev1_responder {
version = 1
local_addrs = 198.51.100.2/32,2001:DB8:000F:1/128
#pull = no
encap = yes
dpd_delay = 35s
dpd_timeout = 200s
reauth_time = 0
rekey_time = 0
pools = responder_ipv4,responder_ipv6_ula
proposals = aes256-sha512-sha2_384-prfsha384-modp1024, aes256gcm16-aes256gcm12-aes128gcm16-aes128gcm12-aesxcbc-sha256-sha1-modp4096-modp2048-modp1024, aes256-aes128-sha256-sha1-modp4096-modp2048, default
local {
auth = psk
id = %any
}
remote {
auth = psk
round = 0
}
remote {
auth = xauth-radius
round = 1
}
children {
net {
esp_proposals = aes128gcm12-aes128gcm16-aes256gcm12-aes256gcm16-modp4096-modp2048-modp1024, aes128-aes256-sha1-sha256-modp4096-modp2048-modp1024, default
local_ts = 0.0.0.0/0,::/0
}
}
}
ikev2_fb_responder {
version = 2
local_addrs = 198.51.100.2/32,2001:DB8:000F:1/128
send_cert = always
fragmentation = yes
pools = responder_ipv4,responder_ipv6_ula
proposals = aes256-sha2_384-sha512-prfsha384-modp1024, aes256gcm16-aes256gcm12-aes128gcm16-aes128gcm12-aesxcbc-sha256-sha1-modp4096-modp2048-modp1024, aes256-aes128-sha256-sha1-modp4096-modp2048, default
encap = yes
dpd_delay = 35s
dpd_timeout = 200s
send_certreq = yes
reauth_time = 0
rekey_time = 0
local {
auth = pubkey
certs = /etc/pki/tls/certs/fb_responder.pem
#id = O=FooBar (https://foobar.tld/), OU=nodes, CN=fqdn.domain.tld
id = @fqdn.domain.tld
}
remote {
auth = pubkey
id = O=FooBar (https://foobar.tld/), OU=nodes, CN=*
cacerts = /etc/pki/ca-trust/source/anchors/FooBar_CA.pem,/etc/pki/ca-trust/source/anchors/FooBar_Intermediate.pem
round = 0
}
remote {
auth = eap-radius
eap_id = %any
round = 1
}
children {
net {
esp_proposals = aes128gcm12-aes128gcm16-aes256gcm12-aes256gcm16-modp4096-modp2048-modp1024, aes128-aes256-sha1-sha256-modp4096-modp2048-modp1024, default
local_ts = 0.0.0.0/0,::/0
rekey_time = 0
}
}
}
ikev2_le_responder {
version = 2
local_addrs = 198.51.100.2/32,2001:DB8:000F:1/128
send_cert = always
pools = responder_ipv4,responder_ipv6_ula
proposals = aes256-sha2_384-sha512-prfsha384-modp1024, aes256gcm16-aes256gcm12-aes128gcm16-aes128gcm12-aesxcbc-sha256-sha1-modp4096-modp2048-modp1024, aes256-aes128-sha256-sha1-modp4096-modp2048, default
encap = yes
dpd_delay = 35s
dpd_timeout = 200s
send_certreq = no
reauth_time = 0
rekey_time = 0
local {
auth = pubkey
certs = /etc/letsencrypt/live/fqdn.domain.tld/fullchain.pem
#id = CN=fqdn.domain.tld
id = @fqdn.domain.tld
}
remote {
auth = eap-radius
eap_id = %any
}
children {
net {
esp_proposals = aes128gcm12-aes128gcm16-aes256gcm12-aes256gcm16-modp4096-modp2048-modp1024, aes128-aes256-sha1-sha256-modp4096-modp2048-modp1024, default
local_ts = 0.0.0.0/0,::/0
rekey_time = 0
}
}
}
-------------- next part --------------
responder_ipv4 {
addrs = 10.9.0.0/24
dns = 9.9.9.10,149.112.112.10
}
responder_ipv6_ula {
addrs = fc00:1:beef:cafe::/64
dns = 9.9.9.10,149.112.112.10
}
# This is not used anywhere/anyhow, but can theoretically be used to directly assign addresses to clients in a
# GRE-like fashion.
#responder_ipv6_pub {
# addrs = 2001:DB8:000F:1/128
# dns = 2620:fe::10,2620:fe::fe:10
#}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: requester.log
Type: text/x-log
Size: 24336 bytes
Desc: not available
URL: <http://lists.strongswan.org/pipermail/users/attachments/20210713/9bd751a1/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: responder.log
Type: text/x-log
Size: 8100 bytes
Desc: not available
URL: <http://lists.strongswan.org/pipermail/users/attachments/20210713/9bd751a1/attachment-0003.bin>
-------------- next part --------------
ike_responder {
secret = foobar
# id = %any
id = responder_ikev1
}
private_le_responder {
file = /etc/strongswan/swanctl/private/le_responder.pem
}
private_pki_responder {
file = /etc/strongswan/swanctl/private/fb_responder.pem
}
More information about the Users
mailing list