Marko Apfel
Homelab

Adding a new machine or service to the homelab

A practical checklist for integrating a new machine or service into my homelab using Sophos XG, Technitium DNS, and Caddy.

5 min read

Adding a new machine or service to the homelab usually requires changes in several places. To avoid forgetting one of them, I use the following sequence as a checklist.

The main components involved are:

  • Sophos XG for DHCP, network objects, services, and firewall rules
  • Technitium DNS for internal name resolution
  • Caddy for services that should be reachable remotely

1. Configure Sophos XG

Open the Sophos XG administration interface:

https://sophos.is.manzana.home:4444/

Several objects normally need to be created before the machine or service can be used from other networks.

Create the DHCP entry

First, create a static DHCP mapping for the new machine.

I use names following the pattern for Proxmox LXC containers:

CT-...

The entry should associate the MAC address of the machine with its intended IP address.

Using a fixed DHCP assignment instead of manually configuring the IP address on the machine has several advantages:

  • IP assignments remain centrally documented
  • Replacing or reinstalling a machine is easier
  • Network configuration stays under control of the DHCP server
  • Firewall and DNS entries can safely reference a stable IP address

After creating the reservation, renew the DHCP lease on the client or restart its network connection.

2. Create a host object

Create a host object representing the new machine.

The naming convention I use is:

LXC ...

The object should reference the IP address assigned through DHCP.

This host object can later be reused in firewall rules instead of entering IP addresses directly.

For example:

LXC PhotoPrism

could represent:

10.0.10.210

Using host objects makes firewall rules considerably easier to understand later.

Instead of seeing:

10.0.20.0/24 → 10.0.10.210

the rule can describe its actual intention.

10.0.20.0/24 → LXC PhotoPrism

3. Create a service object

If the application listens on a dedicated TCP or UDP port, create a service object for it.

For example, PhotoPrism might listen on:

TCP 2342

A corresponding Sophos service object could therefore be named something like:

PhotoPrism TCP 2342

or simply:

PhotoPrism

The important part is that the configured port and protocol match the service running on the destination machine.

Keeping application ports in dedicated service objects also avoids scattering raw port numbers throughout firewall rules.

4. Create the firewall rule

Create the firewall rule that permits access to the new service.

I normally name firewall rules according to the traffic direction:

... → ...

For example:

Office → PhotoPrism

or:

Office → CoreServices

depending on whether the rule is intended for one application or a group of services.

The important settings are:

Source zones / networks:
    the network from which access should be allowed

Destination networks:
    the host object created above

Services:
    the service object created above

For example:

Source:
    Office

Destination:
    LXC PhotoPrism

Service:
    PhotoPrism TCP 2342

This keeps the firewall rule narrow: only the required clients, destination host, and destination port are permitted.

Avoid creating broad rules such as:

Office → CoreServices
ANY service

unless unrestricted communication between the two networks is explicitly intended.

5. Verify the Sophos rule

After creating the rule, verify access from a machine in the source network.

For example:

http://10.0.10.210:2342/

If the connection does not work, useful things to check include:

  • DHCP assignment
  • destination IP address
  • firewall rule order
  • source and destination zones
  • configured service port
  • TCP versus UDP
  • firewall on the destination machine
  • whether the application actually listens on the expected interface and port

Sophos packet capture can also be useful for determining whether the packets reach the firewall and which rule applies.

6. Create the Technitium DNS entry

Once network connectivity works, create a DNS entry in Technitium.

Open:

http://ct-technitium.cs.manzana.home:5380/

Add an appropriate DNS record for the machine or service.

For example:

photoprism.cs.manzana.home

pointing to:

10.0.10.210

Usually this will be an A record:

photoprism.cs.manzana.home.  A  10.0.10.210

After creating the record, verify name resolution:

nslookup photoprism.cs.manzana.home

or:

ping photoprism.cs.manzana.home

The service should now be accessible using its DNS name instead of its IP address:

http://photoprism.cs.manzana.home:2342/

7. Configure Caddy for remote access

This step is only necessary when the service should also be reachable through the Caddy reverse proxy.

The basic idea is:

Internet / remote client
        ↓
      Caddy
        ↓
internal DNS / IP address
        ↓
application

A minimal Caddy configuration could look like:

photos.example.com {
    reverse_proxy photoprism.cs.manzana.home:2342
}

Alternatively, the internal IP address can be used directly:

photos.example.com {
    reverse_proxy 10.0.10.210:2342
}

Using the internal DNS name is usually preferable because the Caddy configuration does not have to change if the application’s IP address changes later.

After changing the Caddy configuration, validate and reload it according to the way Caddy is installed.

For example:

caddy validate --config /etc/caddy/Caddyfile

followed by:

systemctl reload caddy

Complete checklist

For every new machine or application, walk through the following list.

Sophos XG

  • Create static DHCP assignment (CT-...)
  • Create host object (LCX ...)
  • Create service object for the required port
  • Create firewall rule (... → ...)
  • Select the new host under Destination networks
  • Select the new service under Services
  • Verify connectivity from the source network

Technitium

  • Create the DNS entry
  • Verify DNS resolution

Caddy

If remote access is required:

  • Add the reverse proxy configuration
  • Validate the Caddy configuration
  • Reload Caddy
  • Verify access through the external hostname

The most convenient order is:

1. DHCP reservation
        ↓
2. Sophos host object
        ↓
3. Sophos service object
        ↓
4. Sophos firewall rule
        ↓
5. Test access by IP address
        ↓
6. Technitium DNS entry
        ↓
7. Test access by DNS name
        ↓
8. Caddy reverse proxy
        ↓
9. Test remote access

Testing after each layer makes troubleshooting much easier.

If access by IP address already fails, there is no reason to investigate DNS or Caddy yet. Likewise, if access using the internal DNS name works but the public hostname does not, the problem is most likely in the reverse proxy or the path leading to it.

Following this sequence keeps adding new machines and services predictable and helps maintain clear separation between IP assignment, firewall policy, name resolution, and remote access.