Routing issues Cisco VS Fortigate help

[rpratt]

Hi - hoping someone can help me with this seemingly simple problem. Coming from the Cisco world we are replacing two of our routers with two FortiGate firewalls in HA active-passive mode. 

My knowledge of the FortiGate configuration is limited (but growing). I'm currently trying a basic configuration with 1 PC connected to 1 switch which is connected to one FortiGate with two connections. Currently only one of the two networks on the Fortigate is reachable (192.168.10.1).

I've setup an identical configuration but instead using our cisco router and as you can see in the routing table it is logging the 192.168.116.0 route reachable via the two routes. The Fortigate is only showing this route via port2 even though it is also technically reach able via port1. I'm assuming this is the reason I can only reach the network from the port2 link and not the port1 ip of 192.168.20.1. 

If this is the reason how can I populate the route to 192.168.116.0 via either port1 or port 2 instead of just port 2 - same as the cisco routing table. 

Thanks,


Cisco Routing table


Fortigate replacing the cisco 
Fortigate routing table

[Richie_C]

Hi - If i understand correctly, you are talking about equal cost multipath (ECMP).  The feature allows you to load-balance across multiple links:

https://docs.fortinet.com/document/fortigate/6.4.5/administration-guide/25967/equal-cost-multi-path

Only static/ospf/bgp routes are supported for this feature. So RIP isn't going to work I'm afraid.

[Richie_C]

You could confirm this behaviour by trying it with 2 statics.

Thanks

[rpratt]

Hi Richie - 

The two static routes did resolve the issue however I'd like to ask in the GUI what is the use of this "interface" box under RIP?

Also is there a technical reason why Fortinet doesn't allow multiple routes via RIP while other vendors do but allows this via OSPF? Just curios because while creating all our static routes on our firewall is doable it is kind of a pain! 

Anyways appreciate the support and help on this issue it'll get us to where we need to be.

[Richie_C]

The interface option is essentially giving you additional options. It would enable you to change the version of RIP or enabled authentication for example. 

I don't know the reason why RIP isn't supported. Although, from experience,  I don't  see many RIP networks these days. So that might be a factor.

[rpratt]

Thanks for the reply. I'm not trying to load balance between the links. I'm just trying to be able to reach either network from my 192.168.116.0 network. The Fortigate is only able to reach this network via port2 (the 192.168.10.0 network). So when I try to reach the network on port1(the 192.168.20.0 network) from inside my LAN at 192.168.116.0 the fortigate is unable to respond. At least that is my understanding.

Using the Cisco router instead of the Fortigate firewall RIPv2 auto populates the 192.168.116.0 route via either interface gi0/0 (port 1 on the fortigate) or gi0/1( port 2 on the fortigate).

Hopefully this makes sense... we are able to use static routes as we do not have very many routes but for dynamic routing protocols RIP is all that is available due to limitations on our L3 switches we will be using elsewhere in the network (not part of this test).

[Richie_C · Accepted solution]

I think the problem is the same. if you don't have a route in the routing table when the FortiGate receives the packet, It will fail the RPF (reverse path forwarding) check and drop the packet.

I do not believe that you can have 2 RIP routes in the routing table. As mentioned, It is only possible with static/ospf/bgp.

If you have a lab, then confirming it with 2 static routes would confirm the behaviour.

[rpratt]

Thanks - I will try this shortly. If this is the case this seems to be a poor limitation of the FortiGates. Nothing special was done on the Cisco hardware that is small business grade and it was able to understand and implement this without issue... 

In our case if the static routes work it will be a satisfactory workaround that will allow us to move forward... Thanks again and will let you know.

[Richie_C]

Running the following commands from the CLI should also confirm what is happening:

diagnose debug enable
diagnose debug flow filter saddr <source address>
diagnose debug flow show fun enable
diagnose debug flow show ip enable
diagnose debug flow trace start 5

[Toshi_Esumi]

Not sure about your topology. FWs generally block traffic coming back from a different interface from the destination from the interface it sent out outgoing traffic to the same destination, unlike routers (Cisco, etc.). You probably need to change your network topology to avoid that. For example, if the device has 10.254 and one has 20.254 are the same device (switch?) connecting to 116.0/24 network, you can consolidate them as one link like using LAG/LACP if you're concering about the bandwidth and redundancy.

Toshi