SRX

Hi SRX Services Gateway community. I am a relative newcomer in JunOS and would like to implement an IKEv2 IPSEC VPN between a legacy (Junos 12.1) SRX-210H-POE gateway, behind a NAT device, at home, dynamic public IP address and a Mikrotik (RouterOS 6.45) Cloud Hosted Router installed in a virtual machine, with a public fixed IP address. 

I just spent some days studying the July 2019 edition of  IPsec VPN Feature Guide for Security Devices, and found it really detailed, but too much detail really. I am at this moment about to start  reviewing DAY ONE: IPSEC VPN COOKBOOK 2018 

I am planning to try to implement the VPN from the SRX210 gateway (initiator) to Mikrotik CHR (responder). What I found a bit confusing at first read is the requirement to specify the identify of the initiator to the responder. Any tips / general advice would be welcome. 

From my friends at Mikrotik support they wrote (on the possibilty that after the VPN is setup, GRE could be implemented):

This is somehow a tricky setup. The IPsec part is easy and possible, however it is not possible to establish GRE tunnel without knowing the remote address without some scripting. If JunOS supports mode config requesting as initiator, you can use this example:

https://wiki.mikrotik.com/wiki/Manual:IP/IPsec#Site_to_Site_GRE_tunnel_over_IPsec_.28IKEv2.29_using_DNS

The example is not yet updated to 6.45 version, but is working on 6.44.x versions, but the principle is the same. It is using IKEv2 also, but simply changing exchange-mode to main uses IKEv1.

If JunOS does not support mode config, you will have to use some RouterOS scripting to update remote address of the GRE interface.

I should say, the above exercise is just for learning, and not production. Explanation: My project is in the process of planning a buy of current and future generation of Juniper hardware, so at this point, before the project start, I am just experimenting having had Cisco, Nortel Networks/Bay Networks and Mikrotik deep experience. I also tried to spin up a vSRX platform (nice product) and finally got frustrated with the setup issues and opted to find Ebay items; $19 each, new-in-box ancient stock (a lot of them) SRX210H-POE for self-training, and guess what, the hardware really really works well, and the programming modes are beautiful for a 10 year old box (2010 vintage). But finally when I could install 12.1 instead of the stock 10.0, I had an issue, everything is fine, except J-Web is refusing connections - I can putty, I can serial into the box and get things done, but J-Web is kaput. Possibly due to:J-Web incorrect user password after Junos upgrade on SRX

Regards to all. 

Hi Shaque,

Can you elaborate more on this part: " What I found a bit confusing at first read is the requirement to specify the identify of the initiator to the responder."? Where are you reading that or to what part of the SRX configuration you are refering to?

I believe you might be referring to the following:

Find below a configuration example of a VPN between two SRXs where one of the SRXs has a dynamic IP address (like in your case).

See: https://www.fir3net.com/Firewalls/Juniper/srx-dyn.html

Example Topology in reference to the above article:

  Local_SRX-(Dyn IP)-----------INTERNET---------(Static IP)-Remote_SRX

 In this case, the Remote_SRX cant be configured with the address of the Local_SRX because this last one has a dynamic address. Because of the same, we configure the Remote_SRX in the following way:

root@srx100> show configuration security ike gateway IKE-PEER-DYNAMIC
ike-policy IKE-POLICY-VPNRICH;
dynamic hostname fir3net.com; 

With the above configuration we are telling the Remote_SRX that its peer has a dynamic address and that it will be idetifying itself as fir3net.com.

We need to make sure that the Local_SRX identifies itselfs as fir3net.com when connecting to the Remote_SRX and we do this with the following command:

root@srx100> show configuration security ike gateway IKE-PEER-STATIC
local-identity hostname fir3net.com;

These values we are hardcoding are known as IKE-IDs and are values that have to match if we want the VPN to be established. These values are used for the peers to "authenticate" between each other and each device will have a Local IKE-ID and a Remote IKE-ID. You could understand them in the following way from the perspective of each device:

Local IKE-ID: this how I will identify myself when communicating with the remote peer.

Remote IKE-ID: this is how I expect that my peer identifies himself when contacting me.

These values always have to match during the negotiation of the tunnel, however we dont normally configured/hardcode them because by default the devices will use the following values as the IKE-IDs:

Local IKE-ID: the IP address of the device's external interface

Remote IKE-ID: the IP address of the remote peer

In a normal situation note that these values will match by using these default values, see this example topology:

SRXA-(1.1.1.1)------INTERNET-----(2.2.2.2)-SRXB

• SRXA is configured with 1.1.1.1 on its external interface hence this value will be used as its Local IKE-ID. SRXA is also configured to establish a VPN communication against 2.2.2.2 hence this value will be used as the Remote IKE-ID.

• SRXB is configured with 2.2.2.2 on its external interface hence this value will be used as its Local IKE-ID. SRXB is also configured to establish a VPN communication against 1.1.1.1 hence this value will be used as the Remote IKE-ID.

During the negotaition, SRXA identifies itself with its local IKE-ID (1.1.1.1) and SRXB, because of its Remote IKE-ID, is expecting that its peer will be identifying itself as 1.1.1.1. At this point everything matches. The SRXB will then identify itself as 2.2.2.2 (its Local IKE-ID) and SRXA will be expecting, because of its Remote IKE-ID, that SRXB identifies itself as 2.2.2.2. Again everything matches and we are good to go.

The problem in your case is that the address of one of the peers will be dynamically changing hence we cannot rely on the default values for the IKE-IDs (IP addresses) and because of this we manually configure them to fir3net.com, like in the configuration example, to play with fixed values and make sure they will match.

I havent work with Mikrotik but based on the following link, we can hardcode the IKE-IDs as well with a command simillar to:

myid=fqdn: hostname

https://bittenbytes.nl/2018/08/28/ipsec-tunnel-between-sonicos-and-mikrotik/ (note that the 1st image of Sonicwall also shows the IKE-IDs)

The only thing you will need to confirm is what is the correct command to hardcode the Remote IKE-ID on Mikrotik, because on the SRX you already know that you have to use " set security ike gateway [gateway_name] local-identity hostname [hostname]"

I really hope this helps you

Also make sure you use "aggresive" mode because it is required when one of the peers has a dynamic IP address and that "NAT-T" is enable because there is a nAT device in between the VPN peers. NAT-T is enabled by default on the SRX and aggresive mode is configured unde [edit security ike policy Policy_Name] hierarchy.

Thanks @epaniagua, I appreciate your suggestions. I am curious if the 'hostname' parameter has to be a valid hostname (how is it verified)? is a FQDN applicable here, or is the domain name (e.g., your use of fre3net.com) applicable here - or does it matter at all what we set here? I think I have also seen current JunOS documentation that allows several other types:

local-identity (distinguished-name | hostname identity-hostname | inet identity-ipv4 | inet6 identity-ipv6 | key-id | user-at-hostname identity-user);

So, is there a specification of what is valid input to the 'parameter' -- could we just say "abcdefghijk"  or "somedomain.tld"? Of course I understand the inet, inet6 parameters or key-id, but was thrown off by not having a formal syntax/parameter spec and it not being in the PDF of Security VPN IPSEC. 

---

@epaniagua wrote:

Can you elaborate more on this part: " What I found a bit confusing at first read is the requirement to specify the identify of the initiator to the responder."? Where are you reading that or to what part of the SRX configuration you are refering to?

 

[...]

With the above configuration we are telling the Remote_SRX that its peer has a dynamic address and that it will be idetifying itself as fir3net.com.

 

We need to make sure that the Local_SRX identifies itselfs as fir3net.com when connecting to the Remote_SRX and we do this with the following command:

 

 

root@srx100> show configuration security ike gateway IKE-PEER-STATIC
local-identity hostname fir3net.com;

 

 

These values we are hardcoding are known as IKE-IDs and are values that have to match if we want the VPN to be established. These values are used for the peers to "authenticate" between each other and each device will have a Local IKE-ID and a Remote IKE-ID. You could understand them in the following way from the perspective of each device:

 

Local IKE-ID: this how I will identify myself when communicating with the remote peer.

Remote IKE-ID: this is how I expect that my peer identifies himself when contacting me.

 

These values always have to match during the negotiation of the tunnel, however we dont normally configured/hardcode them because by default the devices will use the following values as the IKE-IDs:

 

Local IKE-ID: the IP address of the device's external interface

Remote IKE-ID: the IP address of the remote peer

---

Shaque,

The hostname/fqdn doesnt has to be resolved. It is just a format used for this value that has to match between the peers during the negotiation. As you said you could use different value's formats like IP address (IPv4 pr IPv6), FQDN, user-at-FQDN or Distinguished Name.

local-identity (distinguished-name | hostname identity-hostname | inet identity-ipv4 | inet6 identity-ipv6 | key-id | user-at-hostname identity-user);

Hi Shaque,

I can see that no comment is marked a Solution as of now and I was wondering if you were able to fix the issue or if you still need our help.