IPsec v2 - EAP-TLS Support
-
aha, interesting. I tried it without the client cert and it did work this time. Yesterday when I tried, it didn't, but then again I shuffled around so many certs I probably had something else messed up. I'll amend the doc shortly.
I'll try out EAP-TLS and make a doc for that, too, once I get it running.
-
OK, I removed the client cert parts from the first article:
https://doc.pfsense.org/index.php/IKEv2_with_EAP-MSCHAPv2
And then adapted it for EAP-TLS also:
https://doc.pfsense.org/index.php/IKEv2_with_EAP-TLS
Everything look OK?
I haven't had a chance to properly/fully test the EAP-TLS path, first try the server rejected the cert, which means I probably didn't have the SAN bits right. Will try again tomorrow. -
Look's good, but I have some notes.
I'm using the DNS name of my pfSense as SAN, not my IP, but I think that should work too.
In P2 PFS 2 / additional hash and encryoption algorithms are also possible.
You also have to import the cert to the User store, not the Machine store, if you want to use the machine store, you have to change your connection (not tested, verified):
Set Authentication / Use machine certificates
-
Thanks for the details. I have this working to a point. I can connect from my Windows Phone 8.1 device and access everything on the internal network, however, I want to have it pass ALL traffic from the mobile device through the VPN connection. I have the VPN configuration on the phone set to pass all traffic and I have the IPsec firewall rule set to allow any/any but nothing gets out to the internet via the connection.
I tried unchecking the "Provide a list of accessible networks to clients" box in the Mobile clients config page but it still isn't working. Ideas?
-
Okay, I found a solution to my problem. Under the Phase 2 - Local Network config, I needed to change it to:
Type: Network
Address: 0.0.0.0/0That lets all traffic pass through the VPN including Internet traffic.
-
I'm using the DNS name of my pfSense as SAN, not my IP, but I think that should work too.
Yes that should work as long as the identifier set on the IPsec Phase 1 matches the CN of the cert the client should be able to use either the CN or a SAN to connect. Though even that check can be disabled on the client side with some of the advanced options I believe, it's better to have it enabled.
In P2 PFS 2 / additional hash and encryoption algorithms are also possible.
Yes, I expect several more combinations to work, I just wanted to document one that was specifically known to work and was reasonably secure. We can add more known-good combinations to the list as they are found.
You also have to import the cert to the User store, not the Machine store, if you want to use the machine store, you have to change your connection (not tested, verified):
Set Authentication / Use machine certificates
I didn't get it working with Machine Certificates, but using it in the local user store I was able to get it running fine so long as I had the CN also as a DNS type SAN. I adjusted the docs to reflect that.
-
I have tried to configure EAP-TLS according to the guide, but using DNS instead of IP for SAN in server-cert.
But when using a server-cert generated with SAN DNS=site.domain.com, I see the following in the pfsense log:
charon: 14[IKE] no private key found for 'C=NO, ST=Area, L=City, O=Org, E=user@domain.com, CN=site.domain.com'I have tried without the SAN conf in the server-cert, but then the client complains over the identity.
The client is StrongSwan on android.
Any idea what might be wrong in my setup?
Jan 21 22:15:23 charon: 14[NET] sending packet: from yyy.yyy.yyy.yyy[4500] to 77.16.3.108[55904] (80 bytes) Jan 21 22:15:23 charon: 14[ENC] generating IKE_AUTH response 1 [ N(AUTH_FAILED) ] Jan 21 22:15:23 charon: 14[IKE] no private key found for 'C=NO, ST=Area, L=City, O=Org, E=user@domain.com, CN=site.domain.com' Jan 21 22:15:23 charon: 14[IKE] <con2|50>no private key found for 'C=NO, ST=Area, L=City, O=Org, E=user@domain.com, CN=site.domain.com' Jan 21 22:15:23 charon: 14[IKE] peer supports MOBIKE Jan 21 22:15:23 charon: 14[IKE] <con2|50>peer supports MOBIKE Jan 21 22:15:23 charon: 14[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding Jan 21 22:15:23 charon: 14[IKE] <con2|50>received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding Jan 21 22:15:23 charon: 14[IKE] initiating EAP_IDENTITY method (id 0x00) Jan 21 22:15:23 charon: 14[IKE] <con2|50>initiating EAP_IDENTITY method (id 0x00) Jan 21 22:15:23 charon: 14[CFG] selected peer config 'con2' Jan 21 22:15:23 charon: 14[CFG] looking for peer configs matching yyy.yyy.yyy.yyy[%any]...77.16.3.108[C=NO, ST=Area, L=City, O=Org, E=user@domain.com, CN=eskild] Jan 21 22:15:23 charon: 14[IKE] received cert request for "C=NO, ST=Area, L=City, O=Org, E=user@domain.com, CN=internal-ca" Jan 21 22:15:23 charon: 14[IKE] <50> received cert request for "C=NO, ST=Area, L=City, O=Org, E=user@domain.com, CN=internal-ca" Jan 21 22:15:23 charon: 14[ENC] parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) CERTREQ CPRQ(ADDR ADDR6 DNS DNS6) N(ESP_TFC_PAD_N) SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) N(EAP_ONLY) ] Jan 21 22:15:23 charon: 14[NET] received packet: from 77.16.3.108[55904] to yyy.yyy.yyy.yyy[4500] (656 bytes) Jan 21 22:15:23 charon: 14[NET] sending packet: from yyy.yyy.yyy.yyy[500] to 77.16.3.108[48693] (385 bytes) Jan 21 22:15:23 charon: 14[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(MULT_AUTH) ] Jan 21 22:15:23 charon: 14[IKE] sending cert request for "C=NO, ST=Area, L=City, O=Org, E=user@domain.com, CN=internal-ca" Jan 21 22:15:23 charon: 14[IKE] <50> sending cert request for "C=NO, ST=Area, L=City, O=Org, E=user@domain.com, CN=internal-ca" Jan 21 22:15:23 charon: 14[IKE] sending cert request for "C=NO, ST=Area, L=City, O=Org, E=user@domain.com, CN=GuestCa" Jan 21 22:15:23 charon: 14[IKE] <50> sending cert request for "C=NO, ST=Area, L=City, O=Org, E=user@domain.com, CN=GuestCa" Jan 21 22:15:23 charon: 14[IKE] sending cert request for "C=NO, ST=Area, L=City, O=Org, E=user@domain.com, CN=internal-bkp-ca" Jan 21 22:15:23 charon: 14[IKE] <50> sending cert request for "C=NO, ST=Area, L=City, O=Org, E=user@domain.com, CN=internal-bkp-ca" Jan 21 22:15:23 charon: 14[IKE] remote host is behind NAT Jan 21 22:15:23 charon: 14[IKE] <50> remote host is behind NAT Jan 21 22:15:23 charon: 14[IKE] 77.16.3.108 is initiating an IKE_SA Jan 21 22:15:23 charon: 14[IKE] <50> 77.16.3.108 is initiating an IKE_SA Jan 21 22:15:23 charon: 14[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ] Jan 21 22:15:23 charon: 14[NET] received packet: from 77.16.3.108[48693] to yyy.yyy.yyy.yyy[500] (868 bytes) Jan 21 22:15:23 charon: 09[NET] sending packet: from yyy.yyy.yyy.yyy[500] to 77.16.3.108[48693] (38 bytes) Jan 21 22:15:23 charon: 09[ENC] generating IKE_SA_INIT response 0 [ N(INVAL_KE) ] Jan 21 22:15:23 charon: 09[IKE] DH group MODP_2048 inacceptable, requesting MODP_1024 Jan 21 22:15:23 charon: 09[IKE] <49> DH group MODP_2048 inacceptable, requesting MODP_1024 Jan 21 22:15:23 charon: 09[IKE] remote host is behind NAT Jan 21 22:15:23 charon: 09[IKE] <49> remote host is behind NAT Jan 21 22:15:23 charon: 09[IKE] 77.16.3.108 is initiating an IKE_SA Jan 21 22:15:23 charon: 09[IKE] <49> 77.16.3.108 is initiating an IKE_SA Jan 21 22:15:23 charon: 09[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ] Jan 21 22:15:23 charon: 09[NET] received packet: from 77.16.3.108[48693] to yyy.yyy.yyy.yyy[500] (996 bytes)</con2|50></con2|50></con2|50></con2|50>
-
I have tried to configure EAP-TLS according to the guide, but using DNS instead of IP for SAN in server-cert.
But when using a server-cert generated with SAN DNS=site.domain.com, I see the following in the pfsense log:
charon: 14[IKE] no private key found for 'C=NO, ST=Area, L=City, O=Org, E=user@domain.com, CN=site.domain.com'I have tried without the SAN conf in the server-cert, but then the client complains over the identity.
I believe I saw that when the identifier entered for the IPsec Phase 1 did not match the CN of the certificate.
-
Yes, seems that the IPSec phase 1 identifier must match both the server-cert CN and a SAN DNS entry.
The problem in my case is when creating both entries in the server-cert, ipsec is unable to read the private key.
-
Yes, seems that the IPSec phase 1 identifier must match both the server-cert CN and a SAN DNS entry.
The problem in my case is when creating both entries in the server-cert, ipsec is unable to read the private key.
When I made mine, I used the hostname of the firewall for the CN and the IP address for a SAN. That was good enough.
-
ipsec is unable to read the private key.
with ipsec listcerts you should see a line like
pubkey: RSA 4096 bits**, has private key**If that's not the case, try the following commands
ipsec rereadall
ipsec restart (restart not reload!)What's the output of ipsec listcerts ?
-
ipsec is unable to read the private key.
with ipsec listcerts you should see a line like
pubkey: RSA 4096 bits**, has private key**If that's not the case, try the following commands
ipsec rereadall
ipsec restart (restart not reload!)What's the output of ipsec listcerts ?
I had the same issue with pfSense 2.2 after creating a CA and a certificate (annoyingly, StrongSwan apparently does not and will not support wildcard certs). IPSec log when I connect:
charon: 05[IKE] no private key found for 'C=US, ST=Illinois, L=Naperville, O=ITS Inc, E=support@example.com, CN=router1.example.net'
ipsec listcerts output:
List of X.509 End Entity Certificates:
subject: "C=US, ST=Illinois, L=Naperville, O=ITS Inc, E=support@example.com, CN=router1.example.net"
issuer: "C=US, ST=Illinois, L=Naperville, O=ITS Inc, E=support@example.com, CN=router1-ca"
serial: 02
validity: not before Mar 17 23:10:33 2015, ok
not after Mar 14 23:10:33 2025, ok
pubkey: RSA 2048 bits
keyid: xxxx
subjkey: xxxx
xxxx$ ipsec restart
Stopping strongSwan IPsec…
Starting strongSwan 5.2.1 IPsec [starter]…
no netkey IPsec stack detected
no KLIPS IPsec stack detected
no known IPsec stack detected, ignoring!After those commands, I get "pubkey: RSA 2048 bits, has private key". Unfortunately despite that, I still get error 13801 from Windows when using the common name or IP address.