Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
IMPI
New Contributor II

Assymmetric routing for UDP

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

1 Solution
gfleming

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?

Cheers,
Graham

View solution in original post

7 REPLIES 7
Rathan_FTNT
Staff
Staff

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


EMEA TAC Engineer
IMPI
New Contributor II

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
New Contributor II

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 :)

 

Capture.JPG

 

What are we missing ?

 

Thanks for your help

 

Cedric

gfleming
Staff
Staff

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?

Cheers,
Graham
IMPI
New Contributor II

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

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?

Cheers,
Graham
IMPI
New Contributor II

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

 

Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors