Closed whatever7777 closed 1 year ago
can you try to patch with https://github.com/opnsense/core/commit/3af487bcf65a4d8a32ea999f16f1a932620e80e7 ?
opnsense-patch 3af487b
Just FYI: 23.1.3 includes that patch so patching it reverts it.
Cheers, Franco
oops, my mistake, let me check if anything else changed then between 23.1 and 23.1.3 that's relevant.
for eap-tls I can't really find relevant changes to be honest. the contents (without private data) of /usr/local/etc/swanctl/swanctl.conf
are relevant here. Any log messages in IPsec about the connection not being accepted as well.
On my systems the 23.1.3 update also broke the IPSec VPN.
Reverting the strongswan package with opnsense-revert -r 23.1.1 strongswan
is a temporary solution.
The logs are filled with "success" statements. Never any errors.
I can also confirm that reverting the strongswan package as described by devNan0 does indeed fix the issue.
Hmm, so strongswan stable release caused this? It's pretty well documented so we can pin down the faulty change https://github.com/strongswan/strongswan/releases/tag/5.9.10
Adding TLS 1.3 support to EAP-TLS sounds like trouble https://github.com/strongswan/strongswan/commit/5401a74d36 if the other end doesn't comply?
On my systems the 23.1.3 update also broke the IPSec VPN. Reverting the strongswan package with
opnsense-revert -r 23.1.1 strongswan
is a temporary solution.
Keep that one in mind: https://www.strongswan.org/blog/2023/03/02/strongswan-vulnerability-(cve-2023-26463).html
Same issue here -- point-to-site tunnel with EAP-TLS authentication for clients works fine with strongSwan 5.9.9 and breaks with 5.9.10. Using the Windows 11 built-in IKEv2 client. As pointed out, 5.9.9 has a DoS and potential RCE vulnerability with EAP-TLS, so downgrading is not a viable workaround when using EAP-TLS.
Prompted by @fichtner 's observation, I discovered that you can work around the issue by forcing TLS1.3:
# /usr/local/etc/strongswan.opnsense.d/tls-workaround.conf
libtls {
version_min = 1.3
version_max = 1.3
}
Note that I tried to limit the version constraints to the eap-tls
plugin but wasn't successful in doing so. If anyone knows how to do it, I'd appreciate your sharing it here -- it'd be nice to limit the blast radius from this change.
Some part of that commit's refactoring probably caused TLS1.2 to stop working (I'm guessing it's something to do with indication_sent_received
).
Prompted by @fichtner 's observation, I discovered that you can work around the issue by forcing TLS1.3:
loved the idea. sadly most modern iOS isn't capable of TLS1.3 in IKEv2... https://developer.apple.com/documentation/devicemanagement/vpn/ikev2
There is a fix branch here as per strongswan dev suggestion: https://github.com/strongswan/strongswan/commits/eap-tls-fix
I can build a test package now and report back :)
Sorry for the delay, here it is!
# pkg add -f https://pkg.opnsense.org/FreeBSD:13:amd64/snapshots/misc/strongswan-5.9.10_1.pkg
Cheers, Franco
Can confirm that the above build works for me, at least š
Works for me as well. Thanks a lot! š
Yay, thanks to all. We will ship this in 23.1.4 next week. š
Important notices
Before you add a new report, we ask you kindly to acknowledge the following:
Describe the bug
IPSec IKEv2 RSA (local) + EAP-TLS (remote) is broken on 23.1.3. When a client tries to connect, it immediately disconnects and the tunnel is never established. The logs display no errors. IPSec IKEv2 RSA (local) + EAP-TLS (remote) works in 23.1 (same config).
To Reproduce
Steps to reproduce the behavior:
Expected behavior
IPSec IKEv2 RSA (local) + EAP-TLS (remote) should work on 23.1.3.