HAS — Hegarty Advanced Solutions
← All guides

HAS guides / Networking / Free to read

Give every service
a clear path.

Names, addresses, ports, and access rules do different jobs. Understanding the path from a client to an application makes a homelab easier to operate—and much easier to troubleshoot.

Draw the path before changing the network

Start with one service and one client. Write down how a request reaches the application: the client resolves a name, connects to an address and port, possibly passes through a reverse proxy, and reaches the service. Each stage can work while a later stage fails.

Illustrative web-service path

Client
  → DNS lookup
  → server address, TCP port 443
  → TLS and reverse proxy
  → application on its internal network

DNS participates in finding the address; ordinary application traffic does not pass through the DNS server. A reverse proxy is also optional. A small local service can be reached directly if that matches its documented access model.

Keep a short service record: hostname, host address, listening port, proxy route if present, allowed clients, and administrator. This gives you a known design to compare with observed behaviour rather than changing several settings until a page loads.

Make important addresses predictable

A DHCP reservation can keep a host at a predictable address while leaving address assignment under the router or DHCP server’s control. If you set a static address on the host instead, coordinate it with the DHCP pool and record the gateway, prefix or subnet mask, and DNS servers. Avoid choosing an address merely because it appears unused today.

A container address is a separate concern. Addresses on container networks can change when containers are recreated. Where the platform supports it, connect related services using its internal service names instead of hard-coding temporary container IPs.

Loopback is local to the network namespace using it. Inside a typical container, 127.0.0.1 refers to that container, not another service or the host. A proxy in one container normally needs a reachable service name and port on a shared network to reach another container.

Use service names deliberately

A name such as notes.home.arpa is easier to remember than an address. The home.arpa domain is reserved for residential home networks; your local resolver must still be configured to answer for the names you use. Avoid treating .local as an arbitrary private DNS suffix, because it has a separate role in multicast DNS.

Ordinary A and AAAA records map names to IPv4 and IPv6 addresses. They do not tell a browser to replace the normal HTTPS port with an application’s custom port. For a browser-friendly name without a port suffix, you usually need a service listening on the expected port or an appropriate reverse proxy.

Check which resolver a client actually uses. Guest-network settings, a VPN, manually configured DNS, or browser-level encrypted DNS can cause different clients to receive different answers. A local record in your router will not help a client that bypasses that resolver.

If you use a domain you own instead, document which names resolve privately and which are public. A public DNS record does not itself make a private address reachable from the internet.

Keep proxying, encryption, and authentication separate

A reverse proxy can route requests for several hostnames to different applications. It may terminate TLS, but it is not automatically an authentication layer. A successfully encrypted connection can still lead to a publicly accessible, unauthenticated application.

The certificate must match the name clients use, remain valid, and chain to an authority those clients trust. Private names such as home.arpa require an appropriate private trust arrangement rather than a normal publicly trusted certificate for that name. Do not train users to bypass certificate warnings as a routine setup step.

Check the connection from the proxy to the application as well. Decide whether that path needs encryption and whether the backend can be reached directly by clients that should use the proxy. A protected front door is not sufficient if an exposed backend bypasses it.

Some applications need an explicit public URL or trusted-proxy configuration for redirects, forwarded headers, and cookies. Use the application’s documentation; do not broadly trust every source of forwarded headers to make a warning disappear.

Write access rules as allowed conversations

Before adding VLANs, list the conversations the network must support. For example: household clients reach a document service; an administrator reaches the host’s management interface; guest devices reach the internet but not management services.

Client network
Permit the application access people need. This does not automatically require access to the database or hypervisor behind the application.
Device network
Identify the controller, discovery, DNS, time, and vendor-service connections devices require. Isolation can break discovery across subnets, so test the intended workflow.
Management network
Restrict administration to authorised devices and accounts. Keep a documented recovery path if a rule change locks out normal access.

VLANs divide layer-2 networks; routing and firewall policies determine traffic between them. Apply equivalent intent to IPv4 and IPv6. Test both permitted access and expected denial from devices and networks you control.

For remote access, an authenticated VPN or private-access service may avoid exposing individual management ports. It still needs updates, access control, and a recovery plan. Test from a genuinely external connection; a working connection from inside the LAN does not demonstrate external reachability.

Troubleshoot one layer at a time

  1. Name: Does the affected client resolve the service to the expected address? Compare its configured resolver with a working client.
  2. Path: Is the client on the intended network, with a route to the destination? Check changes to VPNs, gateways, and access rules.
  3. Listener: Is the service listening on the expected address and port? A loopback-only listener will not accept a direct LAN connection.
  4. TLS: Does the certificate match the requested name, and does the client trust it? Check the client’s clock as well.
  5. Proxy: Is the hostname routed to the correct backend, and can the proxy reach that backend?
  6. Application: Are authentication and dependencies working? A proxy error and an application login failure call for different investigations.

A successful ping does not prove an application is available, and a failed ping does not always mean the host is down. Use the service’s real protocol and review relevant logs, removing credentials and personal information before sharing them.

Keep with your network diagram

A service-access checklist

  • Address: Important host addresses are reserved or assigned without conflicting with DHCP.
  • Name: Intended clients use a resolver that knows the service’s hostname.
  • Port: The expected listener and any proxy-to-backend connection are documented.
  • Trust: Certificates match the service names, and clients trust the intended authority.
  • Boundary: Allowed clients can connect; unintended networks cannot bypass the controls.
  • Remote access: External access is intentional, authenticated, and tested separately from LAN access.
  • Recovery: Configuration and a way back from a bad network change are available without the affected service.

Reference documentation