Explorer III

Solved

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

Forum|Forum|8 months ago
September 9, 2025
4 replies
3005 views

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

FortiGate

Best answer by Toshi_Esumi

I'm still not exactly sure what your goal with this set up is.
As @AEK explained, a FGT is a FW, which tracks "sessions" containing initiating direction and returning direction for all traffic. Once the session is initiated by the first packet, the FGT finds the session when packets for returning direction come back. At that time, they go back out to the original incoming interface as long as a proper/matching route still exist. This is also the basic mechanism for anti-spoofing.
Policies and policy routes affect only for the session initiation traffic. The fate of all subsequent traffic and all returning traffic for the same session is decided at the time of the session initiation.

Toshi

AEK

SuperUser

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-routing/ta-p/198575

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

Hope it helps.

AEK

Toshi_Esumi

SuperUser

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

KenjiKangAuthor

Explorer III

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.

topology .jpg

Thank you

Kenji

Toshi_Esumi

SuperUser

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

KenjiKangAuthor

Explorer III

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

SuperUser

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

SuperUser

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-p/189996

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

Riolab23

New Member

Hi Kenji,

Enabling asymroute is a known workaround but not ideal. I'd recommend double-checking your policy-based routing setup and ensuring there are no conflicts with the routing table or session-based routing. Try clearing the policy and reapplying the rules to see if that fixes the issue.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded