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