⚠️ WAF not working on your HTTPS site? You're probably missing THIS one setting

One of my biggest NSF troubleshooting lessons came after spending nearly 2 hours chasing a WAF issue... only to realize HTTPS Decryption wasn't enabled.

• Key takeaway: NSF WAF cannot inspect encrypted HTTPS traffic unless HTTPS Decryption is configured and applied. No decryption means the WAF can't see the traffic, leaving HTTPS services uninspected.
  
  

Another surprise I discovered: Antivirus block events don't show up in Security Logs—they're recorded under Application Control Logs. That one definitely caught me off guard the first time!

• What about you? What's an NSF "gotcha" or troubleshooting lesson you learned the hard way? Share your experience below and let's create a helpful list of real-world tips for the community!

Thanks to Share!

My Experience:

NSF "Gotcha" I Learned the Hard Way – NAT Policy Order Matters**

One of the most time-consuming troubleshooting cases I encountered on a Sangfor NSF/NGAF involved a web server that was published to the Internet.

The Issue:
Users from the Internet could not access the web application consistently. Sometimes it worked, sometimes it didn't. Firewall rules looked correct, routing was correct, and the ISP link was healthy.

I checked:
* Security policies
* Server health
* Routing
* ISP connectivity
* WAF policies

Everything appeared normal.

Root Cause:

The actual problem was the "NAT policy order".

A more general NAT rule was matching the traffic before the intended server publishing NAT rule. Because of this, traffic was being translated incorrectly and never reached the correct destination.

Solution:
1. Review all NAT policies from top to bottom.
2. Identify overlapping source/destination conditions.
3. Move the specific server publishing NAT rule above the general NAT rule.
4. Clear existing sessions.
5. Retest connectivity.
Result:

The web application became immediately accessible and remained stable.