help with routing

[saskuu]

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

now i have:

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

two hosts: vlan 32, untag
192.168.5.251/24 (gw: 192.168.5.1 - mikrotik) ,
192.168.5.252/24 (gw 192.168.5.2 - fortigate)

mikrotik
trunk vlans: 32 (192.168.5.1/24), 33 (192.168.20.1/24)

fortigate:

config system interface

edit "vlan0032"

set vdom "root"

set ip 192.168.5.2 255.255.255.0

set allowaccess ping https ssh snmp http

set device-identification enable

set role lan

set snmp-index 38

set interface "x2"

set vlanid 32

next

edit "vlan0033"

set vdom "root"

set ip 192.168.20.2 255.255.255.0

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

next

end

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

end

ping from 192.168.5.252 to 192.168.20.2 (fortigate) - working

ping from 192.168.5.251 to 192.168.20.2 - dont working

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

fortigate capture showing incoming packets from 192.168.5.251, but outgoing - no

[abarushka]

Hello,

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

[saskuu]

Time,Message

109
2023/06/02 03:30:02,"vd-root:0 received a packet(proto=1, 192.168.5.251:1->192.168.20.2:2048) tun_id=0.0.0.0 from vlan0033. type=8, code=0, id=1, seq=36917."
2023/06/02 03:30:02,"allocate a new session-0737965e, tun_id=0.0.0.0"
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

110
2023/06/02 03:30:07,"vd-root:0 received a packet(proto=1, 192.168.5.251:1->192.168.20.2:2048) tun_id=0.0.0.0 from vlan0033. type=8, code=0, id=1, seq=36918."
2023/06/02 03:30:07,"allocate a new session-0737992b, tun_id=0.0.0.0"
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

[ebilcari]

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.

[gfleming]

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 192.168.20.2 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 192.168.5.0/24 exists on VLAN32 not VLAN33.

It's a very weird set up.

Why is it being done this way?

[Toshi_Esumi]

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.

Toshi

[gfleming]

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!

[saskuu]

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

[gfleming]

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...

[Christian_89]

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 192.168.5.251 to 192.168.20.2, the following should be the expected path:

1. The ping request goes from 192.168.5.251 to its default gateway, which is 192.168.5.1 (MikroTik router).
2. The MikroTik router receives the ping request and looks at its routing table.
3. Since the destination IP address, 192.168.20.2, falls within the subnet 192.168.20.0/24, 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 192.168.5.2.
5. The FortiGate firewall processes the ping request and sends the reply back to 192.168.5.251 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 192.168.5.0/24 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 (192.168.5.251) is set correctly to point to the MikroTik router (192.168.5.1). 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 (192.168.5.2) 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.