Possible Issues with 6.0.5-h3

cancel
Showing results for 
Search instead for 
Did you mean: 

Possible Issues with 6.0.5-h3

L4 Transporter

Has anyone discovered any issues with H3? I have an odd issue and am not sure if it has to do with the layer 4 changes in the hotfix to address the evasion issues.

I have upgraded 3 client sites. No issues at 2 of the sites. On the third side, I have an issue. This client has a public web site in a DMZ. The ACL allows it to be directly accessed by the internal network. After the update to H3, you can access the website just fine from across the internet. You cannot access it from the internal network. You can ping the web server just fine. The Traffic log shows Incomplete for the port 80 traffic. Downgrading back to 6.0.5 allows internal users to hit the website in the DMZ just fine.

1 ACCEPTED SOLUTION

Accepted Solutions

L5 Sessionator

SDorsey

By any chance is there any asymmetric flow when internal users try to access server in DMZ, because I just saw this in the release notes of 6.0.5-h3:

If you have asymmetric routes in your network, before upgrading to 6.0.5-h3, use the following command to ensure session continuity:

set deviceconfig setting tcp asymmetric-path bypass

And, if you have attached a zone protection profile, you must also use the  following command:

set network profiles zone-protection-profile <profile-name> asymmetric-path [bypass | global].

Could you also give us the snapshot of the NAT policy that you are using ?

View solution in original post

7 REPLIES 7

L5 Sessionator

SDorsey

By any chance is there any asymmetric flow when internal users try to access server in DMZ, because I just saw this in the release notes of 6.0.5-h3:

If you have asymmetric routes in your network, before upgrading to 6.0.5-h3, use the following command to ensure session continuity:

set deviceconfig setting tcp asymmetric-path bypass

And, if you have attached a zone protection profile, you must also use the  following command:

set network profiles zone-protection-profile <profile-name> asymmetric-path [bypass | global].

Could you also give us the snapshot of the NAT policy that you are using ?

View solution in original post

csharma

Thank you! That fixed it. Apparently the server admins thought it would be okay to dual-home the web server to the internal network. Smiley Sad

If you add a source nat to interface on the original policy from trust to DMZ that will also fix the asymmetrical flow problem and you can leave the syn checking on.  The reason it is asymmetrical is the reply traffic goes out that direct interface.  If you source nat the subnet on the firewall the reply will still go back to the firewall to return to the client instead of the direct interface.

I don't like to remove basic tcp validity checks on firewalls if at all possible.

Steve Puluka BSEET - IP Architect - DQE Communications (Metro Ethernet/ISP)
ACE PanOS 6; ACE PanOS 7; ASE 3.0; PSE 7.0 Foundations & Associate in Platform; Cyber Security; Data Center

Agreed. I have a request in with the sysadmins to see if we can do away with the dual-homed connection altogether since this is really a design anyway.

Hmm, is there something I'm missing? I'm getting invalid syntax when trying to run the command "set deviceconfig setting tcp asymmetric-path bypass" 😕

you need to use that in configure mode.

be sure you are.

admin@PA-VM# set deviceconfig setting tcp asymmetric-path bypass

Ahh, thanks!

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!