Now that we have a couple of services up and running for our home lab, it is time we start setting up everything so that we can access our services from outside of the local area network. This will enable us to access some apps and services when we are not at home, which can be a great gain for our setup. We have two options. The first is setting up an external address to get to our home network and then use one of our services to redirect traffic. The second is setting up a VPN server on our home network so that we can access our entire network as if we are connected to it, even when we are not. Today we will look at the first option as it is a lot easier and quicker to set up. We also have everything ready to go for the setup.
We will need to access our home router, so please check how to access the settings of your router. This normally involves going to a web address, normally something like http://10.0.0.1, http://192.168.0.1 or http://192.168.1.1 . Most modern routers also have some sort of smartphone app connected to it where one can set up all the settings. We are going to use our TP-Link Deco BE65 Mesh Network setup at home to set up the forwarding.
Step 1: Set up External DNS
If you have not had a look at our Dynamic DNS article, let's refresh what a Dynamic DNS is. Dynamic DNS (DDNS) is a service that automatically updates the IP address associated with a domain name when a device's public IP changes. This is especially useful for users with internet connections that have dynamic IPs, meaning their IP address can change periodically. With DDNS, you can maintain a consistent hostname (e.g., myhome.ddns.net) that always points to your current IP, making it easier to remotely access devices like security cameras, home servers, or VPNs without needing to check and update the IP manually.
From your router's firmware we are looking for two things. Firstly the setup of a Dynamic DNS (DynDNS, DDNS) setting. This can be supplier specific, or use a general service like dyndns.org. Set up a name you can remember and enter it in the relevant section.
Step 2: Port Forwarding
Secondly, we need to port forward from an external source, to an internal source. Look for Port Forwarding or Virtual Server settings. Do not use the exposed-host/DMZ option: it can forward unsolicited traffic broadly to the device. Create only the specific port rules needed for the service, with authentication, updates and HTTPS planned before public use. Port forwarding is a router setting that directs incoming traffic on specific ports to designated devices on your local network. A virtual server is essentially another term for port forwarding, typically used to group or simplify rules for directing traffic to internal servers. A consumer router's DMZ or exposed-host feature typically forwards unsolicited incoming traffic not already handled by other rules to one chosen LAN device. Exact behaviour depends on the router. This broad exposure does not mean the device's own firewall, authentication or every router control disappears, but it exposes far more than the specific web service we need. Do not use that option for this setup.
Before enabling a public forwarding rule: The screenshots record the original WordPress-first routing test; newer router menus may differ. Check the following before applying it:
- Update WordPress, its plugins and the underlying system, use a strong administrator password and keep a recoverable backup.
- Confirm the destination is your actual WordPress guest and keep its address stable. Do not forward Proxmox, database or other management ports for this website test.
- Use only the required TCP rules. Keep DMZ disabled. The pictured 443 rule does not make an HTTP-only site ready for HTTPS; enable public HTTPS traffic when its service and certificate are configured.
- Use a harmless page for the interim HTTP test, without logins or personal data. Complete and verify the HTTPS stage in Part 12 before normal public use. Test from mobile data with Wi-Fi off, then disable any temporary rule you no longer need.
The original example shows forwarding TCP port 80 (HTTP) and TCP port 443 (HTTPS) to a specific IP. Port 443 needs an actual HTTPS service and certificate at the destination; a forwarding rule alone does not provide encryption. In the example below, we are using our WordPress site's IP address.
For the temporary page-only HTTP test, you should be able to go to your DynDNS address, in our case techdecode.tplinkdns.com, and see the WordPress site. Do not sign in or submit sensitive data until HTTPS is configured and verified. It might not look correct as the site was set up to be wordpress.local, but we are now accessing it with techdecode.tplinkdns.com.
Optional After the Walkthrough: Public Reachability and the Next Routing Step
This article demonstrates forwarding to WordPress first. Part 9 moves the entry point to NGINX so one public address can route requests to the appropriate service. Keep that order while following the screenshots. Before changing the forwarding destination, record the working rule and confirm that the new NGINX address is stable.
Dynamic DNS changes a hostname's address record; it does not open a firewall or supply a public address when the ISP uses carrier-grade NAT. Compare the router's WAN address with the address seen from outside. A private or shared-range WAN address, including 100.64.0.0/10, suggests an upstream NAT arrangement. A mismatch alone may also be caused by another router you control, so trace the equipment before assuming the ISP is responsible.
Test from a separate external connection, such as mobile data with Wi-Fi turned off. Failure from inside the house can be caused by missing NAT loopback even when external access works. A timeout can also mean a stopped service, incorrect forwarding destination, host firewall or ISP filtering. Check those layers separately rather than treating one symptom as proof of CGNAT.
If the ISP cannot provide suitable inbound connectivity, choose an access method that explicitly supports that network arrangement. A self-hosted WireGuard server still needs a reachable endpoint; simply installing it behind the same CGNAT does not create one. Overlay services can use outbound connections and relay paths, with their own requirements and trade-offs.
Avoid a consumer router's exposed-host/DMZ shortcut for this setup. Its exact behaviour depends on the router, but it commonly forwards unsolicited traffic much more broadly than the one service being tested. Forward only the ports you need and verify their destination. HTTPS is introduced later in Part 12; do not treat the temporary public HTTP demonstration as a finished login or publishing setup.
Further reading: RFC 6598 shared address space, Tailscale connection types.
Router references: TP-Link DMZ behaviour, Deco port-forwarding settings.
Conclusion
Although this was a short article that might not seem like it accomplished much, we have now set up connectivity from outside of our home network. We will now look at getting our reverse proxy, NGINX, into the mix to have more granular control over the services and addresses we provide. This will also enable us to have other services up and running from outside the home network and even some game servers. This completes an initial reachability test. HTTPS and the application's security and maintenance checks still need to be completed before treating the service as ready for public use.
