Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
New Contributor II

help with routing

i have a network with mikrotik. we are planning to replace mikrotik with fortigate 100F (v7.4.0)

now i have:

tag vlans: 32, 33 to mikrotik
tag vlans: 32, 33 to fortigate
untag vlans: 32 to two hosts

two hosts: vlan 32, untag (gw: - mikrotik) , (gw - fortigate)


trunk vlans: 32 (, 33 (


config system interface

edit "vlan0032"

set vdom "root"

set ip

set allowaccess ping https ssh snmp http

set device-identification enable

set role lan

set snmp-index 38

set interface "x2"

set vlanid 32



edit "vlan0033"

set vdom "root"

set ip

set allowaccess ping https ssh snmp http fgfm

set device-identification enable

set role lan

set snmp-index 35

set interface "x2"

set vlanid 33



config firewall policy

edit 7

set name "all"

set srcintf "any"

set dstintf "any"

set action accept

set srcaddr "all"

set dstaddr "all"

set schedule "always"

set service "ALL"

set logtraffic all


ping from to (fortigate) - working

ping from to - dont working

why ?
theoretically, the traffic should go like this:
ask: - (mikrotik directly connected) -
answer: (dir. conn.) -

fortigate capture showing incoming packets from, but outgoing - no

1 Solution
New Contributor II

solved the problem like this:


config router static
    edit 3
        set gateway
        set device "vlan0033"


at the time of migration it will be like this

View solution in original post




I would recommend to collect debug flow and check for anomalies:


diagnose debug flow filter daddr <destination IP address>

diagnose debug flow filter proto 1
diagnose debug flow show function-name enable
diagnose debug flow trace start 10
diagnose debug enable

New Contributor II


2023/06/02 03:30:02,"vd-root:0 received a packet(proto=1,> tun_id= from vlan0033. type=8, code=0, id=1, seq=36917."
2023/06/02 03:30:02,"allocate a new session-0737965e, tun_id="
2023/06/02 03:30:02,"in-[vlan0033], out-[]"
2023/06/02 03:30:02,len=0
2023/06/02 03:30:02,"result: skb_flags-02000000, vid-0, ret-no-match, act-accept, flag-00000000"
2023/06/02 03:30:02,"reverse path check fail, drop"
2023/06/02 03:30:02,trace

2023/06/02 03:30:07,"vd-root:0 received a packet(proto=1,> tun_id= from vlan0033. type=8, code=0, id=1, seq=36918."
2023/06/02 03:30:07,"allocate a new session-0737992b, tun_id="
2023/06/02 03:30:07,"in-[vlan0033], out-[]"
2023/06/02 03:30:07,len=0
2023/06/02 03:30:07,"result: skb_flags-02000000, vid-0, ret-no-match, act-accept, flag-00000000"
2023/06/02 03:30:07,"reverse path check fail, drop"
2023/06/02 03:30:07,trace

from the logs we see "reverse path check fail, drop", this is caused because FGT will receive a packet for a directly connected subnet in interface "vlan0032" from another interface which is not considered safe and the packet is dropped.

I don't know the reason behind this type of configuration but this is not the right way to configure it.

- Emirjon
If you have found a solution, please like and accept it to make it easily accessible for others.

The issue is the client (.251) that is using Mikrotik as the GW is sending it's packets to Mikrotik to route them.

When Mikrotik receives packet with destination it has a directly connected route on VLAN33. It will forward the packet out that interface and it will be received by the FortiGate.


FortiGate will not be happy about this because from its viewpoint exists on VLAN32 not VLAN33.


It's a very weird set up.


Why is it being done this way?


As the OP stated, it's done for a transitional setup to migrate from Mikrotik to FortiGate without realizing "asymm routing" is not allowed with a modern FW to prevent spoofing. What the OP needs to do is NOT to have the same VLAN on both Mikrotik and FortiGate at any moment, and have to move one VLAN with all devices connected to it to the new FortiGate at the same time.




Sorry I didn't see him mentioned anything about a transitional setup. If so IMO it's best to just cut it all over at once. Test a couple endpoints first and then push it over during a window and run tests.


OP can definitely have the same VLAN on both devices. And if it's for transition from one to the other then he wants the same VLAN on both.


Solution here would be to just SNAT the outbound connections from the Mikrotik so the FGT doesn't complain about RPF checks. And it's not assymmetric routing that's the problem, it's RPF.


Or turn off RFP check but make sure it's turned on again!

New Contributor II

such a strange configuration is due to the fact that the mikrotik configuration is quite voluminous and we want to gradually transfer our network to fortigate


OK in this transitional state is there an actual requirement for traffic to route from internal network->through Mikrotik->through Fortigate?


It seems like this wouldn't be an actual requirement. Either internal hosts are routed through the Mikrotik or the Fortigate. In this case you will not have any problems.


Your issues arise when the Mikrotik tries to route internal packets back trhough the FortiGate...

Contributor III

Based on the information provided, it seems that the issue lies in the routing configuration of the FortiGate firewall. When a ping request is sent from to, the following should be the expected path:

1. The ping request goes from to its default gateway, which is (MikroTik router).
2. The MikroTik router receives the ping request and looks at its routing table.
3. Since the destination IP address,, falls within the subnet, which is directly connected to the FortiGate firewall, the MikroTik router forwards the traffic directly to the FortiGate firewall.
4. The FortiGate firewall receives the ping request on its interface with IP address
5. The FortiGate firewall processes the ping request and sends the reply back to via the same interface.

Based on the configuration you provided, it seems that the FortiGate firewall is correctly configured to handle the traffic. However, there might be a missing configuration or a routing issue. Here are some steps you can take to troubleshoot the problem:

1. Verify the routing configuration on the FortiGate firewall: Ensure that there is a route configured on the FortiGate firewall to reach the subnet via the interface connected to the MikroTik router (x2 interface). This route is necessary to send the reply traffic back to the MikroTik router.

2. Check the default gateway on the hosts: Ensure that the default gateway on the hosts in VLAN 32 ( is set correctly to point to the MikroTik router ( This will ensure that the ping requests are sent to the correct gateway.

3. Verify the VLAN configuration: Double-check the VLAN configuration on the FortiGate firewall (x2 interface) and ensure that VLAN tagging is correctly configured for VLANs 32 and 33. Make sure that the VLAN ID matches the configuration on the MikroTik router.

4. Verify connectivity between the MikroTik router and the FortiGate firewall: Ensure that there is connectivity between the MikroTik router and the FortiGate firewall. You can try pinging the FortiGate's IP address ( from the MikroTik router to verify this.

By going through these troubleshooting steps, you should be able to identify and resolve any configuration or routing issues that may be causing the problem.

Top Kudoed Authors