Asymmetric Routing and TCP syn check (Pulukas Solution)

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Asymmetric Routing and TCP syn check (Pulukas Solution)

L0 Member

Hi Everyone,

 

Asymmetric Routing and TCP syn verification is a common issue and there were many articles on how to resolve that, basically

1 - To change routing itself and make sure there are no asymmetric routing in the network - best from PA point of view

2 - disable tcp syn verification globally on the firewall - worst for PA 

3 - Disable tcp syn verification per zone in zone sec profile - better then #2, however not perfect.

 

4 - Community member pulukas proposed waaaay better solution. If both interfaces are placed in the same zone, they will be treated as the same area and asymmetry will not be applied within the same zone. This way, the asymmetry protection does not need to be disabled. That is based on how the operating system processes packets and manages flows: the firewall is zone based, which means that for all received packets during the session creation and subsequent packets, a source zone lookup will occur before moving to the next step of matching an existing session.

 

Sad part that it doesnt work for me. So far PA techsupport didnt provide any confirmation that this is a workable solution.

 

Does anyone know successeful implementation of that option #4?

2 REPLIES 2

Cyber Elite
Cyber Elite

@Dimitrus,

I mean the 4th option that was presented isn't wrong, but it would only work in a limited number of asymmetric use-cases. You still have to contend with the fact that you have Asymmetric routing and the TCP syn verification is still going to fail. The solution provided is a 'hacky' way to get the firewall to bypass the TCP syn verification without having to disable it at best, and would be far from a recommended solution. 

You also have the real possibility that PA modifies the way that interzone traffic is managed and your 'solution' is invalidated. Since this isn't supposed to be how asymmetric routing issues are handled I doubt PA would put anything in the release notes to make this stand out, and you would simply be broken during an otherwise routine update. 

 

I think you can get where I'm heading with this; while pulukas's solution would technically work under the right conditions, I would really work to simply address the asymmetric routing or disable TCP syn verification per zone as needed. Follow the approved solutions so that if that behavior ever changes you actually have a chance of being notified about it in the release notes. 

Thanks for a promt response.

I thought that it could be some sort of non-recommended solution or as you say "hacky" solution, especially because of how techsupport reacted on such suggestion.

Its a good point that it may stop working after some routine update, if that would happen it would be a real disaster for us.

 

I would wait for an official PA techsupport response.

 

RE:but it would only work in a limited number of asymmetric use-cases.

do you know which use-cases?

I would like to ask same question to Pulukas, why it works for him but not for me, whats the difference between our setups?

 

Regards,

  • 2149 Views
  • 2 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!