CASE STUDY / WEB INFRASTRUCTURE

Publishing an IIS application securely through a reverse proxy.

A public-facing portfolio needed a stable hostname, trusted HTTPS, and controlled exposure without placing the Windows application server directly on the Internet.

Windows IISNo-IPDocker Nginx Proxy ManagerLet's EncryptNAT

THE PROBLEM

Make the site public without exposing management infrastructure.

The IIS application worked internally, but a public deployment needed to survive changing residential IP addresses, support trusted HTTPS, and avoid direct Internet access to IIS management or other homelab services.

THE OUTCOME

One controlled entry point.

External HTTP/HTTPS now terminates at Nginx Proxy Manager. NPM owns the public TLS certificate and forwards approved traffic to IIS over the LAN.

DESIGN

Request path

01ClientHTTPS request

→

02No-IPStable DNS name

→

03Gateway80/443 NAT

→

04NPMTLS + routing

→

05IISPrivate backend

Decision 01

Use DDNS instead of hard-coding a WAN IP

The updater tracks public IPv4 changes automatically so the public hostname remains stable.

Decision 02

Terminate TLS at NPM

IIS stays simple internally while NPM handles certificate issuance, renewal, and HTTPS redirects.

Decision 03

Do not publish IIS directly

The gateway forwards web traffic only to the reverse-proxy host, reducing the public attack surface.

IMPLEMENTATION

Build sequence

DDNS

Created the public hostname and deployed the official No-IP DUC in Docker with restart persistence.

Gateway NAT

Forwarded TCP 80 and 443 to the Nginx Proxy Manager host. Source restriction was intentionally left blank for public access.

Reverse proxy

Mapped the public hostname to the private IIS backend over HTTP on the LAN.

Trusted TLS

Requested a Let's Encrypt certificate in NPM and enabled HTTPS redirection.

Portfolio deployment

Published the static Project Midnight portfolio from the IIS site root.

sanitized-config

Public hostname      projectmidnight.ddns.net
Gateway              TCP 80/443 → reverse proxy
Reverse proxy        HTTPS termination + host routing
Backend              Windows IIS over private LAN
Management           LAN / private remote-access path only

VALIDATION

How I proved each layer worked

✓

IIS direct test

Confirmed the new site rendered successfully from the backend address.

✓

DNS resolution

Verified the public hostname resolved to the current WAN IPv4 address.

✓

External NAT test

Validated public access from outside the home LAN rather than relying only on NAT loopback.

✓

TLS validation

Confirmed NPM presented a certificate for the public hostname rather than an internal CA certificate.

TROUBLESHOOTING

A real fault from the deployment

INC-01

DDNS resolved, IIS worked locally, but public HTTP timed out.

The gateway NAT rule had the home's own public IP entered in the Source IP field. That field filters the remote client addresses allowed to use the rule; it does not identify the gateway's public address.

Root causeIncorrect source-address restriction

FixRemoved the source restriction and re-tested externally

ResultPublic IIS access succeeded

LESSONS LEARNED

What this project demonstrated

Troubleshoot in layers

Prove application, DNS, NAT, proxy, and TLS separately instead of changing everything at once.

Separate public and management paths

A public website does not require public access to the server's administrative interfaces.

Certificates must match the public name

An internal CA certificate can be valid internally while remaining untrusted for a public DDNS hostname.

Document the failure, not just the success

The troubleshooting path demonstrates operational thinking better than a simple technology list.