Connecting a MikroTik RouterOS device to a Fortinet FortiGate firewall via an IPsec site-to-site tunnel bridges two distinct operating systems. While both hardware lines handle enterprise routing effectively, bridging them using open standards requires matching cryptographic parameters precisely. A single mismatched hashing algorithm or incorrect proxy ID setting will prevent the security associations from establishing.
This guide walks through configuring a stable, production-ready IPsec tunnel using Internet Key Exchange version 2 (IKEv2). We'll map out Phase 1 parameters, Phase 2 security proposals, peer authentications, and the necessary firewall rules on both ends to ensure clean packet flow.
Planning the Tunnel Parameters
Before touching either command-line interface or web GUI, you need to map out your addressing and cryptographic suites. Mixing vendor defaults causes most initial handshake failures.
For this setup, assume the following network parameters:
- FortiGate Public IP:
203.0.113.10 - FortiGate Internal Subnet:
192.168.10.0/24 - MikroTik Public IP:
198.51.100.20 - MikroTik Internal Subnet:
10.0.5.0/24 - Pre-Shared Key (PSK):
SecureTunnelKey2026!
For modern deployments, skip legacy protocols like DES or MD5 entirely. We will use AES-256 for encryption, SHA-256 for integrity checks, and Diffie-Hellman Group 14 (or higher) for key exchange.
Configuring the FortiGate Firewall
You can configure the FortiGate using either the web-based FortiOS manager or the CLI. Setting up a custom tunnel template ensures you retain full control over local and remote subnet selectors.
Navigate to VPN > IPsec Tunnels, click Create New, and choose Custom. Name the tunnel MikroTik-Branch and configure the Phase 1 settings:
- Remote Gateway: Static IP Address
- IP Address:
198.51.100.20(MikroTik WAN IP) - Interface: Select your primary WAN port
- IKE Version: IKEv2
- Authentication Method: Pre-shared key
- Pre-Shared Key:
SecureTunnelKey2026! - Proposal: Encryption set to
aes256, Authentication set tosha256 - DH Group:
14
Next, configure the Phase 2 selectors within the same tunnel configuration wizard:
- Local Address:
192.168.10.0/24 - Remote Address:
10.0.5.0/24 - Encryption:
aes256 - Authentication:
sha256 - PFS (Perfect Forward Secrecy): Enabled, using DH Group
14
FortiGate Firewall Policies and Routes
An IPsec tunnel on FortiGate requires explicit firewall policies to permit traffic in both directions. Go to Policy & Objects > IPv4 Policy and create two distinct rules.
For outbound traffic from FortiGate to MikroTik:
- Incoming Interface: Internal LAN interface
- Outgoing Interface:
MikroTik-Branch - Source:
192.168.10.0/24 - Destination:
10.0.5.0/24 - Action: ACCEPT
- NAT: Disabled
For inbound traffic from MikroTik to FortiGate, create the mirror policy with incoming interface set to MikroTik-Branch and outgoing interface set to your internal LAN, reversing the source and destination subnets. Ensure that automatic static routes are enabled for the tunnel interface so the FortiGate knows where to route packets destined for the 10.0.5.0/24 network.
Configuring the MikroTik RouterOS Device
Log into your MikroTik router via WinBox or SSH. All IPsec settings live under the /ip ipsec menu. We will build the configuration sequentially: Profile, Peer, Proposal, Identity, and Policy.
1. IPsec Profile (Phase 1)
Create a profile that matches the FortiGate's IKEv2 cryptographic suite:
/ip ipsec profile
add name=fortigate-profile \
enc-algorithm=aes-256 \
hash-algorithm=sha256 \
dh-group=modp2048 \
nat-traversal=yes
2. IPsec Peer
Define the remote FortiGate peer address and bind it to your newly created profile:
/ip ipsec peer
add name=fortigate-peer \
address=203.0.113.10 \
profile=fortigate-profile \
exchange-mode=ike2
3. IPsec Proposal (Phase 2)
Set up the proposal governing data encryption parameters:
/ip ipsec proposal
add name=fortigate-proposal \
enc-algorithms=aes-256-cbc \
auth-algorithms=sha256 \
pfs-group=modp2048
4. IPsec Identity and Pre-Shared Key
Associate the peer with your authentication secret:
/ip ipsec identity
add peer=fortigate-peer \
auth-method=pre-shared-key \
secret="SecureTunnelKey2026!"
5. IPsec Policy
Define the traffic selectors (encryption domains) that dictate which local packets enter the tunnel:
/ip ipsec policy
add peer=fortigate-peer \
tunnel=yes \
src-address=10.0.5.0/24 \
dst-address=192.168.10.0/24 \
protocol=all \
action=encrypt \
proposal=fortigate-proposal
Handling MikroTik Firewall and NAT Rules
MikroTik routers often employ masquerading NAT rules on their WAN interfaces to share a single public IP address with local clients. If you don't exclude your VPN traffic from this masquerade rule, your internal packets will have their source IPs rewritten, breaking the IPsec policy match.
Navigate to IP > Firewall > NAT and create an accept rule positioned above your general masquerade rule:
/ip firewall nat
add chain=srcnat action=accept \
src-address=10.0.5.0/24 \
dst-address=192.168.10.0/24 \
place-before=1
Additionally, ensure your input and forward filter rules permit UDP ports 500 and 4500 for ISAKMP and NAT-T, and allow traffic originating from the remote subnet under the forward chain. For official documentation on packet flow and advanced routing structures, consult the MikroTik Documentation Portal.
Verifying and Troubleshooting the Tunnel
Once applied, the tunnel should initialize automatically when local traffic attempts to traverse the link. You can verify connectivity using built-in diagnostic tools.
On the MikroTik side, check your active security associations and running peers:
/ip ipsec active-peers print
/ip ipsec installed-sa print
On the FortiGate side, navigate to Monitor > IPsec Monitor to check active tunnels. If the tunnel stays down or packets drop, watch out for these frequent misconfigurations:
- Clock Drift: IPsec relies heavily on accurate timestamps. If your MikroTik and FortiGate are pulling time from different NTP servers with significant drift, authentication will fail. Verify both systems sync via standard Network Time Protocol settings.
- Mismatched Proposal Selectors: Ensure that the subnet masks match identically. If the FortiGate expects a
/24subnet but the MikroTik policy targets a specific host or different subnet mask, Phase 2 negotiations will fail silently. - Overlapping NAT Masquerade: If ping requests leave the MikroTik LAN but never arrive at the FortiGate, double-check your NAT rule ordering to ensure local subnet traffic isn't being masked behind the WAN interface.
Frequently Asked Questions
Can I configure this tunnel using IKEv1 instead of IKEv2?
Yes. While IKEv2 offers faster handshakes and better built-in NAT traversal, you can use IKEv1 by changing the peer settings on MikroTik and adjusting the FortiGate Phase 1 settings to Main or Aggressive mode. Keep in mind that IKEv2 is standard for modern secure deployments.
Why does my MikroTik show an established peer but zero bytes transferred?
This usually indicates an issue with proxy IDs (Phase 2 selectors) or a missing NAT exclusion rule. If your MikroTik's general masquerade rule is intercepting the packets before the IPsec policy catches them, the traffic won't enter the tunnel. Make sure your action=accept rule sits above your masquerade rule.
Do I need to configure static routes on MikroTik for an IPsec policy tunnel?
Unlike interface-based VPNs (like GRE or VXLAN), standard policy-based IPsec tunnels on MikroTik automatically intercept matching traffic via the IPsec policy engine. You typically do not need a dedicated /ip route entry unless you are routing traffic explicitly through a dynamic routing daemon over the tunnel.
How do I handle dynamic public IPs on the MikroTik side?
If your MikroTik sits behind a dynamic consumer connection, you can configure the FortiGate as a dial-up server by setting the remote gateway to "Dial-Up User" and configuring Aggressive mode or peer ID lookups, while your MikroTik points its peer address to a dynamic DNS hostname.
