Embed Size (px)
DESCRIPTION
vpn
Citation preview
Certificate VPN troubleshootingI 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.
1234567891011121314151617181920
{primary:node0}root@CO-A-1> show security ike sa | match UP3497228 UP 099ec6b5648bd43c 344020d094568811 Main 172.4.1.2
{primary:node0}root@CO-A-1> show security ike sa detail index 3497228node0:--------------------------------------------------------------------------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 sanode0:-------------------------------------------------------------------------- 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
{primary:node0}root@CO-A-1> show security i3497228 UP 099ec6b5648bd
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.
12345
root@CO-A-1> show configuration security ike gateway brancha-2ike-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
123456
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;
12345
[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
root@CO-A-1> show configuraike-policy brancha-2;address 172.4.1.2;remote-identity hostname branc
gatew ay co-a { ike-policy pol-cert; address 192.168.9.2; local-identity hostname branc
[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
[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.
12
{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
12345678
[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}[edit]root@CO-A-1# set security ike
[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_
123456789101112131415161718192021222324252627282930313233
{primary:node0}root@CO-A-1> show security pki local-certificate detailnode0:--------------------------------------------------------------------------
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.
{primary:node0}root@CO-A-1> show security pki local-certif icnode0:
12
root@debian1:/etc/pki_srx/CA1# openssl verify -CAfile certs/ca.crt certs/brancha.crtcerts/brancha.crt: OK
Certificate validity period is also an important factor that we shouldn’t miss.
123
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.
root@debian1:/etc/pki_srx/CA1certs/brancha.crt: OK
Validity: Not before: 03-18-2015 13:26 Not after: 03-15-2025 13:26 U
