Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
10-10-2014 08:51 PM
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.
10-10-2014 09:00 PM
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 ?
10-10-2014 09:00 PM
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 ?
10-11-2014 05:08 AM
Thank you! That fixed it. Apparently the server admins thought it would be okay to dual-home the web server to the internal network. 
10-11-2014 08:27 AM
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.
10-12-2014 04:50 PM
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.
10-28-2014 04:03 AM
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" 😕
10-28-2014 11:05 AM
you need to use that in configure mode.
be sure you are.
admin@PA-VM# set deviceconfig setting tcp asymmetric-path bypass
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!
