I am new to RouterOS and seeking assistance with an IPSec IKEv2 tunnel configuration between a Fortigate and a MikroTik router. Below is the setup:
MikroTik Local Subnet: 192.168.0.0/24
MikroTik WAN IP: Static
Fortigate Local Subnet: 10.10.10.0/24
Fortigate WAN IP: Dynamic
Problem 1:
The tunnel is successfully established; however, I am unable to ping devices on the Fortigate site from the MikroTik site. Pinging from the Fortigate site to the MikroTik site works fine. I suspect the issue lies with the MikroTik configuration, possibly involving static routes or firewall rules. Could someone guide me on how to resolve this?
Problem 2:
Since the Fortigate WAN IP is dynamic, I would prefer to configure the MikroTik as passive, allowing the Fortigate to act as the initiator. This is necessary because the Fortigate could potentially be behind CGNAT.
When the MikroTik is set to passive mode, the connection fails to establish, as it seems no requests are reaching the MikroTik. Conversely, when the MikroTik is set as the initiator, the tunnel connects successfully, but the issue described in Problem 1 persists.
I would greatly appreciate your assistance with resolving these two issues. If needed, I can share the current configuration for further clarity.
Just an experienced guess:
Problem #1 is typically caused by not excluding the traffic initiated from the Mikrotik side from getting src-nated. IPsec policies matching is the very last thing to be done as the packet is just about to be sent out using the interface chosen by regular routing, so after even an eventual src-nat operation took place. So if you allow the source address of a packet to get changed to the one assigned to the out-interface (typically, the WAN), the policy cannot “see” it. NAT rules are only evaluated when handling the initial packet of each connection, so connections initiated from the Fortigate side are not affected.
Problem #2 is usually caused by missing permissive rules in chain input of the firewall filter. As the router attempts to initiate connections to the remote router, it creates the pinhole in the stateful firewall so the “accept established or related” rule lets the packets from the remote router in; if the router only acts as a responder, you have to let those packets in explicitly, using a protocol=udp dst-port=500,4500 action=accept rule a proper place in chain input of filter.
thank you very much for your time and your answer.
problem 1:
i think i can understand what are you saying but what should i do ?
UPDATE: ok thank you now it is working, i excluded 10.10.10.0/24 subnet from masquarade srcnat action accept
problem 2:
I added the input chain accept udp dest-port 500,4500 but nothing changed.
Post the complete export, not just the IPsec part - we need to modify the firewall rules for Problem #1 and check them for Problem #2. Also, 6.43.2 is an “ice age” version from the software development perspective, with lots of security issues found and fixed in the meantime, but also with several changes in the way how IPsec is configured.
I would suggest to upgrade to 6.49.13 (which is the long term version) as the first step, even before exporting the complete configuration, of course after first making both a backup and an export of the configuration, ideally just a few minutes after rebooting the device, and saving them outside the 2011 (on your PC). It is always the best common practice but with such a far-leaping upgrade it is even more important.
i will schedule a firmware upgrade soon.
As updated on my previous reply the problem 1 has been solved following your advice exluding destination subnet from masquerade srcnat .
Now we have only the problem 2. I added the iput chain accept udp 500,4500 but still cant work on passive mode.
Two separate issues. One is the firewall setup - the permissive rules for AH and ESP are not necessary at all as the Fortigate is behind a NAT so even ESP will be encapsulated into UDP (and AH cannot be used at all even if you wanted to use it, which is not the case). Also, the permissive rule for UDP 500 and 4500 should be placed after (below) the “drop invalid” one because you want most packets to only ever hit the “accept established, related” one. But none of these is relevant to the fact that the incoming attempts from Fortigate fail.
The second one is that you cannot see anything to arrive from the Fortigate to port 500 or 4500 and you only get those strange packets from port 64999 to port 64999. That looks like these are unrelated to IPsec at all, or like a misconfiguration at Fortigate side, or as if some NAT on the path was doing weird things. So I would make the IPsec peer used for Fortigate passive at Mikrotik side, disable the peer representing the Mikrotik at Fortigate side for 5 minutes, start sniffing on the Mikrotik while filtering on the public address of the Fortigate, and re-enable the peer at Fortigate side. If it comes up, OK, if it doesn’t, the sniff will show you from which port at “Fortigate” side the connection attempts arrive to which port on the Mikrotik side, and you can decide whether there is a way to fix that on their end or whether it will be necessary to use some dst-nat rules on Mikrotik side to compensate for that.
I have second wan on my fortigate in order to test second isp.but there is nat happening there. My fortigates wan is 192.168.11.1 and natted on router to public IP with DMZ on for ibound. Should i change anything to mikrotik in order to make it listen on this ?
Have you tried the procedure I have suggested above, to disable any connection attempts for 5 minutes and then re-enable them on the Fortigate side? What was the outcome?