Skip to main content
IMPI
IMPI
Explorer
September 5, 2022
Solved

Assymmetric routing for UDP

  • September 5, 2022
  • 4 replies
  • 8499 views

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

 

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

Best answer by 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?

4 replies

Rathan_FTNT
Staff
Rathan_FTNT
Staff
September 5, 2022

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
    IMPIAuthor
    Explorer
    September 5, 2022

    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
    IMPIAuthor
    Explorer
    September 9, 2022

    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
    gfleming
    Staff
    September 9, 2022

    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
      IMPIAuthor
      Explorer
      September 12, 2022

      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
      Staff
      gflemingAnswer
      Staff
      September 12, 2022

      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?

        Terms & ConditionsAccessibility statement