Issue with CA Root Authority Certficates and IPSec VPN

Hi all,

Thanks in advance for any help :slight_smile: .

I have a gubernamental services provider who has its own Certification Authority, who is replacing the 1st of December the CA Root Certificate. Their CA infrastructure is not reachable from the internet, so to validate its certificates we need to install them locally.

We have an IPsec tunnel to connect to them, for which we have prepared an SSL certificate (Crt and key files), which have been signed by them with the new CA Certificate successfully.

But in their device, in the endpoint where we connect, they still have a certificate which is validated still with the old CA certificate.

So, in my case we need on our Vyos appliance, version 1.1.6, the New CA Certificate, The Key and the SSL certificate, which I do without issues in the IPsec tunnel configuration:

config

set vpn ipsec site-to-site peer [Peer IP] authentication x509 ca-cert-file /config/auht/[New_CA_FILE.cer]

set vpn ipsec site-to-site peer [Peer IP] authentication x509 cert-file /config/auth/[New_SSLCertificate_FILE.cer]

set vpn ipsec site-to-site peer [Peer IP] authentication x509 key file /config/auth/[New_Key_FILE.Key]

commit

save

But now comes the tricky part, as when we try to connect to their endpoint device, my Vyos appliance refuses their CA.

[DATE/Time] [MyVyosName] pluto[8275]: “peer-[Peer-IP]-tunnel-1” #29: starting keying attempt 30 of an unlimited number
[DATE/Time] [MyVyosName] pluto[8275]: “peer-[Peer-IP]-tunnel-1” #30: initiating Main Mode to replace #29
[DATE/Time] [MyVyosName] pluto[8275]: “peer-[Peer-IP]-tunnel-1” #30: ignoring Vendor ID payload [FRAGMENTATION c0000000]
[DATE/Time] [MyVyosName] pluto[8275]: “peer-[Peer-IP]-tunnel-1” #30: ignoring Vendor ID payload [Cisco-Unity]
[DATE/Time] [MyVyosName] pluto[8275]: “peer-[Peer-IP]-tunnel-1” #30: received Vendor ID payload [XAUTH]
[DATE/Time] [MyVyosName] pluto[8275]: “peer-[Peer-IP]-tunnel-1” #30: ignoring Vendor ID payload [3a9da9f5f4ea646ce687ec271145adb7]
[DATE/Time] [MyVyosName] pluto[8275]: “peer-[Peer-IP]-tunnel-1” #30: ignoring Vendor ID payload [Cisco VPN 3000 Series]
[DATE/Time] [MyVyosName] pluto[8275]: “peer-[Peer-IP]-tunnel-1” #30: we have a cert and are sending it upon request
[DATE/Time] [MyVyosName] pluto[8275]: “peer-[Peer-IP]-tunnel-1” #30: next payload type of ISAKMP Hash Payload has an unknown value: 69
[DATE/Time] [MyVyosName] pluto[8275]: “peer-[Peer-IP]-tunnel-1” #30: malformed payload in packet
[DATE/Time] [MyVyosName] pluto[8275]: “peer-[Peer-IP]-tunnel-1” #30: Peer ID is ID_DER_ASN1_DN: ‘[Peer-ID]’
[DATE/Time] [MyVyosName] pluto[8275]: “peer-[Peer-IP]-tunnel-1” #30: crl not found
[DATE/Time] [MyVyosName] pluto[8275]: “peer-[Peer-IP]-tunnel-1” #30: certificate status unknown
[DATE/Time] [MyVyosName] pluto[8275]: “peer-[Peer-IP]-tunnel-1” #30: we don’t accept the peer’s CA
[DATE/Time] [MyVyosName] pluto[8275]: “peer-[Peer-IP]-tunnel-1” #30: sending encrypted notification INVALID_ID_INFORMATION to [Peer-IP]:500

I was using the old CA Certificate before, and is phisically located within /config/auth/

Of course I know I’m missing something… I have tried to install in the Linux CA Cert Store as per How do you add a certificate authority (CA) to Ubuntu? - Super User ,

renaming the cer files as crt to avoid issues, and have ensured both certs are located at /etc/ipsec.d/cacerts , I can see in the auth.log:

[DATE/Time] [MyVyosName] pluto[8275]: loaded ca certificate from ‘/etc/ipsec.d/cacerts/[Old_CA_CertFile.cer]’
[DATE/Time] [MyVyosName] pluto[8275]: loaded ca certificate from ‘/etc/ipsec.d/cacerts/[Old_CA_CertFile.crt]’
[DATE/Time] [MyVyosName] pluto[8275]: loaded ca certificate from ‘/etc/ipsec.d/cacerts/[New_CA_CertFile.cer]’
[DATE/Time] [MyVyosName] pluto[8275]: loaded ca certificate from ‘/etc/ipsec.d/cacerts/[New_CA_CertFile.crt]’

Please, give me a hand on this, what may I be missing? How can I ensure the certs are loaded fine and should work to autheticate their endpoint?

Many thanks

Regards, P.

Have you checked if the CA cert is valid from the current date? If its start date is in the future (some time in December, for instance), it may be normal.

StrongSWAN’s error look a bit too generic, so it’s hard to tell. I don’t remember if there was a way to make it more verbose, perhaps there is.

Is the other side changing certificates on IPSEC tunnel simultaneously ?