6.0.5 h3 explanation

[PanIst]

Hi all

could someone give an example about 6.0.5 h3 asymmetric bypass.When to enable that ?

how that asymmetric trafic works with 6.0.5 but not with 6.0.5-h3 ? That is the thing I'm confused about.

[ssharma]

Hi PanIst,

You should only enable bypass if you have asymmetric traffic in your environment. If you don't have it then you need not worry about it.

These modification were in place as a response to fix issued after NSS report.

Update on Recently Released 2014 NSS Next-Generation Firewall Comparative Analysis - Palo Alto Netwo...

Hope this helps. Thank you.

[PanIst]

we know that but it is not clear.why it works with 6.0.5 although asymmetric is not enabled.

[ssharma]

As the part of the fix, additional enforcement were included with respect to reassembly, acknowledgement for asymmetric traffic. Due to these changes, now PANOS requires user to configure those commands, which was not the case prior to 6.0.5. Thank you.

[SDorsey]

All correct. Basically with the new anti-packet-evasion protections in 605-h3, it cannot properly reassemble the fragmented packets if the traffic is asymmetric since it only sees half the traffic.

[PanIst]

Thank you for answers.I understand the idea.But I just need an example of an asymmetric traffic that works with 6.0.5 but not with 6.0.5 h3(without enabling)

Can someone give an example for that.

I found this  Re: Possible Issues with 6.0.5-h3 but example is not clear.

[SDorsey]

The web server was placed in a DMZ but the web server was dual homed.. i.e. the web server had two physical interfaces. One was connected to the DMZ vlan and the other was connected to the internal network vlan. So when internal workstations made a request to the web server in the DMZ, the initial request would go through the firewall to the web server.. but when the web server responded to that request, it would respond directly to the internal network since it had an interface physically connected to the internal network.

So the firewall would only see traffic from the client to the server. It would not see the server to client response.

[PanIst]

ok so workstation sends syn and syn-ack is not passing through Firewall.that is Ok.

Ack will be sent again through fiewall.it will be dropped if bypass is not allowed.

But how does this work with 6.0.5 ? why no drop ?

[SDorsey]

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.

[ssharma · Accepted solution]

Hi Panlst,

I did some additional look up. There are 2 sets of different command

# set deviceconfig setting session tcp-reject-non-syn no |yes    <------- asymmetric routing

# set deviceconfig setting tcp asymmetric-path bypass | drop  <--------- asymmetric flow of packets

1st command would bypass non-syn packets. That is if configured "no" firewall is allow non-syn packets. Like SYN-ACK received before SYN or FIN received for unknown tcp flow. Under traffic logs you will see non-syn as application. If you have asymmetric environment pre 6.0.5-h3, command #1  would have been enough for normal traffic flow. That means you did not have to configure 2nd command, which deals with tcp windowing and sequence number check for your asymmetric flows for the packets.

But with changes and improvement made with 6.0.5-h3, if you have asymmetric traffic in your environment and you don't configure command # 2, it is pretty much guaranteed that it will break your traffic. Now firewall explicitly requires that command to be configured for asymmetric environment. That was one of the evasion technique used to evade IPS of firewall as mentioned in link in previous comment and the fix requires either to enforce check of command # 2 or completely bypass it. Hope this helps. Thank you.

[sebastian]

Hi all,

we had this issue after upgrading to 6.0.5-h3 with our Citrix Netscaler Loadbalancer.

There is a feature called MBF (MAC based Forwarding) which was turned off on our Citrix Netscaler.

If MBF is disabled, the return path is determined by a route lookup, or is sent to the default route if no specific route exists.

With MBF instead it caches the MAC address of the uplink router that forwarded the client request to the appliance.

So after turning on the MBF on the Netscaler the SYN/ACK packet went to the PA instead direct to the client via a Netscaler Interface.