Skip to content

Publish Multiple Websites on One Public IP

This guide adapts the old "multiple servers on one public IP" pattern for current t1n1wall deployments.

Use one frontend reverse proxy for ports 80 and 443, then route by hostname.

  • Public IP -> t1n1wall NAT/port-forward -> reverse proxy host
  • Reverse proxy host routes site-a.example.com, site-b.example.com, etc. to internal services
  • DNS for all site hostnames points to the same public IP

This is cleaner than exposing alternate ports (:81, :82) to users.

When to use legacy alternate-port redirects

Use this only when you cannot run a reverse proxy and must keep separate servers on different external ports.

Example pattern:

  • www.example.com on external 80
  • www.example.net on external 81
  • www.example.org on external 82

Then a web server on port 80 can redirect users by hostname to the alternate-port URLs.

t1n1wall configuration steps

  1. Assign stable internal IPs to each web server.
  2. Create required NAT port forwards.
  3. Recommended: 80 and 443 to one reverse proxy host.
  4. Legacy: 80, 81, 82 (or similar) to different backend hosts.
  5. Ensure matching firewall allow rules exist for each published port.
  6. Keep management services off WAN.
  7. Test from an external network path.

Apache redirect example (legacy pattern)

Use this only on the server handling public port 80 when doing hostname-to-port redirects:

<VirtualHost *:80>
    ServerName www.example.com
    DocumentRoot /var/www/example-com
</VirtualHost>

<VirtualHost *:80>
    ServerName www.example.net
    Redirect / http://www.example.net:81/
</VirtualHost>

<VirtualHost *:80>
    ServerName www.example.org
    Redirect / http://www.example.org:82/
</VirtualHost>

Security and operations notes

  • Prefer TLS (443) and valid certificates for every hostname.
  • Prefer reverse proxy + host routing over public alternate ports.
  • Minimize exposed ports and document each exposure.
  • Keep backups of NAT/firewall config before changes.

Validation checklist

  1. DNS hostnames resolve to the intended public IP.
  2. External tests reach the correct backend for each hostname.
  3. Logs show expected NAT translation and firewall decisions.
  4. No unintended services are exposed on WAN.