44Net Connect/Routed Subnet/Raspberry Pi: Difference between revisions

From 44Net Wiki
KN6DWI (talk | contribs)
m Added missing sudo to iw command
KN6DWI (talk | contribs)
Created troubleshooting section on not receiving DHCP addresses
 
(2 intermediate revisions by the same user not shown)
Line 71: Line 71:


For the <code>802-11-wireless.band</code> setting, choose either <code>bg</code> for 2.4 GHz or <code>a</code> for 5 GHz.
For the <code>802-11-wireless.band</code> setting, choose either <code>bg</code> for 2.4 GHz or <code>a</code> for 5 GHz.
Now we need to disable the current <code>nmcli</code> connection and enable our new one. Current connections can be viewed by running <code>nmcli connection</code>. If your Pi is currently connected to a WiFi network, you'll see something like <code>netplan-wlan0-<name of your wifi network></code>. Disable that connection by running the following command:
<code>sudo nmcli conn down netplan-wlan0-<name of your wifi network></code>
Next, enable your new connection by running <code>sudo nmcli conn up <name of connection></code>


== Setting up DHCP ==
== Setting up DHCP ==
Line 131: Line 137:


== Setting up Routing ==
== Setting up Routing ==
=== Enable IP Forwarding ===
Enable IP forwarding in the kernel by running <code>sudo sysctl -w net.ipv4.ip_forward=1</code>. Verify that this worked by running <code>sysctl net.ipv4.ip_forward</code> and it should read back <code>net.ipv4.ip_forward = 1</code>.


== Troubleshooting ==
== Troubleshooting ==
=== Devices connected to the Pi are not receiving DHCP addresses ===
Verify that the Kea DHCP server is running:
<code>systemctl status kea-dhcp4-server</code>
If it's not running, read its logs on the status screen to see if there were any errors in the configuration file.
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.

Latest revision as of 00:15, 19 June 2026


Prerequisites

Set up a single-device tunnel to your Raspberry Pi. Note the IP and name of your WireGuard interface. The name of your WireGuard interface is the same as the name of your config file. For example, if your config file is /etc/wireguard/wg0.conf, then your interface name is wg0. The IP of your WireGuard interface can be obtained from running ifconfig <interface> and finding the IP listed under the interface in the inet field.

Below is some example output of ifconfig wg0.

wg0: flags=209<UP,POINTOPOINT,RUNNING,NOARP>  mtu 1380
    inet 44.27.133.190  netmask 255.255.255.255  destination 44.27.133.190
    inet6 fe80::f728:a0b0:3af5:b5c6  prefixlen 128  scopeid 0x20<link>
    unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
    RX packets 17331  bytes 5865364 (5.5 MiB)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 13389  bytes 2146828 (2.0 MiB)
    TX errors 0  dropped 1 overruns 0  carrier 0  collisions 0

Request a Subnet

Go to the 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.

Optional: Setting Up An Access Point

The recommended way to use a Raspberry Pi as the router for your subnet is with two ethernet interfaces. The second can be provided by a USB ethernet adapter or an ethernet hat. 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.

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.

Step 1: Set your wireless regulatory domain

Different countries have different rules about which frequencies and bandwidths devices are allowed to use for WiFi. Setting the regulatory domain ensures that your Pi will use the right ones, making it work best with nearby devices and ensuring regulatory compliance.

The Raspberry Pi OS imager asks you to set the wireless regulatory domain during setup, but does not require it. If you didn't set the regulatory domain in the imager configuration, set it now by running sudo raspi-config and going to Localisation Options > WLAN Country. Select your country, confirm, and exit. If you're not sure whether you set the wireless regulatory domain, run the command sudo iw reg get. Look at the country set under global. If it says unset, you have not set the regulatory domain.

Step 2: Create a new WiFi connection in nmcli

nmcli is the CLI interface for NetworkManager, which is the high level network configuration tool included in Raspberry Pi OS and many other Linux distributions. These configuration steps can be completed using the NetworkManager GUI, but many people operate their Raspberry Pis in "headless" mode (without a screen or keyboard) and use SSH to remotely configure it. Thus, this tutorial uses a CLI tool to accommodate that use case.

First, create the connection with the command

sudo nmcli con add con-name <connection name> ifname <interface name> type wifi ssid <BSSID>

In this command, <connection name> should be replaced with the name NetworkManager should use to reference this configuration. This name will be used to apply further configuration in later steps. <interface name> should be the wireless interface you're using to create the access point. By default, this is wlan0. <BSSID> is the name of your WiFi network that will appear to other devices. If it has spaces, you must enclose it in quotes.

Next, set the access point security and password.

sudo nmcli con modify <connection name> wifi-sec.key-mgmt wpa-psk

sudo nmcli con modify <connection name> wifi-sec.psk <password>

For security, leave only WPA2 enabled. By default, the older WPA protocol is enabled for compatibility, but it only supports the less secure TKIP encryption algorithm.

sudo nmcli con modify <connection name> wifi-sec.proto rsn

Even after disabling the older WPA protocol, WPA2 supports TKIP for compatibility. As an additional security measure, enable only the CCMP encryption algorithm, disabling TKIP.

sudo nmcli con modify <connection name> wifi-sec.pairwise ccmp

Finally, set the connection to access point mode and configure it to use your subnet assignment.

sudo nmcli con modify <connection name> 802-11-wireless.mode ap 802.11-wireless.band <band> ipv4.method manual ipv4.addr <subnet in CIDR notation>

For the 802-11-wireless.band setting, choose either bg for 2.4 GHz or a for 5 GHz.

Now we need to disable the current nmcli connection and enable our new one. Current connections can be viewed by running nmcli connection. If your Pi is currently connected to a WiFi network, you'll see something like netplan-wlan0-<name of your wifi network>. Disable that connection by running the following command:

sudo nmcli conn down netplan-wlan0-<name of your wifi network>

Next, enable your new connection by running sudo nmcli conn up <name of connection>

Setting up DHCP

Kea is the recommended DHCP server for setting up a routed subnet. dhcpd is deprecated as of 2022.

Install kea by running

sudo apt install kea.

After installing, configure its settings by editing /etc/kea/kea-dhcp4.conf. This file uses an extended JSON syntax that supports shell style comments using #, C style single line comments with //, and C style multi-line comments with /* */.

Configure Interface

Inside the Dhcp4 struct, under interfaces-config, add the interface you want your DHCP server to operate on to the interfaces list. For example, in a setup using 2 ethernet interfaces, you might have eth0 connected to your LAN and eth1 connected to your client devices. In this case, you would use eth1. If you're using the built-in wireless card to broadcast an access point, use wlan0.

"Dhcp4": {
    "interfaces-config": {
        "interfaces": [ "eth1" ]
    }
}

Configure DNS

Inside the Dhcp4 struct, under option-data set at least one DNS server. Cloudflare's DNS servers are 1.1.1.1 and 1.0.0.1. Google's DNS servers are 8.8.8.8 and 8.8.4.4.

"Dhcp4": {
    "option-data": [
        {
            "name": "domain-name-servers",
            "data": "1.1.1.1, 1.0.0.1, 8.8.8.8, 8.8.4.4"
        },
    ],
}

Configure your subnet

subnet4 is a list (denoted with brackets) of structures (denoted with curly brackets) where each structure is one subnet. Inside each subnet structure, set the client IP range(s) in pools, and define at least one router in the option-data field. Comment out or delete the example DHCP reservations in the reservations field, since they're for the wrong subnet.

"subnet4": [
    // Put your subnet here in CIDR notation.
    "subnet": "44.27.45.128/29",

    // Define the range of client IP addresses here.
    "pools": [ { "pool": "44.27.45.129 - 44.27.45.133" } ],

    // These options are subnet specific. You must configure at least one router.
    "option-data": [
        {
            "name": "routers",
            "data": "44.27.45.129"
        }
    ],
    "reservations": [
        // Comment out or delete the examples in this list, since they are for the wrong subnet.
    ]
]

Setting up Routing

Enable IP Forwarding

Enable IP forwarding in the kernel by running sudo sysctl -w net.ipv4.ip_forward=1. Verify that this worked by running sysctl net.ipv4.ip_forward and it should read back net.ipv4.ip_forward = 1.

Troubleshooting

Devices connected to the Pi are not receiving DHCP addresses

Verify that the Kea DHCP server is running:

systemctl status kea-dhcp4-server

If it's not running, read its logs on the status screen to see if there were any errors in the configuration file. 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 kea configuration in /etc/kea/kea-dhcp4.conf and ensure that your interface, router IP, and IP ranges are set properly.