IPsec site-site with LE cert problem

LarryFahnoe

I'm having problems getting a site to site IPsec tunnel configured using mutual certificate authentication with Let's Encrypt certs. Either I'm misunderstanding the pfSense documentation or perhaps there is a trick to generating the LE certs properly.

The scenario is a pair of pfSense+ instances with dynamic IP connections. DNS names are registered dynamically. ACME is working and LE certs are getting installed. I've verified that the hidden IPsec pf rules are being added and showing that traffic is being passed, however connection attempts fail with AUTH_FAILED.

Because I'm using dynamic addresses I'm using FQDN's for the local and remote identifiers

Each side's My Certificate contains a SAN, however I note that the name values have DNS: prefixes which I'm suspecting may be causing the authentication to fail.

I've replaced my TLD with mumble.com in the text below

Initiator:
Authentication Method: Mutual certificate
My identifier: FQDN gw-m.mumble.com
Peer identifier: FQDN gw-a.mumble.com
My Certificate: mpls-vpn.mumble.com

# openssl x509 -text -noout -in /var/etc/ipsec/x509/cert-1.crt | grep mumble.com
        Subject: CN = mpls-vpn.mumble.com
                DNS:gw-m.mumble.com, DNS:mpls-vpn.mumble.com

Responder:
Authentication Method: Mutual certificate
My identifier: FQDN gw-a.mumble.com
Peer identifier: FQDN gw-m.mumble.com
My Certificate: alex-vpn.mumble.com

# openssl x509 -text -noout -in /var/etc/ipsec/x509/cert-1.crt | grep mumble.com
        Subject: CN = alex-vpn.mumble.com
                DNS:alex-vpn.mumble.com, DNS:gw-a.mumble.com

Reading the pfSense troubleshooting documentation and reviewing strongswan.org config examples, I'm wondering it the issue is the DNS: prefix in the cert's SAN that is causing the problem?

This hunch could be validated if I could coerce strongswan into showing the data that it is comparing and resulting in the AUTH_FAILED, but I haven't been able to do that by simply jacking up the IKE logging levels.

Both sides have loaded each other's "My Certificate" certs

Seeing the "no trusted RSA public key found for" messages, I have also generated LE certs for each side's FQDN, but strongswan doesn't know about those certs & I don't see a means of adding them via the pfSense config GUI, so I think that's a dead end.

Mar 12 11:25:08 pfs-m charon[8077]: 14[CFG] <con1|138> selected peer config 'con1'
Mar 12 11:25:08 pfs-m charon[8077]: 14[CFG] <con1|138>   using certificate "CN=alex-vpn.mumble.com"
Mar 12 11:25:08 pfs-m charon[8077]: 14[CFG] <con1|138>   certificate "CN=alex-vpn.mumble.com" key: 2048 bit RSA
Mar 12 11:25:08 pfs-m charon[8077]: 14[CFG] <con1|138>   using trusted intermediate ca certificate "C=US, O=Let's Encrypt, CN=R3"
Mar 12 11:25:08 pfs-m charon[8077]: 14[CFG] <con1|138>   certificate "C=US, O=Let's Encrypt, CN=R3" key: 2048 bit RSA
Mar 12 11:25:08 pfs-m charon[8077]: 14[CFG] <con1|138> no issuer certificate found for "C=US, O=Let's Encrypt, CN=R3"
Mar 12 11:25:08 pfs-m charon[8077]: 14[CFG] <con1|138>   issuer is "C=US, O=Internet Security Research Group, CN=ISRG Root X1"
Mar 12 11:25:08 pfs-m charon[8077]: 14[IKE] <con1|138> no trusted RSA public key found for 'gw-a.mumble.com'
Mar 12 11:25:08 pfs-m charon[8077]: 14[IKE] <con1|138> received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Mar 12 11:25:08 pfs-m charon[8077]: 14[ENC] <con1|138> generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]

--Larry

LarryFahnoe

This was a self-inflicted wound. Somehow I had inadvertently deleted the ISRG Root X1 CA cert. Importing the cert solved the problem. Obviously I should have paid more attention to what the log message was telling me!

no issuer certificate found for "C=US, O=Let's Encrypt, CN=R3"
  issuer is "C=US, O=Internet Security Research Group, CN=ISRG Root X1"

--Larry