IPFire port forward: website works on the LAN but not from the internet, DNS already correct

IPFire port forward: website works on the LAN but not from the internet, DNS is correct

TL;DR

When the name resolves to the right IP and the site answers locally, stop debugging DNS and the web server. Prove whether outside traffic reaches IPFire at all, in this order: compare the red interface address with the address the internet sees (a mismatch, or a red address in the 100.64 range, means the ISP runs carrier-grade NAT and no port forward can ever work until that changes); test from a genuinely external network such as a phone on mobile data, never from the LAN; and read the firewall log during that test for the DNAT line followed by the FORWARDFW line for your rule. The log pair tells you which side of the firewall the request died on.

Verbatim report

The Dynamic DNS update log says successful and the IP address matches on
No-IP and my local outside IP, but connecting to the website is still not
available from outside. The website works fine and is accessible locally,
by the domain name and by the IP address it fails from the internet.

Steps

1. Confirm the red address is really a public address. On the IPFire home page read the IP address shown for the red interface, then compare it with the address an IP-check site reports from a LAN client and with the No-IP dashboard value. Success check: all three agree AND the red address is not in a private or shared range (10.x, 172.16-31.x, 192.168.x, or 100.64-127.x). A red address in the 100.64 range is carrier-grade NAT: the ISP holds the real public address, inbound connections stop at the ISP, and the fix is on the ISP side (a public IP add-on, bridge mode, or an outbound tunnel), not another firewall rule.
2. Test from truly outside. Use a phone with Wi-Fi off, or another external network, and browse to the domain. Testing from the LAN proves nothing about inbound forwarding, because LAN-to-public-IP traffic takes a hairpin path with different rules and often fails for unrelated reasons. Success check: the test request definitely crossed the internet to your red interface.
3. Read the firewall log for that exact test. On IPFire open Logs, Firewall Logs, and look at the minute of the external test for your port. Success check: you can classify the result. A DNAT line followed by a FORWARDFW line means the forward fired and the request reached the internal host, so the failure is on the host (its own firewall, or the service listening on a different interface or port). A DNAT line with no FORWARDFW line means a firewall rule dropped it after translation. No lines at all means the traffic never reached IPFire, which points back to step 1 or to the ISP filtering inbound ports.
4. Rule out ISP port blocking with one alternate port. Temporarily forward a high external port (for example 8443) to the same internal service port and test externally again. Success check: the alternate port answers while the standard port does not, which is the signature of the ISP filtering the standard port; move the service or clear it with the ISP instead of rebuilding rules.
5. Check the internal host last. From the IPFire console or another LAN machine, connect to the service on the internal IP and the exact forwarded port, then check the host's own firewall allows connections from outside the LAN subnet (many host firewalls only allow local addresses, which perfectly matches works-on-LAN, dead-from-internet). Success check: the host accepts a connection whose source address is not on the LAN.

Root cause

A working name and a working local site only prove two of the four links in the chain. The remaining links are addressability (the red interface must hold a genuinely public, non-CGNAT address or inbound traffic has nowhere to arrive) and translation plus admission at the firewall, which is exactly what the DNAT and FORWARDFW log pair records. Most silent port forwards fail at one of those two links, and each has a different owner: the ISP for addressability, the IPFire rule set or the target host for the rest.

Edge cases

• The DDNS entry in IPFire shows red even though updates succeed: the status colour can lag or reflect a check against a stale resolver answer; the log line and the No-IP dashboard are the ground truth, not the colour.
• It worked before an ISP change and broke after: a new ISP is the classic moment CGNAT appears. Redo step 1 before touching any rule.
• IPv6 works while IPv4 does not: the host may be reachable over a native IPv6 prefix while IPv4 sits behind CGNAT; test each protocol separately.
• The external test works from a phone but not from one specific network: that network may block the port or the destination; that is not an IPFire fault.

When to use / not use

Use when a service behind IPFire is reachable locally, the public name resolves to the correct current IP, and external connections still fail. Not for dynamic DNS records that are stale (fix the update first), services that fail on the LAN too (fix the service first), or outbound access problems.

Provenance

Resolved from the public thread: https://community.ipfire.org/t/no-ip-setup-failing/16220

Resolved from the public thread: https://community.ipfire.org/t/no-ip-setup-failing/16220 - OP's No-IP DDNS update logs show successful, the No-IP record matches the firewall's outside IP, a locally hosted website answers on the LAN but not from outside by domain name or by IP; a moderator advised testing from the red side and reading the firewall log for the DNAT then FORWARDFW chain pair; thread open at last activity Oct 16, 2026.