44Net Connect/Routed Subnet/Raspberry Pi - Revision history

KN6DWI: Clarified language on number of reserved IPs

2026-07-20T18:13:07Z

Clarified language on number of reserved IPs

← Older revision		Revision as of 18:13, 20 July 2026
Line 23:		Line 23:

	== Request a Subnet ==		== Request a Subnet ==
	Go to the [https://connect.44net.cloud/networks Network tab] of 44Net Connect, and request a network. Requests up to a /28 (16 IPs) are automatically approved. It's recommended to request at least a /29 (8 IPs), since at least 2 of your IPs must be set aside for network and ~~broadcast addresses~~. That way, you have at least 6 usable addresses for your hosts.		Go to the [https://connect.44net.cloud/networks Network tab] of 44Net Connect, and request a network. Requests up to a /28 (16 IPs) are automatically approved. It's recommended to request at least a /29 (8 IPs), since at least 3 of your IPs must be set aside for network address, broadcast address, and the address of the subnet's interface on your router. That way, you have at least 6 usable addresses for your hosts.

	== Setting Up The Network Interface ==		== Setting Up The Network Interface ==

KN6DWI: Added instructions to start Kea after configuring

2026-07-15T22:33:10Z

Added instructions to start Kea after configuring

← Older revision		Revision as of 22:33, 15 July 2026
Line 180:		Line 180:
	// The rest of this config is omitted for brevity.		// The rest of this config is omitted for brevity.
	}</nowiki>		}</nowiki>

			=== Enable Kea ===
			Enable and start <code>kea</code> by running <code>sudo systemctl enable --now kea-dhcp4-server</code>. Check that the server has started without issue by running <code>systemctl status kea-dhcp4-server</code>.

	== Setting up Routing ==		== Setting up Routing ==

KN6DWI: Fixed typo

2026-07-15T18:15:02Z

Fixed typo

← Older revision		Revision as of 18:15, 15 July 2026
Line 33:		Line 33:
	An <code>nmcli</code> "connection" is an abstraction representing a network configuration attached to a device. Create a new connection by running		An <code>nmcli</code> "connection" is an abstraction representing a network configuration attached to a device. Create a new connection by running

	<code>sudo nmcli con add ~~conn~~-name <name> ifname <interface name> type <type></code>.		<code>sudo nmcli con add con-name <name> ifname <interface name> type <type></code>.

	You can name the connection whatever you like, but it's recommended to name it something descriptive. For example, if you're configuring a 44net routed subnet for <code>eth1</code>, you might name it <code>44net-eth1</code>. The interface name is the name of the interface you're using, as described by <code>ifconfig</code>. The type is either <code>wifi</code> or <code>ethernet</code>. For a WiFi interface, you must also specify the BSSID (network name) by adding the parameter <code>ssid <BSSID></code> at the end.		You can name the connection whatever you like, but it's recommended to name it something descriptive. For example, if you're configuring a 44net routed subnet for <code>eth1</code>, you might name it <code>44net-eth1</code>. The interface name is the name of the interface you're using, as described by <code>ifconfig</code>. The type is either <code>wifi</code> or <code>ethernet</code>. For a WiFi interface, you must also specify the BSSID (network name) by adding the parameter <code>ssid <BSSID></code> at the end.

	=== Step 2: Configure the IP ===		=== Step 2: Configure the IP ===

KN6DWI: Added recommendations about priority and using ip rule over ip route

2026-07-07T23:31:37Z

Added recommendations about priority and using ip rule over ip route

← Older revision		Revision as of 23:31, 7 July 2026
Line 194:		Line 194:
	Next, we need to add a routing rule to allow the clients on the routed subnet to exit via the WireGuard tunnel. The setup steps for creating the tunnel should have created the routing table <code>51820</code> where the default route is via the WireGuard interface, whatever you've named it. Verify that it exists by running the command <code>ip route show table 51820</code>. It should have a single line that says something like <code>default dev wg0 scope link</code>. In this case, <code>wg0</code> is the example WireGuard interface name. Yours may be different.		Next, we need to add a routing rule to allow the clients on the routed subnet to exit via the WireGuard tunnel. The setup steps for creating the tunnel should have created the routing table <code>51820</code> where the default route is via the WireGuard interface, whatever you've named it. Verify that it exists by running the command <code>ip route show table 51820</code>. It should have a single line that says something like <code>default dev wg0 scope link</code>. In this case, <code>wg0</code> is the example WireGuard interface name. Yours may be different.

	Run the command <code>sudo ip rule add from <subnet> table 51820</code>. Replace <code><subnet></code> with your routed subnet in CIDR notation.		Run the command <code>sudo ip rule add from <subnet> table 51820</code>. Replace <code><subnet></code> with your routed subnet in CIDR notation. If you have other rules with desired priority order, set your priority in the above command accordingly. Though it's possible to do the same thing as this rule using <code>ip route</code>, it's much more difficult and is not recommended.

	Verify that your routing is working correctly by running the following command:		Verify that your routing is working correctly by running the following command:

KN6DWI: Instructed user to check for kea failing to bind to interface when troubleshooting

2026-06-30T23:09:10Z

Instructed user to check for kea failing to bind to interface when troubleshooting

← Older revision		Revision as of 23:09, 30 June 2026
Line 236:		Line 236:
	Forgetting to delete the default DHCP reservation examples will cause errors, because those are not in your subnet.		Forgetting to delete the default DHCP reservation examples will cause errors, because those are not in your subnet.

	If the DHCP server has started properly, check your <code>kea</code> configuration in <code>/etc/kea/kea-dhcp4.conf</code> and ensure that your interface, router IP, and IP ranges are set properly.		If the DHCP server has started properly, check your <code>kea</code> configuration in <code>/etc/kea/kea-dhcp4.conf</code> and ensure that your interface, router IP, and IP ranges are set properly. Check the logs in <code>systemctl status kea-dhcp4-server</code> for warnings that <code>kea</code> failed to bind to an interface.

	=== Clients cannot find route to hosts ===		=== Clients cannot find route to hosts ===

KN6DWI: Added missing space

2026-06-30T23:01:33Z

Added missing space

← Older revision		Revision as of 23:01, 30 June 2026
Line 184:		Line 184:
	=== Enable IP Forwarding ===		=== Enable IP Forwarding ===
	To allow packets to be forwarded between different network interfaces on your Pi, we must enable IP forwarding in the kernel. Do this by adding the line <code>net.ipv4.ip_forward=1</code> to one of the drop-in files in <code>/etc/sysctl.d/</code>. The file <code>98-rpi.conf</code> exists by default, so		To allow packets to be forwarded between different network interfaces on your Pi, we must enable IP forwarding in the kernel. Do this by adding the line <code>net.ipv4.ip_forward=1</code> to one of the drop-in files in <code>/etc/sysctl.d/</code>. The file <code>98-rpi.conf</code> exists by default, so
	add the line to ~~thatfile~~ using your editor of choice. It will require superuser privileges. For example:		add the line to that file using your editor of choice. It will require superuser privileges. For example:

	<code>sudo nano /etc/sysctl.d/98-rpi.conf</code>		<code>sudo nano /etc/sysctl.d/98-rpi.conf</code>

KN6DWI: Grammatical fix

2026-06-30T18:29:02Z

Grammatical fix

← Older revision		Revision as of 18:29, 30 June 2026
Line 59:		Line 59:
	== Optional: Setting Up A Wireless Access Point ==		== Optional: Setting Up A Wireless Access Point ==

	~~However, if~~ you have wireless only clients or wish not to purchase additional hardware, the Raspberry Pi's WiFi interface can be configured as an access point.		If you have wireless only clients or wish not to purchase additional hardware, the Raspberry Pi's WiFi interface can be configured as an access point.

	After your subnet is approved, you must attach it to your tunnel. Go to your Tunnels tab on 44Net Connect, and click Edit on the tunnel for your routing device. Go to the "Route additional Networks Through This Tunnel" section, and check the box for the subnet you want to use for this tunnel.		After your subnet is approved, you must attach it to your tunnel. Go to your Tunnels tab on 44Net Connect, and click Edit on the tunnel for your routing device. Go to the "Route additional Networks Through This Tunnel" section, and check the box for the subnet you want to use for this tunnel.

KN6DWI: Fixed heading formatting issue

2026-06-26T20:12:37Z

Fixed heading formatting issue

← Older revision		Revision as of 20:12, 26 June 2026
Line 160:		Line 160:
	</nowiki>		</nowiki>

	~~###~~ Ethernet Hot Plugging Workaround		=== Ethernet Hot Plugging Workaround ===
	At present, <code>kea</code> does not support hot plugging interfaces. This means that ethernet devices must have at least one client at the time the DHCP server starts, otherwise it will not properly bind to the interface. If you plan on hot plugging ethernet devices on your Pi, this can be worked around by configuring <code>service-sockets-max-retries</code> to an extremely large number such as 9223372036854775807, the upper limit of a signed 64-bit integer. You may also wish to increase <code>service-sockets-retry-wait-time</code>, which specifies the retry time in milliseconds, though the default time of 5000 ms is typically fine. These options should go in the <code>interfaces-config</code> section at the top of your <code>Dhcp4</code> section in <code>/etc/kea/kea-dhcp4.conf</code>. Here is an example:		At present, <code>kea</code> does not support hot plugging interfaces. This means that ethernet devices must have at least one client at the time the DHCP server starts, otherwise it will not properly bind to the interface. If you plan on hot plugging ethernet devices on your Pi, this can be worked around by configuring <code>service-sockets-max-retries</code> to an extremely large number such as 9223372036854775807, the upper limit of a signed 64-bit integer. You may also wish to increase <code>service-sockets-retry-wait-time</code>, which specifies the retry time in milliseconds, though the default time of 5000 ms is typically fine. These options should go in the <code>interfaces-config</code> section at the top of your <code>Dhcp4</code> section in <code>/etc/kea/kea-dhcp4.conf</code>. Here is an example:

KN6DWI: Added instructions for ethernet hotplugging workaround

2026-06-26T19:36:44Z

Added instructions for ethernet hotplugging workaround

@@ Line 159: / Line 159: @@
+]
 </nowiki>
 == Setting up Routing ==

KN6DWI: Added instructions on starting the new interface

2026-06-26T19:20:09Z

Added instructions on starting the new interface

← Older revision		Revision as of 19:20, 26 June 2026
Line 46:		Line 46:
	<code>sudo nmcli con modify <name> ipv4.address <subnet></code>		<code>sudo nmcli con modify <name> ipv4.address <subnet></code>

	Your subnet should be specified in CIDR notation.		Your subnet should be specified in CIDR notation. At this point, if you're configuring an ethernet interface, you're ready to start it up. If you're configuring a WiFi interface, don't start your interface yet, and move on to the next section for additional configuration.

			=== Step 3: Starting the Interface ===
			First, disable the existing connection, which is likely named <code>netplan-<interface></code>. If you're using <code>eth1</code> for your 44net clients, it may look like <code>netplan-eth1</code>. If you are configuring your Pi over SSH, be careful not to deactivate the connection over which your SSH is traveling.

			<code>sudo nmcli con down <name of existing connection></code>

			After deactivating the regular connection, activate your new connection. If this succeeds, you're good to go.

			<code>sudo nmcli con up <name of new connection></code>

	== Optional: Setting Up A Wireless Access Point ==		== Optional: Setting Up A Wireless Access Point ==