Hello everyone
I want to make a router to router iKEV2 tunnel but one of the router got dynamic IP. I was wondering how I can manage to do this in this case, maybe using DDNS provided by MicroTik on routers?
I heard with some script it will be doable but I'm a bigginner so maybe you guys can help with this or got other solutions which I will appreciate if you tell me.

yes, I think you could activate DDNS
https://wiki.mikrotik.com/wiki/Manual:IP/Cloud
/ip cloud set ddns-enabled=yes
and then use the dns-name instead of static IP

Maybe something like this?

• viewtopic.php?f=23&t=169538
• viewtopic.php?f=23&t=175656

Maybe something like this?

• viewtopic.php?f=23&t=169538
• viewtopic.php?f=23&t=175656

Thanks man, The server got static IP but not the client is this a same situation as your first given link?

yes, I think you could activate DDNS
https://wiki.mikrotik.com/wiki/Manual:IP/Cloud
/ip cloud set ddns-enabled=yes
and then use the dns-name instead of static IP

Thank you, but how to set it up for IKEV2?

If you've got a static public IP at at least one peer, just make that one a responder only (passive=yes) and that's it. You only need to use dynamic DNS if none of the peers has a static public IP. And if none of them has a public IP, not even a dynamic one, it's yet another challenge which may or may not be resolved using dynamic DNS, depending on the behaviour of the NAT devices between each peer and the internet.

If you've got a static public IP at at least one peer, just make that one a responder only (passive=yes) and that's it. You only need to use dynamic DNS if none of the peers has a static public IP. And if none of them has a public IP, not even a dynamic one, it's yet another challenge which may or may not be resolved using dynamic DNS, depending on the behaviour of the NAT devices between each peer and the internet.

Yeah one of them got static ip (server one) but IDK how to set them up for IKEV2, So I would highly appreciate a guide or link to a guide for that.

Set them exactly as you would if both had a static public IP, using the site to site example from the manual, but set passive=yes address=0.0.0.0/0 in the peer properties at the one with static IP. And set exchange-mode to ike2 rather than main at both. That's all.

Set them exactly as you would if both had a static public IP, using the site to site example from the manual, but set passive=yes address=0.0.0.0/0 in the peer properties at the one with static IP. And set exchange-mode to ike2 rather than main at both. That's all.

Thanks man, I will try this one as well. Is using passive=yes address=0.0.0.0/0 in the peer properties is safe?
I tried this one at the link below but somehow didn't worked for me. (got Active on client but no phase 2)

• viewtopic.php?f=23&t=169538

The safer authentification method you use, the less you have to care about the address of the remote peer. With properly generated certificates (CSR generated at the device that will use the certificate to authentify itself to others, signing the CSR by a CA, and importing the signed certificate to the device, so that the private key to the certificate never leaves the device), it's cheaper to bribe a coworker than to break the IPsec security. With a pre-shared secret, if you use a long, randomly generated one, and do not deliver it to the remote device via an open channel, you are still quite safe. Linking the peer to a particular IP or subnet is actually the least safe way, as the IP of the peer can be easily spoofed by a "man in the middle" - anyone controling a router anywhere on the network path between your two peers.

The safer authentification method you use, the less you have to care about the address of the remote peer. With properly generated certificates (CSR generated at the device that will use the certificate to authentify itself to others, signing the CSR by a CA, and importing the signed certificate to the device, so that the private key to the certificate never leaves the device), it's cheaper to bribe a coworker than to break the IPsec security. With a pre-shared secret, if you use a long, randomly generated one, and do not deliver it to the remote device via an open channel, you are still quite safe. Linking the peer to a particular IP or subnet is actually the least safe way, as the IP of the peer can be easily spoofed by a "man in the middle" - anyone controling a router anywhere on the network path between your two peers.

Can you link me a guide or manual in beginners level cause I couldn't understand the manual which mikrotik provided.
Thanks in advance

This one was quite useful for me back in 2016 when I knew almost nothing about RouterOS. Just bear in mind that certificate-based authentication is an add-on to this or, better to say, just a small change to the IPsec configuration but an additional area to study when it comes to creating the certificates.

Also, the Mikrotik manuals mostly assume you know the protocol standard, and only tell you how to configure it on RouterOS in particular, so if you don't know the basics, many settings may be pythic to you. A bright example is the "send-initial-contact" parameter of the peer, which causes something totally different than common sense would suggest.

This one

@sindy @erkexzcx
Thanks man, But it didn't worked with this on you send the link and I tried This one but didn't worked as well. So I thought maybe I'm setting something wrong, This is the configurations for both routers and xy.xy.xy.xy is the static IP of the server.

You have combined multiple configuration methods that don't play well with each other. Namely:

• at the initiator ("client") side, you use mode-config and generate-policy different from no on the /ip ipsec identity row but at the same time you have a static policy linked to the peer, and there is no policy template in the group "My group" to which the identity refers.
• at the responder ("server") side, the situation is the same, except that there, the static policy referring to a responder peer should be marked as invalid because no particular address is configured for the peer it is linked to so the policy has to be generated in order to inherit the sa-dst-address from the actual address of the remote peer.

So I'd say set template=yes for the policy at both devices (which will make the peer and tunnel properties irrelevant) and you should be good - both peers will generate the policy from this template.

So I'd say set template=yes for the policy at both devices (which will make the peer and tunnel properties irrelevant) and you should be good - both peers will generate the policy from this template.

I've done this but no change. maybe Scr or Dst IPs are wrong or maybe it's because the client is connected to a router or server is belind the NAT

The group value default is wrong at both, unless you've changed also the policy template group on the identity row to default. According to the configurations you've posted, it should be My group.

In fact, the group parameter is useless for a non-template policy, so as you've converted a static policy into a template, Winbox may have ignored the value set previously and assigned the default to the drop-down.

NAT as such doesn't constitute a problem if there is sufficient port-forwarding (UDP port 4500) at all the routers between the internet and the responder (server).

The group value default is wrong at both, unless you've changed also the policy template group on the identity row to default. According to the configurations you've posted, it should be My group
NAT as such doesn't constitute a problem if there is sufficient port-forwarding (UDP port 4500) at all the routers between the internet and the responder (server).

On both side now I set it to my group but no change.
How can I check if (UDP port 4500) is open I both side? cause on my client I cannot connect with L2TP to server

How can I check if (UDP port 4500) is open I both side? cause on my client I cannot connect with L2TP to server

On the server, run /tool sniffer quick port=4500 while trying to connect from the client. If you can see something to come, the port forwading outside the Mikrotik works fine.

But with L2TP, you need both UDP port 500 and UDP port 4500 to be forwarded, as the IPsec connection is always initiated at 500 and only migrates to 4500 once presence of NAT is discovered. With IKEv2, it is mandatory that the responder accepts initial requests also at port 4500, so Mikrotik as an initiator does exactly that, whereas e.g. Windows start at 500 also for IKEv2.

Since I've noticed a configured L2TP with IPsec at the server side, I didn't dive deep into your firewall rules, assuming that whoever wants to set up any kind of VPN should understand how firewalls work first, but now as I look at your rules, there indeed is no rule in chain input of filter that would permit incoming connections to UDP ports 500 and 4500. So add, just before the last action=drop rule in chain input, the following two rules:
chain=input in-interface-list=WAN protocol=udp dst-port=500,4500 action=accept
chain=input in-interface-list=WAN protocol=udp dst-port=1701 ipsec-policy=in,ipsec action=accept

Your firewall rules at the initiator side are really leaky, but I assume there is a firewall on the outer router (the one between that Mikrotik and the internet), am I right?

On the server, run /tool sniffer quick port=4500 while trying to connect from the client. If you can see something to come, the port forwading outside the Mikrotik works fine.

Thanks man, but it didn't show anything. After and before adding the firewall rules the results are the same.

Since I've noticed a configured L2TP with IPsec at the server side, I didn't dive deep into your firewall rules, assuming that whoever wants to set up any kind of VPN should understand how firewalls work first, but now as I look at your rules, there indeed is no rule in chain input of filter that would permit incoming connections to UDP ports 500 and 4500. So add, just before the last action=drop rule in chain input, the following two rules:
chain=input in-interface-list=WAN protocol=udp dst-port=500,4500 action=accept
chain=input in-interface-list=WAN protocol=udp dst-port=1701 ipsec-policy=in,ipsec action=accept

After I added those firewall rules on both side (on the server side there was no WAN in the in-interface-list so I set it to all) there was no change for IPsec IKEV2 or even L2TP.
I tried to connect with client to server again with L2TP but got these logs:
on client: on server:

Since I've noticed a configured L2TP with IPsec at the server side, I didn't dive deep into your firewall rules, assuming that whoever wants to set up any kind of VPN should understand how firewalls work first.

Well I don't know and the guy setup the client (home) and the server (he is the owner(I got the server for 1 month to see if it's any good for sha512 IPsec IKEV2 (he supposed to setup that but since I didn't had the static IP on the client side he refused and said find a way and do it yourself. so here I am ))) and another router in other place, so if there is anything wrong with the firewall and the settings and configurations or there are leaks to fix I would highly appreciate it if you tell me how to fix them.

Your firewall rules at the initiator side are really leaky, but I assume there is a firewall on the outer router (the one between that Mikrotik and the internet), am I right?

About the server side I don't know about the client (home) there is just a TD LTE modem with default settings from ISP (the modem is locked) about my another router which is connected to a ADSL modem (bridge) also with default settings on the modem.

OK, the title says IKEv2 but we've silently moved to L2TP. Never mind, just run /tool sniffer quick port=500 on the server, and try connecting from the client. If it shows nothing, the problem is not in the server-side Mikrotik but most likely on the router(s?) standing between that Mikrotik and the internet, where the port forwarding is not configured at all or is configured incorrectly. Another possibility is that you're connecting to a wrong address.

Since the client side is LTE, chances are close to zero you could use pinhole punching to create the "port forwarding" rules dynamically.

So until you manage to set the port forwarding properly, it won't work.

I know this one is not related to the topic subject but this is my another router configurations, if you got time take look it and tell me if there is anything like a problem or something with it (firewall) that can be fix.

OK, the title says IKEv2 but we've silently moved to L2TP.

I know I thought since I had problem with that bringing that up might help with the actual topic of the subject.

OK, the title says IKEv2 but we've silently moved to L2TP. Never mind, just run /tool sniffer quick port=500 on the server, and try connecting from the client. If it shows nothing, the problem is not in the server-side Mikrotik but most likely on the router(s?) standing between that Mikrotik and the internet, where the port forwarding is not configured at all or is configured incorrectly. Another possibility is that you're connecting to a wrong address.

Since the client side is LTE, chances are close to zero you could use pinhole punching to create the "port forwarding" rules dynamically.

So until you manage to set the port forwarding properly, it won't work.

Okay I tried it but it shows nothing and then I thought okay what if I try with L2TP again and it shows this things so maybe this is telling us that port forwarding is correct and for some reasons IKEv2 is not initiating from client. is there anything I should've enabled in order for it to initiate? are Src Address & Dst Address are correctly set?

Also with the client (home) I can connect to another L2TP server without any problem (even before adding those two firewall rules) (don't have the access to the server) so maybe both UDP port 500 and UDP port 4500 are forwarding correctly on the client side and we got a problem with server side or either the settings (Src Address & Dst Address) are wrong

Client side: Server side:

Now wait - the server has a public IP on itself after all? If so, no port-forwarding is necessary at its side. Sorry, too many similar topics.

L2TP client should send packets to port 500 on the server's address; IKEv2 initiator should send packets to port 4500. Both should be shown by the sniffer.

You don't need to set any port forwarding on the client side. Show me /ip firewall filter export from the server, please.

Now wait - the server has a public IP on itself after all? If so, no port-forwarding is necessary at its side. Sorry, too many similar topics.

L2TP client should send packets to port 500 on the server's address; IKEv2 initiator should send packets to port 4500. Both should be shown by the sniffer.

You don't need to set any port forwarding on the client side. Show me /ip firewall filter export from the server, please.

yeah it's 5.xxx.xxx.xxx but on Route List you can see it's also connected to a xx.xx.xx.xx which is a public IP as well

here you go man:
# sep/27/2021 by RouterOS 6.48.4
# software id =
#
#
#
/ip firewall filter
add action=accept chain=input dst-port=500,4500 in-interface-list=all protocol=\
udp
add action=accept chain=input dst-port=1701 in-interface-list=all ipsec-policy=\
in,ipsec protocol=udp
add action=drop chain=forward port=25,110,465,587,2525,3535 protocol=tcp
add action=drop chain=forward port=25,110,465,587,2525,3535 protocol=udp
add action=accept chain=input dst-port=53 protocol=udp src-address-list=\
Allow_VPN_DNS
add action=drop chain=input dst-port=53 protocol=udp
add action=accept chain=input dst-port=53 protocol=tcp src-address-list=\
Allow_VPN_DNS
add action=drop chain=input dst-port=53 protocol=tcp
add action=accept chain=input limit=30,50 protocol=icmp
add action=drop chain=input protocol=icmp

OK, so I have swapped the roles of the routers when checking the configurations, and the one without a firewall is actually the server one, with the public IP directly on itself. Great. The right thing to do would be to disconnect it from the internet, netinstall it with the default configuration, restore the export there line by line but leaving out the firewall, except if the router is one of the higher models where no firewall is present in the default configuration. If that's the case, you have to create the minimum set of firewall rules first, before connecting it to internet again. And never use any of the passwords used before the netinstall again. The filth from the net is incredibly fast in squatting in if it could collect the credentials using the vulnerability in older RouterOS versions.

Nevertheless, in such a case, if you enable the IKEv2 peer and the identity associated to it on the client, you should see packets to arrive to 5.x.x.x:4500 if you run /tool sniffer quick port=4500. If you don't, something is rotten somewhere outside the server side router.

It may take some time between retries, so sniff for at least two minutes before declaring it a fail.

OK, so I have swapped the roles of the routers when checking the configurations, and the one without a firewall is actually the server one, with the public IP directly on itself. Great. The right thing to do would be to disconnect it from the internet, netinstall it with the default configuration, restore the export there line by line but leaving out the firewall, except if the router is one of the higher models where no firewall is present in the default configuration. If that's the case, you have to create the minimum set of firewall rules first, before connecting it to internet again. And never use any of the passwords used before the netinstall again. The filth from the net is incredibly fast in squatting in if it could collect the credentials using the vulnerability in older RouterOS versions.

Nevertheless, in such a case, if you enable the IKEv2 peer and the identity associated to it on the client, you should see packets to arrive to 5.x.x.x:4500 if you run /tool sniffer quick port=4500. If you don't, something is rotten somewhere outside the server side router.

It may take some time between retries, so sniff for at least two minutes before declaring it a fail.

It's on VMware
Okay so now after you said there is no firewall on the server the many logs with "TCP connection established from 178.128.66.56" with diffrent IP address make sense

Should I tell the guy for netinstall or just do it myself, I mean cause it's on the vmware after resetting am I gonna be able to access it?

Nevertheless, in such a case, if you enable the IKEv2 peer and the identity associated to it on the client, you should see packets to arrive to 5.x.x.x:4500 if you run /tool sniffer quick port=4500. If you don't, something is rotten somewhere outside the server side router.

right now when I run /tool sniffer quick port=4500 on both side I got only sends on client but nothing on server side. I'm worried maybe I should use the other public IP (the one server itself connected to) or different LAN IPs.
I used 192.168.11.111 (client) which is the router, is it correct or I should use 192.168.11.0 or 192.168.0.254 (modem)?

Should I tell the guy for netinstall or just do it myself, I mean cause it's on the vmware after resetting am I gonna be able to access it?

If it's on a VMware you can manage, just delete the VM and deploy it again from the template, but do not connect the internet-facing interface before you set up the basic firewall rules:

/interface list
add name=WAN

/interface list member
add list=WAN interface=ether1

/ip firewall filter
add chain=input connection-state=established,related action=accept
add chain=input connection-state=invalid action=drop
add chain=input protocol=icmp action=accept
add chain=input in-interface-list=WAN protocol=udp dst-port=500,4500 action=accept
add chain=input in-interface-list=WAN protocol=udp dst-port=1701 ipsec-policy=in,ipsec action=accept
add chain=input in-interface-list=WAN action=drop

No rules in chain forward as you seem not to use it as an actual router so far.

On the other hand, if the goal is to test sha512, why don't you deploy two CHRs on it and let them establish an IPsec tunnel to each other? It will definitely be a better througphut test than via some LTE overseas...

Should I tell the guy for netinstall or just do it myself, I mean cause it's on the vmware after resetting am I gonna be able to access it?

If it's on a VMware you can manage, just delete the VM and deploy it again from the template, but do not connect the internet-facing interface before you set up the basic firewall rules:

/interface list
add name=WAN

/interface list member
add list=WAN interface=ether1

/ip firewall filter
add chain=input connection-state=established,related action=accept
add chain=input connection-state=invalid action=drop
add chain=input protocol=icmp action=accept
add chain=input in-interface-list=WAN protocol=udp dst-port=500,4500 action=accept
add chain=input in-interface-list=WAN protocol=udp dst-port=1701 ipsec-policy=in,ipsec action=accept
add chain=input in-interface-list=WAN action=drop

No rules in chain forward as you seem not to use it as an actual router so far.

On the other hand, if the goal is to test sha512, why don't you deploy two CHRs on it and let them establish an IPsec tunnel to each other? It will definitely be a better througphut test than via some LTE overseas...

No all I got is winbox access

If so, and since the whole exercise is only for evaluation of sha512, leave it as it is, just be ready that the CHR may start sending tons of spam somewhere. And revert back to investigation why packets to port 500 do make it through whilst packets to port 4500 don't.

When you enable the peer & identity at the client and run the same /tool sniffer quick port=4500 on it, can you see the attempts there?

When you enable the peer & identity at the client and run the same /tool sniffer quick port=4500 on it, can you see the attempts there?

Yes

Okay... let's do another thing then, set the port parameter on the /ip ipsec peer row at the client to 500, and sniff at both the server and the client with port=500 (still with IKEv2, not L2TP/IPsec). What's the result?

Okay... let's do another thing then, set the port parameter on the /ip ipsec peer row at the client to 500, and sniff at both the server and the client with port=500 (still with IKEv2, not L2TP/IPsec). What's the result?

I managed to screw the server firewall rules so it's not accessible anymore. gonna give that guy a call to reset or fix it. then I will try this. Thanks for all the help man, I really appreciate it.