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.
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
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
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?
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
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
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
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?
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
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?
Created on 09-20-2022 01:28 AM Edited on 09-20-2022 01:30 AM
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
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1547 | |
1031 | |
749 | |
443 | |
210 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.