RTFM · Networking

Port forwarding without router screenshots

A port-forward rule maps one deliberately chosen public IPv4 connection to one deliberately chosen private host. It is a delivery rule, not a firewall replacement.

What actually happens

A person on the Internet connects to the public IPv4 address of the home router. The router compares the connection with its forwarding rules. A matching rule replaces the destination with the reserved LAN address and port of Saphira. Saphira's own firewall then decides whether the service receives it. If any one of those steps is absent, the service is not reachable.

One HTTPS forwarding path

Internet client
    │ TCP 443 to 203.0.113.25
    ▼
Home router: NAT / Port Forwarding / Virtual Server
    │ TCP 443 to 192.168.1.50
    ▼
Saphira nftables input policy
    │ allow TCP 443
    ▼
HAProxy or webDragon listener

Vendor labels differ. Look for Port Forwarding, NAT, Virtual Server, Port Mapping, Application Rule, Firewall, or Advanced. The label is less important than the fields and the resulting traffic path.

Know every field before entering it

Common router fields
Field	Meaning	HTTPS example
Internal or LAN IP	The fixed destination inside your network.	192.168.1.50
External or WAN port	The port Internet clients use at the public router address.	443
Internal port	The port the Saphira listener actually uses.	443
Protocol	TCP, UDP, or both. Pick the protocol the service uses.	TCP
Source address	Optional Internet-side allow-list. Blank or any means any source.	Any for a public website
Enable	Whether the saved rule is active.	Enabled only after host firewall is ready

Do not choose TCP/UDP 'both' as a habit. HTTPS is TCP. A WireGuard listener is UDP. Opening both expands the reachable surface without helping a service that only speaks one protocol.

Complete HTTPS example

1. Reserve the Saphira address
In the router's DHCP or LAN reservation screen, bind Saphira's hardware address to 192.168.1.50. A forwarding rule fails after a lease change if it points at the old address.
2. Prepare Saphira before exposure
Install and configure webDragon or HAProxy, validate the configuration, and permit only TCP 443 in nftables. Confirm ss -lntp shows the intended local listener.
3. Create the router rule
Name it webDragon HTTPS. Set external port 443, internal address 192.168.1.50, internal port 443, protocol TCP, and enable it.
4. Test from an independent network
Use a mobile hotspot or a remote host you control. A test from the same Wi-Fi can be misleading because NAT loopback is optional on consumer routers.

Worked rule and evidence

Name:          webDragon HTTPS
External port: 443
Internal IP:   192.168.1.50
Internal port: 443
Protocol:      TCP
Source:        any
Enabled:       yes

# On Saphira, before the external test.
ss -lntp '( sport = :443 )'
nft list ruleset

# From a real external network.
curl -v https://www.example.test/

Prove it works: The rule has one job

The public hostname reaches the expected HTTPS certificate and page from outside, while a deliberately unforwarded port remains unreachable. Test the denied case as well as the success case.

Failures that look like a bad rule

The server works at 192.168.1.50 but not externally: check the Saphira firewall, router WAN address, and whether the rule is enabled before changing the application.
The router WAN address is private or in 100.64.0.0/10: this may be CGNAT. A port-forward rule cannot create an Internet route the ISP has not given you.
There are two routers: this is double NAT. The outer router must forward to the inner router, then the inner router to Saphira, or the outer device must be put in a deliberately understood bridge/forwarding mode.
The test works on Wi-Fi but not mobile data: local NAT loopback is not evidence of Internet reachability. Test from a network that does not use the same router.
IPv4 works but IPv6 behaves differently: IPv4 forwarding rules usually do not govern IPv6. Inspect the router IPv6 firewall and Saphira's IPv6 nftables policy separately.