Challenge using the RB760iGS

RouterOS General
1

RouterOS 7.23.1 on RB760iGS / hEX S.

Goal:
IKEv2 certificate VPN to FortiGate dial-up hub.
Remote LAN is 192.168.125.0/24.
Need VPN-visible NAT addresses 1.1.5.x for PLC/HMI access.

Working:
IKEv2 certificate tunnel establishes.
Phase 2 establishes with:
MikroTik policy: 1.1.5.0/24 -> 192.168.130.0/24
FortiGate selector: 192.168.130.0/24 -> 1.1.5.0/24

MikroTik has:
1.1.5.1/24 on bridge
192.168.125.1/24 on bridge

Confirmed working:
MikroTik ping 192.168.130.1 source 1.1.5.1 succeeds.

Problem:
FortiGate ping 1.1.5.110 source 192.168.130.1 enters IPsec tunnel, but MikroTik NAT rules never count packets.

Tried:
dst-nat:
src-address=192.168.130.0/24
dst-address=1.1.5.110
to-addresses=192.168.125.110

src-nat:
src-address=192.168.125.110
dst-address=192.168.130.0/24
to-addresses=1.1.5.110

Also tried full netmap:
1.1.5.0/24 <-> 192.168.125.0/24

In both cases:
IPsec SA counters increment, but NAT counters and connection tracking do not.

Can RouterOS policy-based IPsec perform NAT-LAN style translation for decrypted inbound traffic, like 1.1.5.110 -> 192.168.125.110?

If yes, where must the NAT be applied? Firewall NAT, mangle, raw, mode-config, policy template, or a different IPsec design?

2

Interestingly enough I found that the issue was not just the MikroTik, but the FortiGate as well. While making the IPsec tunnel on the FortiGate side, the IPsec tunnel actually created a route for the virtual IP 1.1.5.0/24 but it's "distance" was 15 and the static route that I had created for the same connection had a "distance" of 10. So, the FortiGate was trying to use the closer one. I deleted the one I made and part of it was correct.

I also discovered that i created my NAT rules incorrectly because I had the source IP under the source IP address lists instead of the source IP address area (I simply overlooked it). I corrected that and then the entire connection went off without a hitch. Oh! I did have to turn off MikroTik FastTrack though. That did cause an issue when running remote connection software over the IPsec tunnel.

3

The default firewall rules have exceptions for ipsec traffic to not get fasttracked.
If you know the ports/protocols used by the remote connection software, perhaps you could just except them from fasttrack as well. (an accept rule for this traffic prior to the fasttrack rule)