The Portal That Only Works From Outside

This is a missing path, not a NAT bug. The only policy that matches 443 to 203.0.113.10 is External to DMZ. Traffic from 10.10.10.0/24 arriving at the firewall is Trusted-sourced, matches no inbound policy, and is dropped - from the user's point of view, a timeout.

Options:

1. Hairpin / NAT loopback policy. Add a Trusted to 203.0.113.10 policy on 443 carrying the same port-forward/NAT action. It works, but: internal traffic is inspected as if it were internet traffic, logs show confusing translated sources, and every internal connection consumes firewall sessions. It also quietly depends on the external path staying healthy.
2. Split DNS (recommended). Add an internal zone on the AD DNS servers resolving portal.example.com to 192.168.50.20, and a Trusted to DMZ policy for 443 to that server. Traffic stays inside, is inspected once, is not dependent on the external IP, and survives an ISP change. Cost: one more record to maintain, and any device hardcoding the public name or IP still fails.
3. Do nothing for staff, tell them to use the internal name. Cheapest, but users will keep typing the public name.

Recommended: split DNS as the primary fix, plus the hairpin policy as a fallback for devices that hardcode the public hostname (embedded clients, kiosks, some mobile app configs). Build both, and document which one the helpdesk should point users at.

Note the behaviour difference: with a 1-to-1 NAT (rather than a port forward) the loopback behaves differently, so if you convert later, retest from inside.

Steps:

1. Confirm 203.0.113.11 is genuinely usable - it must be inside the ISP's routed /29 to you, not a neighbouring allocation. Check the usable range of the /29 (typically .9 to .14 for .8/29) and confirm the ISP routes the whole block to the Firebox.
2. Add the secondary IP (203.0.113.11) to eth0 in the external interface configuration; the Firebox will answer ARP for it on that interface.
3. Create a policy-based SNAT action: original source = the web server's addresses (192.168.50.20), translated source = 203.0.113.11. Do not use an IP-header SNAT or interface SNAT here; you need a source-specific rule.
4. Attach that SNAT action to the DMZ to External policy that covers the vendor's destinations (use an FQDN/IP set rather than 'any' so you are not sending all DMZ traffic out as .11).

Traps:

• Policy order again. Only the first matching policy's SNAT action applies. If a general DMZ to External policy sits above your vendor policy, the SNAT never fires. Move the vendor policy up.
• Multi-WAN interaction. If the policy uses an SD-WAN action that can choose eth1, the source address .11 no longer exists on the egress interface and the vendor sees a different IP anyway. Pin the policy to eth0.
• Return path. The vendor replies to .11, which lives on eth0, so this is fine - but confirm with a quick test, because asymmetric return paths show up as one-way TCP handshakes.
• Reporting. Traffic reports will now show traffic attributed to .11; make sure whoever reads the reports knows why.

Do not disable deep inspection on the DMZ outbound policy as a whole - that is the easy mistake, and it removes visibility for every other DMZ host.

Use a narrower path for the vendor traffic:

1. Build an explicit destination object/alias containing the vendor's hostnames and their resolved addresses (an FQDN-based alias if the Fireware version supports dynamic resolution, otherwise a static IP set maintained as the vendor publishes them).
2. Create a policy above the general DMZ to External proxy policy for the web server to that destination set, on 443. Make it a packet filter, or an HTTPS proxy with content inspection / TLS break-out disabled for that traffic - whichever your Fireware version exposes most cleanly; verify the exact option in the UI rather than assuming.
3. Keep the general DMZ to External policy below it using the full HTTPS proxy with inspection, Gateway AntiVirus and APT Blocker so everything else is still inspected.
4. Attach the .11 SNAT action to whichever policy actually carries the vendor traffic (normally the narrow one), and pin it to eth0.

Reasoning to record for the next admin: certificate pinning means the client validates the vendor's certificate chain, and breaking TLS replaces it with the firewall's CA - so any bypass must be destination-scoped, ordered above the inspecting policy, and accompanied by a compensating control (the vendor set is a small, known allow-list, and you can add IPS/Botnet detection at packet level, which does not touch the certificate).

Confirm the vendor's address list is stable; if it changes without notice, updates break again and it will look like a firewall fault.