Port forwarding and the home-router DMZ

An inbound Internet connection arrives at the router's public address. A forwarding rule matches an external port and protocol, then rewrites the destination to an internal address and port. The service must be listening there and the Saphira firewall must permit it.

Internet → 203.0.113.25:443/tcp
          router forwarding rule
        → 192.168.1.50:443/tcp
          Saphira nftables
        → webDragon/HAProxy

• Internal/LAN IP: the fixed address of the receiving host, for example 192.168.1.50.
• External/WAN port: the port Internet clients use, for example 443.
• Internal port: the port the service actually listens on; it may differ from the external port.
• Protocol: TCP, UDP, or both. Do not choose both without a reason.
• Source address: an optional allow-list of remote addresses or networks.
• Description: identify the service and owner.
• Enable/disable: save a rule without making it active, or activate it when ready.

Vendors may call this NAT, Port Forwarding, Virtual Server, or an application rule. Read the field labels rather than relying on the menu name.

Reserve 192.168.1.50 for Saphira. Create TCP external 443 to internal 192.168.1.50 port 443, enable it, and save. The expected result is that a client on the Internet reaches the HTTPS listener, while an unlisted port remains closed. Repeat for TCP 25 only when MailDragon and your ISP policy support direct mail.

Name:          webDragon HTTPS
External port: 443
Internal IP:   192.168.1.50
Internal port: 443
Protocol:      TCP
Source:        any (or a deliberate allow-list)
Enabled:       yes

On many consumer routers, DMZ Host means: forward unsolicited inbound IPv4 traffic that did not match another rule to one chosen LAN address. It does not create a separate protected network, inspect every application, or replace the host firewall. The chosen Saphira machine becomes responsible for rejecting everything nftables does not allow.

Internet
    ↓
Home router public IPv4
    ↓
DMZ / Exposed Host
    ↓
192.168.1.50
    ↓
Saphira firewall
    ↓
Services actually allowed by nftables

IPv6 may already route directly from the Internet to Saphira or to a server VLAN. An IPv4 DMZ or port-forward rule normally does not control that IPv6 traffic. Find the IPv6 Firewall menu and create equivalent, intentionally limited rules, or let the upstream router filter inbound IPv6 while Saphira enforces its own policy too.

A connection that works on LAN but not from the Internet has crossed more boundaries than a LAN test. Do not change every setting at once. Start at the service and move outward; stop when the evidence no longer matches the expected path. This preserves the one change that actually fixes the issue.

• A LAN test using the public name can succeed through NAT loopback/hairpin support even when the Internet path is broken—or fail even when the Internet path is correct. It is not a substitute for an external test.
• If the server's DHCP address changed, an old forwarding rule can send traffic to a different device. Use a reservation and compare the router rule target with ip addr on Saphira.
• If IPv4 is CGNATed, repeatedly changing local forward rules cannot make unsolicited IPv4 arrive. Switch to the IPv6 or provider/tunnel decision rather than continuing to debug the LAN.
• If IPv6 fails independently, inspect RA/prefix and IPv6 firewall policy. Do not add an IPv4 DMZ rule and expect it to alter an IPv6 route.

• Follow the full explicit port-forward procedure
• Use consumer DMZ Host only with a prepared edge firewall
• Continue with boundary-by-boundary diagnostics