PA firewall can't properly reassemble fragmented packets if the traffic is asymmetric

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

PA firewall can't properly reassemble fragmented packets if the traffic is asymmetric

L0 Member

Hi PA Expert,

 

We have a network environment that have an asymmetric routing and fragmented traffics.

 

Model: PA5060

PANOS: 8.0.6-h3

Method: vwire mode

No security profiles applied, no zone protection, no QOS, just single security policy that allow all.

 

Already applied this setting to allow asymmetric:

 

set deviceconfig setting session tcp-reject-non-syn no

set deviceconfig setting tcp asymmetric-path bypass

 

All internet traffics are backhauled from this branch to HQ using 2 different ISP.

 

ISP1: MTU 1500

ISP2: MTU 1380

 

** we can't change (not allowed to change) MTU size on ISP2.

** also, we not allowed to change the network design.

 

Since this is a fully-converged network (ospf) traffic will go to any ISP but the 'return route' from HQ will not follow the same way the traffic is originating.

HQ will load balance the traffic, so means that the traffic will go back to ISP1 or ISP2.

 

When the traffic coming from ISP2 (mtu 1380), i know the traffic will be fragmented. But, when the 'fragmented packet' reached to Palo Alto, look like PA firewall can't properly reassemble the fragmented packets.

This will cause all TCP related traffic such as http can't load. The browser will keep loading. User complaining slowness issue.

But, when i bypass PA, all will back to normal.

 

To prove that MTU size is the issue here, We have try to force HQ to set the 'return route' using ISP1 (mtu 1500) only.

The PA is still there (intercepting the traffic) and the results is.....no issue occurred.  All webpage load successfully.

 

So, the BIGGEST question is....yes we know the MTU size on ISP2 will cause packet to be fragmented.

There is no issue at all for all traffics.. No slowness issue. All application can load without issue.

But, why after intercepting with 'PALO ALTO FIREWALL'  this issue will happen?

 

Does this issue caused by this statement: ?

 

Because H3 added new anti-packet-evasion techniques.

 NSS labs discovered they could use certain fragmentation attacks to completely bypass the PAN IPS. So H3 was released which introduces protections against these which require symmetric traffic for the PAN to be able to reassemble the fragments.

 
So, does that mean that there will be issue if trying to assemble packet in "Asymmetric" traffic?
 
So, we need your advise how we can solve this issue? Any workaround or settings that must be done on PA to properly reassemble fragmented packets?
 
 
Thank You!

 

 

1 REPLY 1

Cyber Elite
Cyber Elite

disabling protections and sanity checks should not be the route to take, as this will render yoiur firewall less effective:

 

Do you happen to have a cluster? you could consider HA in Active/Active to tackle assymetry

 

If you enable layer3 mode, you can also force the MTU to be lower for both links (by adjusting the mss header), this would prevent fragmentation:

 

Enabling 'Adjust TCP MSS' will inject a new mss header in the tcp packet, reducing MTU on the returning packetsEnabling 'Adjust TCP MSS' will inject a new mss header in the tcp packet, reducing MTU on the returning packets

also, if you're able to converge both links before they reach the firewall, you wouldn't have an assymetry issue either (you could aggregate both links into a single vwire)

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization
  • 4832 Views
  • 1 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!