Assymmetric routing for UDP

[IMPI]

Hi All,

i know enabling assymetric routing is a bad (bad) thing  :) but we are using an "old" fortinet to migrate between two firewalls. The only job it has to do is routing packet using policy routing to avoid assymmetric routing on the others two firewalls.

Then we enabled assymmetric routing, but it applies only on TCP packets, not UDP. This his a problem with telephony.

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

On this link they say we have to do a policy for UDP, but not which one. We are unable to find how to do.

Any help is appreciated

Thnaks a lot

[Rathan_FTNT]

Hello Good day,

As per the link:

UDP packet is checked by session table regardless of asymmetric routing. Asymmetric routing does not affect UDP packet. In order to allow UDP, a policy is needed to allow it.

id=20085 trace_id=12 func=print_pkt_detail line=4471 msg="vd-root received a packet(proto=17, 1.1.1.2:53->10.255.130.210:1024) from wan. "
id=20085 trace_id=12 func=init_ip_session_common line=4624 msg="allocate a new session-0003db5e"
id=20085 trace_id=12 func=vf_ip4_route_input line=1596 msg="find a route: flags=00000000 gw-10.255.130.210 via dmz"
id=20085 trace_id=12 func=fw_forward_handler line=561 msg="Denied by forward policy check (policy 0)"
68.235893 wan in 1.1.1.2.53 -> 10.255.130.210.1024: udp 52
71.228558 wan in 1.1.1.2.53 -> 10.255.130.210.1024: udp 52
74.228675 wan in 1.1.1.2.53 -> 10.255.130.210.1024: udp 52

This is related to Ipv4 policy , you can create it from source to destination.
Allowing UDP  service

Regards,

Rathan

[IMPI]

Hello Rathan,

Thanks for such a quick reply. I only have to "permit udp source to destination" on this interface... great.

I'll try and tell you

Thanks a lot

[IMPI]

Hi Rathan,

we did not managed to have it work.

In fact :

  - we have a machine with 192.168.XX.1 as IP

  - our firewall has 192.168.XX.254 as IP

  - Fortinet is 192.168.XX.250 as IP. A PBR is done to say : if a packet comes from 192.168.XX.0 and wants to go to "any" then send it to 192.168.XX.254. Quite simple.

Then, as you guess, the returning packet goes directly from firewall (.254) to the machine (.1) avoiding Fortinet, resulting in assymmetric routing.

UDP is for telephony, then we also disable sipalg on fortinet.

As we activated assymmetric routing on fortinet all of that is ok for TCP.

But how to help UDP to be OK ?

On the 192.168.XX interface of Forninet we only have this rule, which is quite large :)

What are we missing ?

Thanks for your help

Cedric

[gfleming]

which firewall is blocking the traffic? it would seem like the Fortigate is allowing the traffic from 192.168.XX.1 and the 192.168.XX.254 firewall is blocking the return path? Can you provide more info on topology and traffic paths and what diagnostics you are doing to confirm where the UDP stream is being blocked?

[IMPI]

Hi Graham,

many thanks for this reply.

In fact this is what we are trying to find : where (and why) is the trafic blocked, and we can not find.

We are still working on this and will come back with more info if we found it.

By the way we are wondering if this is a good idea to migrate piece by piece from one firewall to another, we are facing complicated case, i guess we will migrate all during a week-end, this should be a better solution.

Regards

Cedric

[gfleming · Accepted solution]

IMO a straight cutover is preferable but I do not know the details of your deployment and topology and your use-cases so it is hard to say. If you want to post more details about your topology and traffic flows I can give you a better answer.

It should be easy to figure out where the return traffic is being blocked. Just run a packet cap on the external interfaces of the firewalls and look for the traffic. Or check the logs?

[IMPI]

Thanks Graham for these thoughts :)

While trying to migrate step by step we encouter problems at each step and we can see that futur steps will also be difficults !

This new problem, not really important and maybe easy to solve as you said just helped us realize that the method is not good

Our networks are too embedded then this is complicated to use this method...

Then, as you said, we are now preparing a replacement on a week-end.

We are analysing the actual conf, translate it to the new firewall, doing some step for crucial points.

Thanks a lot for your help