Why does this work without asymmetric routing?

[smxko]

Hi,

we have two /29 IP blocks from our ISP. IPs from the first block are used for SNAT and a few VIPs. There are two default routes, one for each gateway because both subnets have different gateways. We didn't want ECMP, so we increased the distance for the default route to the gateway of block 2.

We also run VIPs on IPs of the second block. I was wondering why this is even working because the default route for block 2 is not installed in the routing table because of the higher distance. Therefore, return traffic for VIPs of block 2 must flow through the gateway of block 1. Asymmetric routing is disabled, I checked it.

We are also using port forwarding on the VIPs, so it shouldn't automatically use the VIP's public IP for return traffic.

Edit: I checked the session table and it looks like Fortigate SNATs the reply traffic. But I don't know why, the documentation says that it sould only be doing this when One-to-One NAT is applied without port-forwarding. Or does this rule only apply to traffic originating from the server behind the VIP and not reply traffic?

[Dhruvin_patel · Accepted solution]

Greetings!

FortiGate is a stateful firewall.

When FortiGate receives the traffic, it creates a session, and the return traffic is sent based on that created session. 

When the packet enters the FortiGate, it will follow the flow defined in this document, https://docs.fortinet.com/document/fortigate/6.4.0/parallel-path-processing-life-of-a-packet/86811/p... and create the session.

The traffic below to the same session will be sent out using the session info.

As a result, in your case, the traffic received on another block will create a session and then return the allowed/routed based on the created session. 

Best Regards!

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

[smxko]

Thanks, so is the routing table is negelcted for lookups for reply traffic and always following the initial session? I've had scenarios where I forgot to add a static route back to the source and reply traffic didn't work.

[dingjerry_FTNT]

FGT will always run the Reverse Path Check for ingress traffic if asymmetric routing is NOT enabled. Please check this KB for more information about RPC check:

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Details-about-FortiOS-RPF-Reverse-Path-For...

Again, your information and description are ambiguous. For further assistance, it's better to provide relevant configurations and your network diagram. 

[smxko]

I think the main reason why RPF doesn't block the traffic and asymmetric routing is not used here is because ingress and egress interface is still the same for both directions.

There are two public IP blocks on wan1. Only the gateway of block 1 is installed in the routing table. When VIPs of block 2 are accessed, the reply traffic leaves interface wan1 (RPF Ok) but uses the gateway of block 1. I thought that RPF is designed in a way that even the routers IP address needs to be the same on the route back, so that reply traffic for VIPs of block 2 is also back sent to the gateway of block 2. But RPF obviously only cares about the interface, otherwise this would not work.

I printed out the sessions using diag sys session list and there I saw that reply traffic for VIPs on block 2 uses the gateway of block 1 but the same interface of course.

This would probably only lead to RPF fail if block 2 was actually on a different interface and beacause of the gateway from block 2 missing from the routing table, reply traffic would be sent back through a different interface (wan2) than the ingress traffic (wan1).

[dingjerry_FTNT]

Return Path Check only checks whether there is a routing entry match to the source IP of the incoming traffic flow with the ingress interface.  

It does not care about the gateway info because the routing table has it.

So once the Return Path Check passes, FGT will look for the routing info (including the gateway, interface pair, and so on) and record it in the session table for return traffic.

[dingjerry_FTNT]

Hi @smxko ,

Your description is ambiguous. 

It's better you share relevant configurations for better understanding.  And if you can provide with a network diagram, it would be much better.