DHCP Topology for Networks in the House and Outbuildings

There are some network Subnets which are local to the Outbuildings, with a Routed (Layer 3) connection back to the House.1 To field DHCP requests for Hosts on these Subnets, there needs to be something local to those subnets to receive the DHCP packets broadcast by clients.

Plan A was to use a separate instance of the dnsmasq DHCP / DNS server running on the Firewall / Router in the Outbuildings, configured with its own DHCP Ranges and Host Reservations etc. and forwarding DNS requests to dnsmasq running on the Firewall / Router in the House, While this sort-of worked OK, there were some shortcomings:

  • Hosts in the Outbuildings can resolve DNS requests for Hosts in the House, since the House’s DNS server is ‘upstream’ – but Hosts in the House cannot resolve DNS requests for Hosts in the Outbuildings, since those DNS records are only present in the Outbuildings’ DNS server.
    • While this isn’t a show-stopper, it’s more convenient for all Hosts to be able to resolve DNS names for all other Hosts.
    • I guess a workaround would be to point all the Hosts in the House to the Outbuildings‘ DNS server – but that would be pretty clunky
  • DNS responses from the House’s DNS server to the Outbuildings’ DNS server are flagged as a “possible DNS-rebind attack” – because they map to RFC1918 ‘private’ address space. The default configuration of dnsmasq on OPNsense makes it difficult to process such requests; it’s difficult to turn off the checking for such attacks.

Plan B is therefore to run DHCP Relay agents on the Subnets in the Outbuildings instead, forwarding DHCP requests to and from dnsmasq in the House. As well as addressing the issues listed above, there are a few ‘softer’ benefits:

  • All of the DHCP configuration – of Ranges, Host Reservations etc. is now consolidated in one place – in the House’s dnsmasq configuration pages.
    • There’s just a small, one-time configuration required in the Outbuildings’ router configuration, for every Subnet that needs a DHCP Relay agent
    • While this means there’s a single point of failure for DHCP, the House’s router is a single point of failure for pretty much all of the network connectivity anyway
  • Since the House’s dnsmasq server is configured to set the DNS server record in DHCP leases to ‘the address of the DHCP server’, that has the side effect of having all DNS queries from the Outbuildings go direct to the House’s DNS server – without the need to run any sort of DNS relay in the Outbuildings.
    • The same applies for NTP

In order to implement this behaviour the DHCRelay Service needs to be configured on the Outbuildings’ Firewall / Router. (It’s installed by default but without any configuration entries it has no effect.) There needs to be one “Destination” DHCP server (the House DHCP server in this case) set up – and then every network Interface which needs DHCP Relay services needs to be aded to the list of Relays.

Screenshot of the DHCRelay Configuration on the Outbuildings’ Firewall / Router

Then, on the House’s Router / Firewall, the corresponding DHCP ranges need to be defined as part of the dnsmasq configuration. All of the relayed DHCP requests for clients in the Outbuildings appear on the BACK network interface (the backbone link between the two routers) so the various address ranges need to be specified against that one interface.

Screenshot of the Dnsmasq DNS & DHCP Configuration on the House Firewall / Router

I think that’s all the configuration that is required. The relayed DHCP Request includes the IP address on which the Relay received the DHCPDISCOVER packet, which is enough to let the DHCP Server select from the appropriate address range (of the many ranges configured against the BACK interface).

  1. There are other network Subnets which need to be ‘stretched’ across both buildings. This is either because devices rely on Layer 2 continuity across the whole network (as is the case for the Paxton access control intercom system) or because they are supporting particular WiFi SSIDs and it needs to be possible for WiFi clients to roam from one Wireless Access Point to another while preserving the same IP address – even if these APs are in different buildings. All such networks are ‘bridged’ across the two buildings, so any DHCP traffic is naturally presented to the House DHCP server anyway. ↩︎

Fibre Connection Between the House and the Outbuildings

After initially thinking I wanted a fibre optic network link, I’d mostly settled on using a copper Cat 5E Ethernet link between the House and the Outbuildings, to connect their separate computer networks together. The reasons for favouring a copper Ethernet link were:

  • I happen to have about 150m of Ubiquiti outdoor grade Cat 5E Ethernet cable going spare, from when I bought a 305m reel to install outdoor cabling for the CCTV cameras that monitored the site and the construction of the House 10 years ago – so this enables the buildings to be linked ‘for free’
  • This network link will directly-connect the network Routers1 in each building, which (currently) only offer 1Gbit/s copper Ethernet ports and so would need Media Converters to connect over a fibre link
    • When these Routers need to be replaced, I would expect to purchase devices which have SFP+ ports which would take an SPF+ module to enable a fibre cable to be connected directly to each Router and synchronise at 10Gbit/s
    • Media Converters aren’t especially expensive – roughly £25 each – but need mounting somewhere and need their own power supply
  • The physical cable route between the two Routers takes ‘the long way round’ but is less than 100m, so the Cat 5E cable should enable a 1000BASE-T connection, at 1Gbit/s
  • 1Gbit/s will be plenty of bandwidth, given the planned use of the Outbuildings

However, I have just installed 85m of outdoor grade 8-core bulk fibre cable, because:

  • I had to install another cable along the same route, to extend a Current Transformer clamp connection to enable the Tesla PowerWall 32 to monitor the existing AC-connected solar PV inverter’s generation output
    • About 1/3 of the cable run is through the now-fully-insulated loft space above the Workshop, so it’s quite a difficult job to balance on the roof trusses (while unable to stand upright) and attach the cable to the cable baskets using the existing releasable cable ties – and it’s no harder to do that for 2 cables than for 1
  • Unterminated bulk fibre cable is surprisingly cheap – less than 50p per metre – so it’s not a major problem if the fibre doesn’t get used for a while – or ever

I’m still planning to use the copper Cat 5E initially, so I won’t pay to have the fibre spliced to pre-terminated ‘pigtails’ until I see how that performs (or doesn’t). If the Cat 5E works OK I’ll wait until I upgrade the Routers to light up the fibre link.

I selected Single Mode (OS2) fibre, with an outdoor-grade PE sheath (since about 25m of the run is in an underground duct between the buildings) and 8-core because it was only fractionally more expensive than 4-core.

Initially I found the many variants of fibre types and connectors quite confusing but this forum post by an amateur astronomer, in relation to network-connecting an observatory. proved very helpful in cutting through the jargon and homing in on the right solution – although they advocate using pre-terminated fibre which can be difficult to install when there’s not much space available in an existing duct.

  1. I’m using the term “Router” in the strict sense of its computer networking definition: a device that provides OSI Layer 3 connectivity, routing TCP/IP packets between Layer 2 network segments ↩︎
  2. Strictly speaking it’s the Tesla Backup Gateway 2 which does the monitoring – and then passes the measurement to the PowerWall 3 ↩︎