Skip to content

Final Network - LAN Configuration

This page provides requirements to complete the final configuration of your LAN, including all internal address updates, private LAN resources, and firewall rules.

"Re-numbering" your Ethernet Network

While connecting directly to your Pi, reconfigure the routing interface on eth0 and your DHCP configuration based on your new address plan (using the addresses set aside for the untagged subnet). In addition to new address changes, we will make another change from prior checkpoints. Remove the secondary address assignments from eth0, leaving only the gateway/DHCP address. We will be moving these addresses onto a separate virtual interface.

To minimize time spent on troubleshooting, proceed carefully with this task and make sure that you update networkd and dhcpd in a consistent manner.1 You are also advised to temporarily disable the dhcpd options for routers and domain-name-servers. This precaution will prevent attempts to use the Pi as default gateway and DNS resolver until you have completed your configuration changes and testing.

Routing

When you are confident in your updates, modify the dhcpd configuration again to provide clients on the LAN with the new default gateway address. Reload the DHCP configuration and force a lease renewal on your connection to proceed with testing. Before you move on, make sure that DHCP works and that your Pi is still able to route internet traffic for your LAN.

LAN Configuration for Tagged Subnet

Using your LAN's VLAN ID recorded in the VLAN/Switch planning document, create a new VLAN virtual network device associated with eth0 as described in Configuring VLANs in systemd-networkd. Create a .network file for this virtual interface modeled on /etc/systemd/network/20-eth0.network, and set up the gateway IP defined for your trunked network in your final address plan.

DHCP

Two additional changes will be needed to provide DHCP services on this subnet:

  • Revisit /etc/default/isc-dhcp-server (last modified in Checkpoint #2) and update the list of DHCP interfaces to include the new VLAN interface.2
  • Add a second subnet declaration to dhcpd.conf, enabling a dynamic address range and a router option specifying the gateway address for the subnet.

nftables

In Checkpoint #3, we set up nftables rules to enable NAT on outbound traffic and to allow forwarding from our internal LAN. Now that our internal LAN spans two network interfaces, it's likely that your rules will need some updates to permit traffic from the VLAN interface to be forwarded.

To minimize repetition in rulesets, we can rewrite our rules to reference a set of interfaces rather than just one. Likewise, we can generalize our rule so that it allows to send traffic to anywhere from any of our internal networks.

These changes are demonstrated in the example below, where a rule is updated to accept incoming packets from any member of the set { eth0, vlan2 } rather than just eth0. This rule has logical or semantics. It allows traffic flowing from eth0 => * or vlan2 => *.

- iifname eth0 oifname wlan0 accept
+ iifname { eth0, vlan2 } accept

As with previous changes to the nftables rules, we recommend against modifying /etc/nftables.conf directly. Instead, copy the current file into your home directory and use the nftables-apply.sh script given in the project resources to test and install your updates.

Testing

This subnet is designed to accomodate the final network topology, in which your LAN devices connect to a switch port that is natively configured for the correct VLAN while your Pi is communicating over a tagged link. This poses a challenge for testing the configuration without having a correctly configured switch in hand. Please consider the following options if you would like to test your second subnet over a direct connection.

Apple provides full support for VLAN tagging. With your Ethernet adapter attached, create a new VLAN interface associated with the adapter based on the instructions in Apple's online help. After applying your changes in System Preferences, select the physical adapter and turn it off by change the setting Configure IPv4.

Windows support for VLAN tagging is inconsistent. With supported adapters, you may be able to set a VLAN ID by editing the advanced settings for your network adapter. To modify these settings, right click on the Start Menu and open Device Manager. Locate the correct network adapter in the device list and look for the VLAN ID option in the device's advanced properties. This option is device dependent. It will not always be present in the options list, and it is not guaranteed to function as expected when it is available.

Private LAN Resources

In this section, you will update the configuration for the network services available on your LAN, namely DNS resolution and the private domain.

Configure IP Addressing

To separate the internal service subnet from the subnets used to connect end-users to your network, we are moving the associated IP addresses to a new, virtual network device known as a dummy interface. Dummy interfaces use a loopback mechanism to provide a software-based endpoint that is always available (even when physical connections are offline). This feature is similar to the loopback interface (lo) that provides localhost networking on 127.0.0.1; however, we can still communicate to these dummy interfaces over physical network links.

Create and configure a persistent dummy interface on the Pi as described in Configuring Dummy Interfaces in systemd-networkd. Add a .network configuration for this interface with Address= statements for your resolver and private name server addresses.

Remember that this statement expects the address and network to be given backslash-delimited, abbreviated CIDR format. Because of the loopback-like behavior that drives dummy interfaces, you can list each address as a /32 network, as shown below:

/etc/systemd/network/20-lan0.network
[Match]
Name=lan0

[Network]
Address=172.30.0.129/32
Address=172.30.0.130/32

Once you have completed the configuration, reload the systemd-networkd service and verify that the new addresses are online and able to receive traffic.

Bind9

Open named.conf.options and edit the subnet and address references to match your final address planning changes. Make sure that your ACL includes all of your assigned address space and that you server is set to listen for connections from your resolver and private name server addresses. Finally, update the authoritative name server's address record within your private zone file.

Verify your updates and use rndc to reload the configuration files (as you did previously in Checkpoints #4 and #5). Test the name server from your Pi and from your laptop3, before updating DHCP to provide the new resolver address (on both subnets).

Override DNS resolution on the Pi

By now, you should be aware that when you run a dig query from your Pi, the queries are not being handled by your local Bind9 instance. By default, DNS resolution relies on the name server addresses that were configured by DHCP on the wireless network. To control which resolvers the Pi will use, we need to modify the resolver configuration under systemd-resolved. In this case, we'll use a systemd "drop-in" to set a global DNS resolver preference and a search domain.

Drop-ins are a systemd configuration pattern that is used to override default behavior. Each service has its own drop-in configuration directory. If the standard location for a service doesn't already exist, administrators can enable the feature by creating the directory and additional .conf files.

Run mkdir -p /etc/systemd/resolved.conf.d to create the drop-in configuration directory for the systemd-resolved resolver. Add a new configuration to this location containing the following settings (adapted to your own network).

/etc/systemd/resolved.conf.d/override_dns.conf
[Resolve]
DNS=127.0.0.1 # resolve via localhost
Domains=lan.gradebook.pi # private domain name

Restart the systemd-resolved service and verify that the new settings appear in /etc/resolv.conf. You may notice other resolver addresses, but the localhost address should appear first in the list. The file should end with a Search statement pointing to your private domain name.

  1. Many of the questions that arise in this process can be answered by reviewing your previous work and the project guides from those Checkpoints. ↩

  2. This file's comments includes notes that are pertinent to configuring the list. ↩

  3. Make sure you're querying the correct name server. Remember that dig can override the system resolver by providing an @<resolver-address> parameter before your query. The powershell command Resolve-DnsName takes a -server parameter. ↩

Back to top