Using Home Broadband without Public IP + CDNfly to Host a Website
Ops

Using Home Broadband without Public IP + CDNfly to Host a Website

KaguraiYoRoy
09-03-2025 / 0 Comments / 232 Views / Checking if indexed by search engines...

Introduction

As is well known, hosting a website with home broadband usually requires a public IP address. However, in certain cases without a public IP, it is possible to expose an HTTP port on the carrier's exit IP for external connections through special methods, i.e., NAT penetration (this is different from FRP, ngrok, or Oray-like intranet penetration, as it does not require a server).

Prerequisites

Download NatTypeTester to check your NAT type. Please refer to relevant materials for details on NAT types.

Ensure your network environment meets the following conditions:

  1. Under RFC3489, the NAT type must be Full Cone.
  2. Under RFC5780, the TCP mapping behavior must be EndpointIndependent.

If UDPBlocked appears, change the server.

Methods to Improve NAT Type

  1. Reduce the number of router layers. If using modem dial-up, connect the device directly under the modem. For multi-layer routing, connect the device directly under the top router.
  2. Enable UPnP on the router.
  3. Set the DMZ host to the server IP.

Getting Started

We use Lucky as the NAT penetration tool, deployed on TrueNAS via Docker Compose. TrueNAS locally has port 9080 open for HTTP.

Deploying a web server is not covered in this article.

Installing Lucky

Follow the official guide and write a Docker Compose file:

services:
  lucky:
    image: gdy666/lucky
    network_mode: host
    restart: always
    volumes:
      - /mnt/systemdata/DockerData/lucky/luckyconf:/goodluck

Modify the persistent storage path to your own. Note: network_mode must be host. It can be deployed without host, but that is not discussed here.

After installation, open http://[YourIP]:16601. The default username is 666 and password is 666. After logging in, modify security settings as required.

Configuring Penetration

Open STUN Intranet Penetration on the left side of the Lucky page and create a penetration rule.
Fill in the local port with any port (ensure it does not conflict with local services), and the target address and port with the IP and port of the web service on the intranet.

After completing the above configuration, choose one of the following penetration methods:

If no issues arise, you should see the address and port assigned by the carrier's public exit IP. If you can access it from outside or if an itdog test shows green, the penetration is successful.

Configuring CDNfly WebHook

Since the public IP and port obtained this way are dynamic, a service similar to DDNS is needed to fix the access method. You can use CloudFlare Workers for redirection or use a CDN to dynamically modify the origin IP and port. I use the latter.

My CDN uses the cdnfly management system. Refer to the cdnfly official documentation for API request methods.

When editing the STUN intranet penetration rule, open Webhook below and check Only trigger Webhook when the address is different from the last time. Fill in the API address: https://[your-cdn-domain]/v1/sites, request method PUT; request headers include api-key and api-secret (can be found in the CDNfly backend):

api-key: Your API Key
api-secret: Your API Secret

The request body uses JSON format to construct the payload according to the cdnfly official documentation (change the id field to your website id; if multiple websites, copy and modify accordingly):

[
    {
        "id": 114,
        "backend_http_port": #{port},
        "backend": [
            {
                "addr": "#{ip}",
                "weight": 1,
                "state": "up"
            }
        ]
    },
    {
        "id": 514,
        "backend_http_port": #{port},
        "backend": [
            {
                "addr": "#{ip}",
                "weight": 1,
                "state": "up"
            }
        ]
    }
]

Where #{ip} and #{port} are parameters provided by Lucky, representing the obtained public IP and port.

Save, and if no issues, the CDN's corresponding website's origin address and port will be automatically changed to the carrier's public IP and port.

Security Considerations

I recommend using HTTPS penetration because HTTP is plain text and less secure. If using HTTPS, change backend_http_port to backend_https_port in the CDN API call payload and switch to HTTPS origin in the CDN.


Reference Articles:

1

Comments (0)

Cancel