Operation to enable asymroute because policy-based routing can't be worked.

[KenjiKang]

Hi,

I need to configure policy-based routing and I'm testing it, but it doesn't work even though the configuration is correct.

According to a veteran's advice, I temporarily enabled asymroute, and when I immediately disabled it, the routing started working.

I'm reluctant to use this method. Is this a well-known workaround?
Do you have any advice on a better way to handle this?

Hardware: FortiGate 120G OS: 7.4.8

Thanks,
Kenji

[AEK]

Hi Kenji

Asymmetric routing is a workaround not so good for security. It was a good technique in ancient world network but it should not be use anymore if you want a good network security.

The right solution is either redesign your network architecture to avoid the need for asym routing, or you can also use auxiliary sessions instead, which is secure (may also need some redesign).

Have a look here:

https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-the-FortiGate-behaves-when-asymmetric-...

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Differences-between-asymmetric-routing-and...

Hope it helps.

[Toshi_Esumi]

Until you share the topology, hopefully with a diagram, around the policy route you intended to steer traffic to a specific direction including the policy route itself, we can't comment why it's not working.

Toshi

[KenjiKang]

Toshi-san

Here is a simple topology diagram.

---

This is a test configuration, so it differs slightly from the production environment, but I believe it is sufficient for verifying the behavior of the policy-based route.

My personal hypothesis is that the issue might be caused by using Destination NAT in conjunction with the policy-based route, or by setting the destination of the policy-based route to the default route when one already exists.

Any additional advice would be greatly appreciated.

Thank you

Kenji

[Toshi_Esumi]

So, all traffic initiated by the DMZ Server needs to go to LAN2 Server regardless the destination IP of those outgoing packets instead of going out through the "Default Gateway" to the Internet?
Then you need to have another default route going toward the LAN2 Server. Do you have it? Without a proper route matching the destination IPs in the routing-table, no policy routes would work. Since you want all other internet-bound traffic, like from LAN1 PC, to go out to the internet directly, you need to make the default route toward the LAN2 Server less-preferable. If static, you can do that with priority.

Toshi

[KenjiKang]

Toshi-san

Thank you for your kind advice.

There is currently no default route configured for the LAN2 server.
According to your advice, the policy route and the routing destination must match.
Therefore, based on the current configuration, I understand that I need to set a low-priority static route (default route) for the LAN2 server (specifically, by setting the priority to 2 or higher).
Is this understanding correct?

If my understanding is correct, I will test it in a verification environment next week and share the results with you.
Also, this is the first time I've heard that the policy route and the routing destination need to match.
If you have any evidence of this fact, I would greatly appreciate it if you could share any documentation.

Thank you
Kenji

[Toshi_Esumi]

I didn't say "the policy route and the routing destination need to match."
I said, when you steer a particular traffic, let's say to 8.8.8.8/32, toward an interface, there needs to be a matching route, which could be just 8.8.8.8/32, or 8.8.0.0/16, or 0/0. Otherwise the FGT can't route the packet to the interface.
In your case, you implicitly said "all traffic from the DMZ server". So only option is 0/0 route.

Basically FGT's policy route doesn't inject any routes itself nor override (unlike some other vendors routers/FWs). Proper routes always need to exist regardless using policy-route, SD-WAN steering or whatever.
 
Toshi

[Toshi_Esumi]

It's hard to find this fact in FTNT's documenation. But this KB states it in one sentence even with smaller fonts:
https://community.fortinet.com/t5/FortiGate/Technical-Tip-Configuring-the-Firewall-Policy-Routes/ta-...

"Requirement: The routing table must have an active route to the gateway or the destination."

That's why you can't use admin distance with the second default route. It wouldn't be "active" in the routing table.

[KenjiKang]

Toshi-san

Thank you again for your polite and detailed response.
I now understand that for policy-based routing, a routing match is required, not just a destination address exact match, and that changing the priority value, not the AD value, is necessary to reflect the routing in the routing table.

I will check this in our test environment,I'll reach out again to discuss the results.

This has been very helpful. Thank you.
Kenji