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.
Lets check CO-A cluster side status first.
{primary:node0}
root@CO-A-1> show security i
3497228 UP 099ec6b5648bd

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

{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

20 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 dont
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 configura
ike-policy brancha-2;
address 172.4.1.2;
remote-identity hostname branc

1
2
3
4
5

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
gatew ay co-a {
ike-policy pol-cert;
address 192.168.9.2;
local-identity hostname branc

1
2
3
4
5
6

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_ke
No Id -> 192.168.9.2:500, id = ip
[Mar 23 22:09:54]ike_policy_rep

1 [Mar 23 22:09:54]ike_find_public_key: Find public key for 172.4.1.2:500, id = No Id -&gt;

2 192.168.9.2:500, id = ipv4(any:0,[0..3]=192.168.9.2)
3 [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
4
[Mar 23 22:09:54]ike_st_i_sig: Start, sig[0..128] = 03c5b328 4324ab67 ...
5
[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 COA in purpose to see what kind of error message we get.
{primary:node0}[edit]
root@CO-A-1# set security ike

1 {primary:node0}[edit]
2 root@CO-A-1# set security ike gateway brancha-2 local-identity hostname co-a.example.com
Now lets check the ike error log
[Mar
23 22:51:13]ike_find_public_ke
No Id -> 192.168.9.2:500, id = f
[Mar 23 22:51:13]ikev2_fb_find_

[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
1
'Authentication failed'
2
[Mar 23 22:51:13]ike_policy_reply_find_public_key: Start
3
[Mar 23 22:51:13]172.4.1.2:500 (Responder) 192.168.9.2:500 { 95ec8728 cf2e470f 4
71e8dd54 edb8f4b8 [-1] / 0x00000000 } IP; No public key found
5
[Mar 23 22:51:13]ike_state_restart_packet: Start, restart packet SA = { 95ec8728 cf2e470f 6
71e8dd54 edb8f4b8}, nego = -1
7
[Mar 23 22:51:13]172.4.1.2:500 (Responder) 192.168.9.2:500 { 95ec8728 cf2e470f 8
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 isnt what is
configured on branchA box. Now branchA side cant 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-certific
node0:

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

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

2 certs/brancha.crt: OK
Certificate validity period is also an important factor that we shouldnt miss.
Validity:
Not before: 03-18-2015 13:26
Not after: 03-15-2025 13:26 U

1
2
3

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 isnt 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.