Hi, all! I'm new here, so I apologize if I incorrectly categorized this post. I'm new to Juniper and Junos, but am loving the features I am finding. I have a fair background in networking, training mostly on Cisco devices for work and building my own routers with CRUX Linux and FreeBSD for personal use.
I typically build IKEv2 IPSec VPNs using asymmetric PSKs, but I am having some difficulty finding this on our Juniper SRX320 devices (running Junos 18.2R3). I tried searching the forums, but didn't see any guidance on how to do this. From what I can gather, the `pre-shared-key` directive can only be set once per `security ike policy`, which sounds like asymmetric PSKs are not supported. Is this true? Or am I just digging in the wrong place? Thank you!
P.S. I have built working IKEv2 IPSec VPNs with the Juniper SRX320, but the same PSK is used on both ends.
First of all, welcome to the wonderful world of JUNOS. I am glad to hear that you are loving Juniper & JunOS.
Coming to your question, in Juniper devices, PSK has to match on both ends. If you want different peers to have different PSK , all you have to do is create as many policies (with different PSKs) and gateways.
Note that after the configuration has been committed, you can only see the ecrypted & hashed value of PSK in the configuration file.
I may suggest you to consider "Certificate Based VPN" as an option too as it gives more security than PSK . This VPN requires a certificate exchange with the peer whose certificate is also signed by a trusted CA. Since you use Linux/FreeBSD, you can generate the certificates locally and sign it from your linux based devices.
Thank you for the information. I have been considering moving to a certificate-based authentication scheme, but just haven't done so yet. Maybe I need to throw some priority behind that project.
As to the main topic, the IKEv2 protocol allows asymmetric PSKs _on the same connection_. For example, Peer 1 connects to Peer 2, but each contains two keys, a "sender" key (Key S) and a "receiver" key (Key R), if you will. Peer 1 sends Key S when it initiates the IKE connection to Peer 2, which uses Key R to match the connection; Peer 1's Key S exactly matches Peer 2's Key R. The reverse is also true, such that when Peer 2 sends its Key S to initiate the VPN handshake, Peer 1 compares it with its Key R.
In all versions of IKE, the PSK of one peer _must_ match that of its peer, but IKEv2 introduced the concept of asymmetric PSKs (along with asymmetric authentication in general), which means that each gateway contains a pair of keys and uses one or the other depending on whether it initiated or responded to the handshake.
I have configured IKEv2 VPNs with asymmetric keys before... but in Cisco devices. Not to blaspheme (:P), but this is how I would accomplish the same with IOS (NOTE: not an actual config):
Thanks for the info re: categories; I will ensure I tag things better in the future. Also, not having asymmetric keys isn't a huge problem. It's more of 1) me trying to integrate with established procedures, and 2) morbid curiosity as to why this feature wouldn't be implemented in JunOS. Anyway, it sounds like I need to get moving with TLS certificates. Thanks muchly!
By default, crl (certificate revocation list ) is enabled on SRX. Local certificates are validated against certificate revocation list (CRL) even when CRL check is disabled. This can be stopped by disabling the CRL check through the Public Key Infrastructure (PKI) configuration. When CRL check is disabled, PKI will not validate local certificate against CRL.