Juniper SRX: Site-to-Site IPSec VPN using SSL certificates

Last time, we set up a Site-to-Site IPSec VPN using a pre-shared-key. Today we will talk about the same IPSec VPN, only using SSL certificates.

I draw attention to the fact that both SRX'a must have a static external IP address.

The network layout will be the same as last time:

')
We will create certificates using OpenSSL, because it's more interesting - CA for Windows Server 2012 R2 when installing “Next, Next, Next” signs CSR requests without problems, I had to tinker a bit with OpenSSL.

All interested in asking under the cat.


I will produce all of the following actions on Oracle Enterprise Linux 6.5 x64 (default install) and JunOS 12.1X46-D20.5:

[root@localhost ~]# cat /etc/oracle-release Oracle Linux Server release 6.5 [root@localhost ~]# uname -mrs Linux 3.8.13-35.el6uek.x86_64 x86_64 [root@localhost ~]# openssl version OpenSSL 1.0.1e-fips 11 Feb 2013 

 cartman@gw-jvsrx-1# run show version Hostname: gw-jvsrx-1 Model: firefly-perimeter JUNOS Software Release [12.1X46-D20.5] 

The whole process is divided into the following parts:

• Create a private key and certificate request on a Juniper SRX device
• Prepare Root CA
• Sign CSR requests with a Root CA certificate
• Install a chain of certificates for Juniper SRX devices
• Configure IPSec VPN
• Check IPSec VPN performance

Create private key and CSR

Everything is simple - on each device you need to execute the following commands (you need to pay attention to the certificate-id, domain-name, ip-address and CN entry, since they will be different for each device). Further (in the final config of the tunnel) I will use the domain-name , as local and remote identity, so this parameter must be present in the CSR request. It is recommended to use the device FQDN.

 run request security pki generate-key-pair certificate-id gw-jvsrx-1 size 2048 type rsa run request security pki generate-certificate-request certificate-id gw-jvsrx-1 digest sha-256 domain-name gw-jvsrx-1.home.local ip-address 192.168.136.137 subject "DC=HOME.local,CN=gw-jvsrx-1.home.local,OU=IT,O=Home,L=Moscow,C=RU" 

As a result of the last command, a CSR request will be displayed in the console and its MD5 and SHA1 fingerprints:

Generated certificate request
----- BEGIN CERTIFICATE REQUEST -----
MIIC9DCCAdwCAQAwdjEaMBgGCgmSJomT8ixkARkWCkhPTUUubG9jYWwxHjAcBgNV
BAMTFWd3LWp2c3J4LTEuaG9tZS5sb2NhbDELMAkGA1UECxMCSVQxDTALBgNVBAoT
BEhvbWUxDzANBgNVBAcTBk1vc2NvdzELMAkGA1UEBhMCUlUwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDNz / 0WXjOYu0rMy9sv865BjH0QbYQSjyqehpfv
U0cIzRcRvhASrLVunHUQbnQCjZtjCEPQj3cpumXaxM5KufpmNelo + 3NXnIo70yn7
oxD / 9SOd3UUV6wPrSVGnu8j1PlL08YAaSTIxtqchhQ + 0JK8DJVPHRCH2sXSwPy9B
RbmfAi4p7cfHHo28c7 / wECWPpK4GvEKZ7SzqLtAbZsPqB6ulk8Qy41Qk3Agi4qrf
u3YxfynrxZQH2ZhsxCIdUollzKMe8BmlViL9mbv31 + 9UKogXdgsG1rRQWjJflghQ
oGZ6NIDqwDV8g2Fc5SCQo0mSdmXHz44zYRkfzgQLUCQuqm0dAgMBAAGgOTA3Bgkq
hkiG9w0BCQ4xKjAoMCYGA1UdEQQfMB2CFWd3LWp2c3J4LTEuaG9tZS5sb2NhbIcE
wKiIiTANBgkqhkiG9w0BAQsFAAOCAQEAw6nvznXy60xzd69zKd4mWRdXBF + sw5Wo
i5x9 / qhLG4OtBDi2byBMLirytnVyFv2QOGCSjX6 / O0uI7lPec2Qvt / hB40QMifOk
CIcF8nErseEwWyFJIHN3LVN0GrNb + wleZP8DiAVIHmDxefpaBMlB207fOu02jrkp
AdFdb0UAGmvqLBi9dYLWFq9MIHpTKBygIwWvn1gFoToZHJhWSDuHZTeYpVGYMBWN
MGTUNmo7h3Hp1IOghYVK9VsanK9mikWHebZN1aKUi6bDoRAi + UXnd2j1qBEPwc5q
LWX0ytm + ykMmkEKcT5S + EeIP + wgw74mQ9k6 + P2f53fecKPK13Q3ASg ==
----- END CERTIFICATE REQUEST -----
Fingerprint:
77: 5a: 8c: 51: c1: 29: 3b: 73: 81: 0d: 52: a3: 7f: 56: 06: 21: 17: 42: 8f: 20 (sha1)
d6: 41: a6: b8: af: f9: e5: e0: 2f: 6c: 0f: fa: 3b: 23: 3d: 76 (md5)

Copy the bold fragment to the clipboard and save it as a file on the server, where we will sign this request:

 [root@localhost ~]# cat gw-jvsrx-1.csr -----BEGIN CERTIFICATE REQUEST----- MIIC9DCCAdwCAQAwdjEaMBgGCgmSJomT8ixkARkWCkhPTUUubG9jYWwxHjAcBgNV BAMTFWd3LWp2c3J4LTEuaG9tZS5sb2NhbDELMAkGA1UECxMCSVQxDTALBgNVBAoT BEhvbWUxDzANBgNVBAcTBk1vc2NvdzELMAkGA1UEBhMCUlUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDNz/0WXjOYu0rMy9sv865BjH0QbYQSjyqehpfv U0cIzRcRvhASrLVunHUQbnQCjZtjCEPQj3cpumXaxM5KufpmNelo+3NXnIo70yn7 oxD/9SOd3UUV6wPrSVGnu8j1PlL08YAaSTIxtqchhQ+0JK8DJVPHRCH2sXSwPy9B RbmfAi4p7cfHHo28c7/wECWPpK4GvEKZ7SzqLtAbZsPqB6ulk8Qy41Qk3Agi4qrf u3YxfynrxZQH2ZhsxCIdUollzKMe8BmlViL9mbv31+9UKogXdgsG1rRQWjJflghQ oGZ6NIDqwDV8g2Fc5SCQo0mSdmXHz44zYRkfzgQLUCQuqm0dAgMBAAGgOTA3Bgkq hkiG9w0BCQ4xKjAoMCYGA1UdEQQfMB2CFWd3LWp2c3J4LTEuaG9tZS5sb2NhbIcE wKiIiTANBgkqhkiG9w0BAQsFAAOCAQEAw6nvznXy60xzd69zKd4mWRdXBF+sw5Wo i5x9/qhLG4OtBDi2byBMLirytnVyFv2QOGCSjX6/O0uI7lPec2Qvt/hB40QMifOk CIcF8nErseEwWyFJIHN3LVN0GrNb+wleZP8DiAVIHmDxefpaBMlB207fOu02jrkp AdFdb0UAGmvqLBi9dYLWFq9MIHpTKBygIwWvn1gFoToZHJhWSDuHZTeYpVGYMBWN MGTUNmo7h3Hp1IOghYVK9VsanK9mikWHebZN1aKUi6bDoRAi+UXnd2j1qBEPwc5q LWX0ytm+ykMmkEKcT5S+EeIP+wgw74mQ9k6+P2f53fecKPK13Q3ASg== -----END CERTIFICATE REQUEST----- [root@localhost ~]# cat gw-jvsrx-2.csr -----BEGIN CERTIFICATE REQUEST----- MIIC9DCCAdwCAQAwdjEaMBgGCgmSJomT8ixkARkWCkhPTUUubG9jYWwxHjAcBgNV BAMTFWd3LWp2c3J4LTIuaG9tZS5sb2NhbDELMAkGA1UECxMCSVQxDTALBgNVBAoT BEhvbWUxDzANBgNVBAcTBk1vc2NvdzELMAkGA1UEBhMCUlUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDGSfJvRWRGz8gRQAiTQaoVfgrLGv4l00xDBqat egRMJ4811d80auFz8JvBy6XLCliaDUdTthGOu+8S8FACzO7sQHPLa+r1rnURU7A4 j9UxTLCDJ/5KR4FZHfIR+B/2ni3P40qWuat/KaYjJNW0Rb6cAZ9BRgbuTQU09i39 kPsZWLT3mazx1HP5hmAwRDHtx+AmZNV/gf/ho7JTNfbmRbh56CmJqGuLXDvKrGtN Us5K0BdFH6/SlRO+k8sD/mMJUOl909VT11WTj1li9C2EHzgVmrC3L78A9WWjLHDF FHpiYfP+8krMotek4n4BChMFnSBsGD6uBKtnNjvPRnvOI60HAgMBAAGgOTA3Bgkq hkiG9w0BCQ4xKjAoMCYGA1UdEQQfMB2CFWd3LWp2c3J4LTIuaG9tZS5sb2NhbIcE wKiIijANBgkqhkiG9w0BAQsFAAOCAQEAOc2zAMGMbo6SwvyBz+yJ8Ep1WL/rLuN8 ZKhkytwdVJJT42NyAZMyg2NLTyv735fgfGo7lMTW/18foVNhqG2gQwM/OETgqhTu K2XblHOCD9A0WRD6bUfL1pST7brJNQjmpnXRo+WRqHnZuVxNgj/gdbkCceYrVG70 BpA12SdJoWVMCbe/qVQ+N7OSECmL8skUCHPTQiKxW/lKQKvlbSReq7NnccdfcheK wZGa+uqb8EzZV3e0PwR75+VKIyw2Rf1IDU/sQrShqCGKrIJcfU16XL9hvTdINXFW RGtfuBhERHw1HcWiQL+x56Htyc4qDdt8ffz+aV38jVtCcwN+FoqWxA== -----END CERTIFICATE REQUEST----- 

Create a root certificate

Now let's prepare the file structure and configuration of our CA Root:

 [root@localhost ~]# mkdir -p ca_root/{certs,conf,csr,newcerts,private} [root@localhost ~]# cd ca_root [root@localhost ca_root]# echo 1000 > serial [root@localhost ca_root]# touch index.txt [root@localhost ca_root]# cp /etc/pki/tls/openssl.cnf conf/ 

Do not forget to transfer our CSR to the "correct" directory:

 [root@localhost ~]# mv *.csr ca_root/csr 

I will create certificates without the ST field in the Subject (this can be done with this field, but there can be a lot of configurations and I decided to cover this moment), so I need to fix this parameter in the openssl.cnf config, which we will use:

 [root@localhost ca_root]# vi conf/openssl.cnf ..... [ CA_default ] dir = /etc/pki/CA <==========================  /etc/pki/CA  . ..... [ policy_match ] countryName = match stateOrProvinceName = match <==========================  match  optional organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optional ..... 

JunOS creates a query using the PRINTABLESTRING encoding (string mask), while OpenSSL (by default) uses UTF8ONLY. You can check it like this:

 [root@localhost ca_root]# openssl asn1parse -in csr/gw-jvsrx-1.csr | grep PRINTABLESTRING --color 50:d=5 hl=2 l= 21 prim: PRINTABLESTRING :gw-jvsrx-1.home.local 82:d=5 hl=2 l= 2 prim: PRINTABLESTRING :IT 95:d=5 hl=2 l= 4 prim: PRINTABLESTRING :Home 110:d=5 hl=2 l= 6 prim: PRINTABLESTRING :Moscow 127:d=5 hl=2 l= 2 prim: PRINTABLESTRING :RU [root@localhost ca_root]# openssl asn1parse -in csr/gw-jvsrx-2.csr | grep PRINTABLESTRING --color 50:d=5 hl=2 l= 21 prim: PRINTABLESTRING :gw-jvsrx-2.home.local 82:d=5 hl=2 l= 2 prim: PRINTABLESTRING :IT 95:d=5 hl=2 l= 4 prim: PRINTABLESTRING :Home 110:d=5 hl=2 l= 6 prim: PRINTABLESTRING :Moscow 127:d=5 hl=2 l= 2 prim: PRINTABLESTRING :RU 

If the encodings do not match, we will not be able to sign certificates for devices, since there will be an error about the mismatch of values ​​(although the error text will indicate something like HOME <> HOME and guess which direction to dig might be problematic). Let's make OpenSSL use PRINTABLESTRING:

 [root@localhost ca_root]# vi conf/openssl.cnf ..... string_mask = utf8only <==========================  utf8only  default ..... 

Now we will generate the root certificate of our Root CA (we will do for 10 years):

 [root@localhost ca_root]# openssl req -new -x509 -days 3650 -keyout private/rootCA.key -out certs/rootCA.crt -config conf/openssl.cnf Generating a 2048 bit RSA private key .........+++ .........................................................................................+++ writing new private key to 'private/rootCA.key' Enter PEM pass phrase: Verifying - Enter PEM pass phrase: ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [XX]:RU State or Province Name (full name) []: Locality Name (eg, city) [Default City]:Moscow Organization Name (eg, company) [Default Company Ltd]:Home Organizational Unit Name (eg, section) []:IT Common Name (eg, your name or your server's hostname) []:Internal Root CA Email Address []: 

Just in case, let me remind you that private / rootCA.key must be guarded like the apple of an eye, because This is the private key of our root certificate. It is also recommended that when creating the root certificate, enter a very complex password for the Enter PEM pass phrase prompt.

Verify that the encoding is correct:

 [root@localhost ca_root]# openssl asn1parse -in certs/rootCA.crt | grep PRINTABLESTRING --color 50:d=5 hl=2 l= 2 prim: PRINTABLESTRING :RU 63:d=5 hl=2 l= 6 prim: PRINTABLESTRING :Moscow 80:d=5 hl=2 l= 4 prim: PRINTABLESTRING :Home 95:d=5 hl=2 l= 2 prim: PRINTABLESTRING :IT 108:d=5 hl=2 l= 16 prim: PRINTABLESTRING :Internal Root CA 169:d=5 hl=2 l= 2 prim: PRINTABLESTRING :RU 182:d=5 hl=2 l= 6 prim: PRINTABLESTRING :Moscow 199:d=5 hl=2 l= 4 prim: PRINTABLESTRING :Home 214:d=5 hl=2 l= 2 prim: PRINTABLESTRING :IT 227:d=5 hl=2 l= 16 prim: PRINTABLESTRING :Internal Root CA 

Sign CSR Requests

Let's start generating certificates for devices. First you need to create 2 files in which we write down the attributes of the subjectAltName. For us, the most critical will be the DNS parameter (the same local and remote identity), IP can be omitted, but we will do this:

 [root@localhost ca_root]# cat conf/gw-jvsrx-1.cnf extensions = extend [extend] subjectAltName = "DNS:gw-jvsrx-1.home.local","IP:192.168.136.137" [root@localhost ca_root]# cat conf/gw-jvsrx-2.cnf extensions = extend [extend] subjectAltName = "DNS:gw-jvsrx-2.home.local","IP:192.168.136.138" 

Now we will sign our CSR root certificate requests:

 [root@localhost ca_root]# openssl ca -verbose -in csr/gw-jvsrx-1.csr -out certs/gw-jvsrx-1.crt -keyfile private/rootCA.key -cert certs/rootCA.crt -extfile conf/gw-jvsrx-1.cnf -config conf/openssl.cnf [root@localhost ca_root]# openssl ca -verbose -in csr/gw-jvsrx-2.csr -out certs/gw-jvsrx-2.crt -keyfile private/rootCA.key -cert certs/rootCA.crt -extfile conf/gw-jvsrx-2.cnf -config conf/openssl.cnf 

Verify that subjectAltName is in the final certificates:

 [root@localhost ca_root]# openssl x509 -in certs/gw-jvsrx-1.crt -text -noout | grep DNS DNS:gw-jvsrx-1.home.local, IP Address:192.168.136.137 [root@localhost ca_root]# openssl x509 -in certs/gw-jvsrx-2.crt -text -noout | grep DNS DNS:gw-jvsrx-2.home.local, IP Address:192.168.136.138 

(For fun) Let's look at the issued certificates:

 [root@localhost ca_root]# cat index.txt V 150721115632Z 1000 unknown /C=RU/O=Home/OU=IT/CN=gw-jvsrx-1.home.local V 150721115943Z 1001 unknown /C=RU/O=Home/OU=IT/CN=gw-jvsrx-2.home.local 

Install a chain of certificates for devices

First you need to copy the device certificate files and the root certificate to our Junipers (can be done using scp or WinSCP).

 [root@localhost ca_root]# scp certs/gw-jvsrx-1.crt cartman@192.168.136.137:/cf/var/home/cartman/gw-jvsrx-1.crt [root@localhost ca_root]# scp certs/rootCA.crt cartman@192.168.136.137:/cf/var/home/cartman/rootCA.crt [root@localhost ca_root]# scp certs/gw-jvsrx-2.crt cartman@192.168.136.138:/cf/var/home/cartman/gw-jvsrx-2.crt [root@localhost ca_root]# scp certs/rootCA.crt cartman@192.168.136.138:/cf/var/home/cartman/rootCA.crt 

Now let's prepare the PKI configuration (this part of the config is the same for both devices):

 set security pki ca-profile openssl_root_ca ca-identity openssl_root_ca set security pki ca-profile openssl_root_ca revocation-check disable 

Install the root certificate and device certificate:

 run request security pki ca-certificate load ca-profile openssl_root_ca filename rootCA.crt run request security pki local-certificate load certificate-id gw-jvsrx-1 filename gw-jvsrx-1.crt 

The same should be done on the 2nd device (just install the certificate for gw-jvsrx-2).

Configure IPSec VPN

There is nothing complicated here, most of the parameters I described in this article:

 set interfaces st0 unit 0 point-to-point set interfaces st0 unit 0 family inet address 172.16.0.1/30 set security ike respond-bad-spi 1 set security ike proposal ike-proposal-rsa authentication-method rsa-signatures set security ike proposal ike-proposal-rsa dh-group group14 set security ike proposal ike-proposal-rsa authentication-algorithm sha-256 set security ike proposal ike-proposal-rsa encryption-algorithm aes-128-cbc set security ike proposal ike-proposal-rsa lifetime-seconds 3600 set security ike policy ike-policy-rsa mode main set security ike policy ike-policy-rsa proposals ike-proposal-rsa set security ike policy ike-policy-rsa certificate local-certificate gw-jvsrx-1 set security ike policy ike-policy-rsa certificate peer-certificate-type x509-signature set security ike gateway gw-jvsrx-2 ike-policy ike-policy-rsa set security ike gateway gw-jvsrx-2 address 192.168.136.138 set security ike gateway gw-jvsrx-2 dead-peer-detection always-send set security ike gateway gw-jvsrx-2 dead-peer-detection interval 10 set security ike gateway gw-jvsrx-2 local-identity hostname gw-jvsrx-1.home.local set security ike gateway gw-jvsrx-2 remote-identity hostname gw-jvsrx-2.home.local set security ike gateway gw-jvsrx-2 external-interface ge-0/0/0.0 set security ike gateway gw-jvsrx-2 version v2-only set security ipsec proposal ipsec-proposal-rsa protocol esp set security ipsec proposal ipsec-proposal-rsa authentication-algorithm hmac-sha-256-128 set security ipsec proposal ipsec-proposal-rsa encryption-algorithm aes-128-cbc set security ipsec proposal ipsec-proposal-rsa lifetime-seconds 7200 set security ipsec policy ipsec-policy-rsa perfect-forward-secrecy keys group14 set security ipsec policy ipsec-policy-rsa proposals ipsec-proposal-rsa set security ipsec vpn gw-jvsrx-2 bind-interface st0.0 set security ipsec vpn gw-jvsrx-2 vpn-monitor source-interface ge-0/0/0.1 set security ipsec vpn gw-jvsrx-2 vpn-monitor destination-ip 172.16.0.2 set security ipsec vpn gw-jvsrx-2 ike gateway gw-jvsrx-2 set security ipsec vpn gw-jvsrx-2 ike ipsec-policy ipsec-policy-rsa set security ipsec vpn gw-jvsrx-2 establish-tunnels immediately 

To increase paranoia, we tunnel the st0.0 tunnel interface into a separate security-zone with the name vpn (although it is possible with the trust already created), but since educational post allow all traffic between trust and vpn:

 set security policies from-zone vpn to-zone trust policy vpn-to-trust match source-address any set security policies from-zone vpn to-zone trust policy vpn-to-trust match destination-address any set security policies from-zone vpn to-zone trust policy vpn-to-trust match application any set security policies from-zone vpn to-zone trust policy vpn-to-trust then permit set security policies from-zone trust to-zone vpn policy trust-to-vpn match source-address any set security policies from-zone trust to-zone vpn policy trust-to-vpn match destination-address any set security policies from-zone trust to-zone vpn policy trust-to-vpn match application any set security policies from-zone trust to-zone vpn policy trust-to-vpn then permit set security zones security-zone vpn interfaces st0.0 host-inbound-traffic system-services all set security zones security-zone vpn interfaces st0.0 host-inbound-traffic protocols all 

And of course OSPF:

 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface st0.0 interface-type p2p set protocols ospf area 0.0.0.0 interface st0.0 hello-interval 10 set protocols ospf area 0.0.0.0 interface st0.0 flood-reduction set protocols ospf area 0.0.0.0 interface st0.0 neighbor 172.16.0.2 

Check the state of our tunnel

Verify that the first IPSec phase is functioning, and also verify the authentication method field:

 cartman@gw-jvsrx-1# run show security ike security-associations detail IKE peer 192.168.136.138, Index 6745, Gateway Name: gw-jvsrx-2 Role: Initiator, State: UP Initiator cookie: ce70b7c0d1c523a2, Responder cookie: be63393746194b61 Exchange type: IKEv2, Authentication method: RSA-signatures Local: 192.168.136.137:500, Remote: 192.168.136.138:500 Lifetime: Expires in 900 seconds Peer ike-id: gw-jvsrx-2.home.local Xauth assigned IP: 0.0.0.0 Algorithms: Authentication : hmac-sha256-128 Encryption : aes128-cbc Pseudo random function: hmac-sha256 Diffie-Hellman group : DH-group-14 Traffic statistics: Input bytes : 42720 Output bytes : 42720 Input packets: 534 Output packets: 534 Flags: IKE SA is created IPSec security associations: 0 created, 0 deleted Phase 2 negotiations in progress: 0 Negotiation type: Quick mode, Role: Initiator, Message ID: 0 Local: 192.168.136.137:500, Remote: 192.168.136.138:500 Local identity: gw-jvsrx-1.home.local Remote identity: gw-jvsrx-2.home.local Flags: IKE SA is created 

Check the second phase:

 cartman@gw-jvsrx-1# run show security ipsec security-associations detail ID: 131073 Virtual-system: root, VPN Name: gw-jvsrx-2 Local Gateway: 192.168.136.137, Remote Gateway: 192.168.136.138 Local Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0) Remote Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0) Version: IKEv2 DF-bit: clear Bind-interface: st0.0 Port: 500, Nego#: 11, Fail#: 0, Def-Del#: 0 Flag: 0x600a29 Last Tunnel Down Reason: Lifetime expired Direction: inbound, SPI: da9f6c4f, AUX-SPI: 0 , VPN Monitoring: UP Hard lifetime: Expires in 3880 seconds Lifesize Remaining: Unlimited Soft lifetime: Expires in 3245 seconds Mode: Tunnel(10 10), Type: dynamic, State: installed Protocol: ESP, Authentication: hmac-sha256-128, Encryption: aes-cbc (128 bits) Anti-replay service: counter-based enabled, Replay window size: 64 Direction: outbound, SPI: cb42bcf5, AUX-SPI: 0 , VPN Monitoring: UP Hard lifetime: Expires in 3880 seconds Lifesize Remaining: Unlimited Soft lifetime: Expires in 3245 seconds Mode: Tunnel(10 10), Type: dynamic, State: installed Protocol: ESP, Authentication: hmac-sha256-128, Encryption: aes-cbc (128 bits) Anti-replay service: counter-based enabled, Replay window size: 64 

It would be nice to see how OSPF worked there:

 cartman@gw-jvsrx-1# run show ospf route Topology default Route Table: Prefix Path Route NH Metric NextHop Nexthop Type Type Type Interface Address/LSP 172.31.255.2 Intra Router IP 1 st0.0 172.16.0.0/30 Intra Network IP 1 st0.0 172.16.1.0/27 Intra Network IP 1 ge-0/0/1.0 172.16.2.0/27 Intra Network IP 2 st0.0 

... And check the availability of addresses "on the other side":

 cartman@gw-jvsrx-1# run ping inet 172.16.0.2 interface ge-0/0/1.0 count 5 PING 172.16.0.2 (172.16.0.2): 56 data bytes 64 bytes from 172.16.0.2: icmp_seq=0 ttl=64 time=15.802 ms 64 bytes from 172.16.0.2: icmp_seq=1 ttl=64 time=5.458 ms 64 bytes from 172.16.0.2: icmp_seq=2 ttl=64 time=10.438 ms 64 bytes from 172.16.0.2: icmp_seq=3 ttl=64 time=10.476 ms 64 bytes from 172.16.0.2: icmp_seq=4 ttl=64 time=5.445 ms --- 172.16.0.2 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 5.445/9.524/15.802/3.856 ms cartman@gw-jvsrx-1# run ping inet 172.16.2.1 interface ge-0/0/1.0 count 5 PING 172.16.2.1 (172.16.2.1): 56 data bytes 64 bytes from 172.16.2.1: icmp_seq=0 ttl=64 time=11.051 ms 64 bytes from 172.16.2.1: icmp_seq=1 ttl=64 time=5.441 ms 64 bytes from 172.16.2.1: icmp_seq=2 ttl=64 time=4.553 ms 64 bytes from 172.16.2.1: icmp_seq=3 ttl=64 time=5.447 ms 64 bytes from 172.16.2.1: icmp_seq=4 ttl=64 time=5.542 ms --- 172.16.2.1 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 4.553/6.407/11.051/2.350 ms 

The tunnel is up and functioning correctly. Hooray!

Just in case, I bring the complete configuration of each device: