Certificate VPN troubleshooting

I am going to break my certificate VPN setup in this post and see what sort of log message we will get. If you are looking for how to set up a certificate based IPSEC VPN on SRX, you can check my other post.

I have already an established the tunnel between those two peers you can see in the topology.

Let’s check CO-A cluster side status first.

{primary:node0}
root@CO-A-1> show security ike sa | match UP    
3497228 UP     099ec6b5648bd43c  344020d094568811  Main           172.4.1.2       

{primary:node0}
root@CO-A-1> show security ike sa detail index 3497228 
node0:
--------------------------------------------------------------------------
IKE peer 172.4.1.2, Index 3497228, Gateway Name: brancha-2
  Role: Initiator, State: UP
  Initiator cookie: 099ec6b5648bd43c, Responder cookie: 344020d094568811
  Exchange type: Main, Authentication method: RSA-signatures   <<<<--------
....

root@CO-A-1> show security ipsec sa 
node0:
--------------------------------------------------------------------------
  Total active tunnels: 1
  ID    Algorithm       SPI      Life:sec/kb  Mon lsys Port  Gateway   
  131083 ESP:3des/sha1 a95fdfaa 2220/ unlim   -   root 500   172.4.1.2 

Now we have confirmed that Phase 1 and Phase 2 are UP.

If you can take a look at the IKE gateway config, we set remote IKE-ID as hostname. We don’t set our own IKE-ID hence our interface IP 192.168.9.2 on CO-A will be selected. You can already see this on the ike SA output above.

root@CO-A-1> show configuration security ike gateway brancha-2   
ike-policy brancha-2;
address 172.4.1.2;
remote-identity hostname brancha.example.com;
external-interface reth1.953;

BranchA gateway configuration is also as follows

gateway co-a {
    ike-policy pol-cert;
    address 192.168.9.2;
    local-identity hostname brancha.example.com;
    external-interface ge-0/0/0.950;
}

Before the tunnel comes up, I have enabled IKE traceoptions on BranchA side. First interesting log snippet is the following;

[Mar 23 22:09:54]ike_find_public_key: Find public key for 172.4.1.2:500, id = No Id -> 192.168.9.2:500, id = ipv4(any:0,[0..3]=192.168.9.2)
[Mar 23 22:09:54]ike_policy_reply_find_public_key: Start
[Mar 23 22:09:54]ike_state_restart_packet: Start, restart packet SA = { 099ec6b5 648bd43c - 344020d0 94568811}, nego = -1
[Mar 23 22:09:54]ike_st_i_sig: Start, sig[0..128] = 03c5b328 4324ab67 ...
[Mar 23 22:09:54]ike_find_public_key: Find public key for 172.4.1.2:500, id = No Id -> 192.168.9.2:500, id = ipv4(any:0,[0..3]=192.168.9.2)

On the first line “id = ipv4(any:0,[0..3]=192.168.9.2” this line seems to be revealing the IKE-ID which is 192.168.9.2 received from the remote side (CO-A) , now we will modify ike-id of CO-A in purpose to see what kind of error message we get.

{primary:node0}[edit]
root@CO-A-1# set security ike gateway brancha-2 local-identity hostname co-a.example.com 

Now let’s check the ike error log

[Mar 23 22:51:13]ike_find_public_key: Find public key for 172.4.1.2:500, id = No Id -> 192.168.9.2:500, id = fqdn(any:0,[0..15]=co-a.example.com)
[Mar 23 22:51:13]ikev2_fb_find_public_key_cb: Public key lookup failed, error 'Authentication failed'
[Mar 23 22:51:13]ike_policy_reply_find_public_key: Start
[Mar 23 22:51:13]172.4.1.2:500 (Responder)  192.168.9.2:500 { 95ec8728 cf2e470f - 71e8dd54 edb8f4b8 [-1] / 0x00000000 } IP; No public key found
[Mar 23 22:51:13]ike_state_restart_packet: Start, restart packet SA = { 95ec8728 cf2e470f - 71e8dd54 edb8f4b8}, nego = -1
[Mar 23 22:51:13]172.4.1.2:500 (Responder)  192.168.9.2:500 { 95ec8728 cf2e470f - 71e8dd54 edb8f4b8 [-1] / 0x00000000 } IP; Error = Authentication failed (24)
.....
[Mar 23 22:51:13]  IKEv1 Error : Authentication failed

As you can see on the 1st line, received IKE-ID is “id = fqdn(any:0,[0..15]=co-a.example.com)” i.e it is co-a.example.com which is what we set in the CO-A device config but this isn’t what is configured on branchA box. Now branchA side can’t match the public key received and returns the authentication failed error. IKE-ID can incorrectly exist in two locations I believe: one in the config the other one is the certificate itself as we embed our ike-id in the SubjectAlternative attribute i.e

{primary:node0}
root@CO-A-1> show security pki local-certificate detail 
node0:
--------------------------------------------------------------------------

Certificate identifier: srx-co-id
  Certificate version: 3
  Serial number: 00000017
  Issuer:
    Organization: CA Internet Ltd, Organizational unit: CA Org, Country: NL, State: CA State, Locality: Prague, Common name: ca.example.com
  Subject:
    Organizational unit: SRX Dept, Country: NL, Common name: Mr. Admin
  Subject string: 
    CN=Mr. Admin, OU=SRX Dept, C=NL
  Alternate subject: email empty, fqdn empty, 192.168.9.2     <<<<<<----   IKE-ID
  Validity:
    Not before: 03-18-2015 13:26 UTC
    Not after: 03-15-2025 13:26 UTC
  Public key algorithm: rsaEncryption(1024 bits)
    30:81:89:02:81:81:00:bb:f6:bb:a1:7d:31:0a:5a:72:5e:19:7d:85
    4d:8a:74:9f:8f:1b:4b:b2:a7:7f:83:f2:df:5e:04:b0:a2:cf:7e:30
    df:96:a6:50:88:f2:a5:c0:4c:9d:8e:ed:2d:71:ca:24:26:62:90:f8
    bb:42:3d:66:56:bf:5b:78:04:be:8c:7d:68:1b:d4:0e:ff:84:60:a3
    38:1b:12:8f:9e:27:d7:f1:d5:10:17:46:6c:f2:21:23:f8:8f:62:31
    85:0b:8b:46:bd:6d:8d:c8:b0:78:ba:08:81:e2:87:66:f0:05:e6:96
    fa:0f:88:65:6a:01:05:6d:d9:f8:1d:97:05:25:03:02:03:01:00:01
  Signature algorithm: sha1WithRSAEncryption
  Fingerprint:
    6b:a7:72:94:ed:f9:19:2f:bc:5f:b1:5c:1f:ec:0c:10:ca:38:a5:7f (sha1)
    25:4e:fc:ee:4e:69:2a:90:82:00:8c:55:40:bb:f1:6e (md5)
  Auto-re-enrollment:
    Status: Disabled
    Next trigger time: Timer not started

Do you see the IKE id in the certificate itself? There we can make another mistake as well.

Another mistake I do is that from time to time, I do mess up signing the certificate. Openssl has a verification option for this purpose by which you can verify if certificate you have is signed by the CA currently loaded on the box or not.

root@debian1:/etc/pki_srx/CA1# openssl verify -CAfile certs/ca.crt certs/brancha.crt
certs/brancha.crt: OK

Certificate validity period is also an important factor that we shouldn't miss.

  Validity:
    Not before: 03-18-2015 13:26 UTC
    Not after: 03-15-2025 13:26 UTC

Last but not least is the CRL. If the cert is already revoked, that can also cause problem for the tunnel to come up. To get more log you can also enable PKI traceoptions under [security pki] which will give you bunch of info about cert you load and CRL.

I know that this post isn't that nicely outlined as my mind is also a bit of a mess when it comes to certificate VPN. I just wanted to put couple of trouble points for cert VPN here.