docs: Document NAT reflection fix for internal service access

- Pure NAT mode doesn't work when clients/servers on same subnet
- Must use enablenatreflectionhelper for proper source NAT
- Added to Common Gotchas in DECISIONS.md

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

docs/CHANGELOG.md

@@ -127,6 +127,16 @@
 
 - **Port range NAT fix**: OPNsense config.xml requires `<local-port>` to contain only the **starting port** (e.g., `2223`), not the full range (e.g., `2223-2323`). OPNsense maps ranges 1:1 automatically.
 
+### NAT Reflection Fixed
+- **Problem**: Internal clients couldn't access services via public domain names (kavcorp.com)
+- **Root cause**: Pure NAT reflection mode doesn't source-NAT traffic, so return packets bypass OPNsense
+- **Solution**: Enabled `enablenatreflectionhelper` (NAT+proxy mode) instead of pure NAT
+- **Config changes**:
+  - `<enablenatreflectionpurenat>no</enablenatreflectionpurenat>`
+  - `<enablenatreflectionhelper>yes</enablenatreflectionhelper>`
+  - Added `<natreflection>purenat</natreflection>` to HTTP/HTTPS port forward rules
+- Internal and external access now both work via public domain names
+
 ### Verified Working
 - All VLANs (10, 20, 30) receiving DHCP from OPNsense
 - LAN (10.4.2.0/24) receiving DHCP from OPNsense

docs/DECISIONS.md

@@ -192,6 +192,7 @@ cat /tmp/rules.debug
 4. NAT port range rules: `<local-port>` must be just the starting port, not the full range
    - Correct: `<port>2223-2323</port>` with `<local-port>2223</local-port>`
    - Wrong: `<port>2223-2323</port>` with `<local-port>2223-2323</local-port>` (rule will be commented out)
+5. NAT reflection requires `enablenatreflectionhelper` (not just purenat) when clients and servers are on the same subnet - pure NAT doesn't source-NAT so return traffic bypasses OPNsense
 
 ### Reverse Proxy