44Net Wiki - User contributions [en]

44Net Connect/Quick Start/PFsense

2026-07-14T16:33:16Z

KN6DWI: Added troubleshooting section

=== What you need ===
* A 44Net Portal account
* A verified amateur radio callsign
* A machine running PFsense
* Some sort of Internet access

If you haven't set up your Portal account or verified your callsign yet, see [[GetStarted|44Net: Get Started]] for instructions. If you haven't obtained a WireGuard tunnel configuration file from 44Net Connect, get one using the [[44Net_Connect/Quick_Start|the 44Net Connect quick start guide]]

Unlike other Quick Start guides, we aren't starting with a configuration file from 44Net Connect. Instead, we will be creating one during the course of this tutorial.

== Install the WireGuard Package ==
WireGuard is not installed by default on PFsense, so we need to install it. Go to <code>System > Package Manager > Available Packages</code> and install WireGuard.

== Generate keypair and create tunnel ==
After installing WireGuard, go to <code>VPN > WireGuard > Tunnels</code> and click the <code>Add Tunnel</code> button.
Click the <code>Generate</code> button to generate a new keypair.

[[File:pfsense_generate_keypair.png|A screenshot of the PFsense WireGuard tunnel configuration page. The button to generate a new WireGuard keypair is highlighted with a red box.]]

Then, open your [https://connect.44net.cloud/tunnels tunnels page in 44Net Connect], request a new tunnel, and select your preferred server.
In the <code>Public Key</code> field, paste the public key generated in PFsense, then click <code>Create Tunnel</code> to save. Retain the wg-quick WireGuard config for use in later steps.

== Fill in interface ==
Copy the interface addresses from your config file into the Interface Addresses section in your PFsense WireGuard tunnel configuration. Adding the IPv6 address is optional but recommended. If you're doing so, click the <code>Add Address</code> button to add another IP address field. For all entries, use the drop-down menu to configure the subnet. For the IPv4 address it should be /32, and for the IPv6 address it should be /64. There are some places on 44Net Connect that are labeled in a confusing way, and could be interpreted as your tunnel being allocated a /24 for IPv4, but a tunnel will always receive a /32 for IPv4.

[[File:pfsense_interface.png|A side-by-side view of the PFsense WireGuard interface configuration page, and a wg-quick config file opened in the Kate text editor. A red arrow indicates where one should copy the IP addresses from the config file into the configuration page.]]

PFsense won't let you add peers until you save the tunnel. Click <code>Save Tunnel</code> to save, and we'll add peers in the next step.

== Add Peer ==
Click the <code>Add Peer</code> button. Uncheck the <code>Dynamic Endpoint</code> box, as this will allow us to fill in a static IP and port for the endpoint. Fill in the endpoint IP and port from the <code>[Peer]</code> section of the WireGuard config file. Also copy in MTU, Keep Alive interval, the peer's public key, and if applicable, the pre-shared key.

[[File:pfsense_peer_configuration.png|A side-by-side view of the PFsense WireGuard peer configuration page and a wg-quick configuration file. Red numbered dots indicate where to copy the information from the config file to the configuration page.]]

Fill in the Allowed IPs section at the bottom using the values from the config file, which by default is <code>0.0.0.0/0</code> and <code>::/0</code>. This configuration allows all addresses, and will let you pass all traffic through the tunnel. If you want only traffic to and from your 44Net IP to go through the tunnel, change your AllowedIPs to <code>44.0.0.0/9</code> and <code>44.128.0.0/10</code>.

[[File:pfsense_peer_allowed_ips.png|A side-by-side view of the PFsense WireGuard peer configuration page and a wg-quick configuration file. Red arrows show where to copy allowed IPs from the configuration file to the PFsense configuration page.]]

== Enable WireGuard ==
Go to <code>VPN > WireGuard > Settings</code> and check the <code>Enable WireGuard</code> box, then save your changes. If prompted with a banner at the top to save your WireGuard settings before applying, do so. Check the status of your tunnel by going to <code>Status > WireGuard</code>, clicking the arrow next to your tunnel to expand its section, and verifying that it's performed a handshake with the endpoint.

[[File:pfsense_wireguard_status.png|A screenshot of the PFSense WireGuard status page. There is a green handshake icon, and the latest handshake was 1 minute 54 seconds ago.]]

== Troubleshooting ==
=== Tunnel is up but peer is not ===
If your tunnel is up (indicated by the green up arrow) but your peer connection is not, there may be something wrong with your peer configuration. Double check it against the config file. Ensure your allowed IPs are set correctly, and that the subnet size is correctly selected in the drop-down menu.

=== Tunnel will not connect ===
Ensure that the dynamic endpoint checkbox is unchecked. Verify that the tunnel's endpoint IP, endpoint port, keep alive time, and public key are correct. If you are using a pre-shared key, make sure that it matches the one set in 44Net connect.

44Net Connect/Quick Start/PFsense

2026-07-14T04:53:04Z

KN6DWI: /* Enable WireGuard */

File:Pfsense wireguard status.png

2026-07-14T00:10:45Z

KN6DWI: A screenshot of the PFSense WireGuard status page. There is a green handshake icon, and the latest handshake was 1 minute 54 seconds ago.

== Summary ==
A screenshot of the PFSense WireGuard status page. There is a green handshake icon, and the latest handshake was 1 minute 54 seconds ago.

44Net Connect/Quick Start/PFsense

2026-07-14T00:07:24Z

KN6DWI: Added picture for filling in allowed IPs

File:Pfsense peer allowed ips.png

2026-07-14T00:07:14Z

KN6DWI: A side-by-side view of the PFsense WireGuard peer configuration page and a wg-quick configuration file. Red arrows show where to copy allowed IPs from the configuration file to the PFsense configuration page.

== Summary ==
A side-by-side view of the PFsense WireGuard peer configuration page and a wg-quick configuration file. Red arrows show where to copy allowed IPs from the configuration file to the PFsense configuration page.

File:Pfsense peer configuration.png

2026-07-14T00:02:39Z

KN6DWI: KN6DWI uploaded a new version of File:Pfsense peer configuration.png

== Summary ==
A side-by-side view of the PFsense WireGuard peer configuration page and a wg-quick configuration file. Red numbered dots indicate where to copy the information from the config file to the configuration page.

File:Pfsense peer configuration.png

2026-07-13T18:52:07Z

KN6DWI: Fixed typo

44Net Connect/Quick Start/PFsense

2026-07-13T18:51:56Z

KN6DWI: Added image for peer configuration

=== What you need ===
* A 44Net Portal account
* A verified amateur radio callsign
* A machine running PFsense
* Some sort of Internet access

If you haven't set up your Portal account or verified your callsign yet, see [[GetStarted|44Net: Get Started]] for instructions. If you haven't obtained a WireGuard tunnel configuration file from 44Net Connect, get one using the [[44Net_Connect/Quick_Start|the 44Net Connect quick start guide]]

Unlike other Quick Start guides, we aren't starting with a configuration file from 44Net Connect. Instead, we will be creating one during the course of this tutorial.

== Install the WireGuard Package ==
WireGuard is not installed by default on PFsense, so we need to install it. Go to <code>System > Package Manager > Available Packages</code> and install WireGuard.

== Generate keypair and create tunnel ==
After installing WireGuard, go to <code>VPN > WireGuard > Tunnels</code> and click the <code>Add Tunnel</code> button.
Click the <code>Generate</code> button to generate a new keypair.

[[File:pfsense_generate_keypair.png|A screenshot of the PFsense WireGuard tunnel configuration page. The button to generate a new WireGuard keypair is highlighted with a red box.]]

Then, open your [https://connect.44net.cloud/tunnels tunnels page in 44Net Connect], request a new tunnel, and select your preferred server.
In the <code>Public Key</code> field, paste the public key generated in PFsense, then click <code>Create Tunnel</code> to save. Retain the wg-quick WireGuard config for use in later steps.

== Fill in interface ==
Copy the interface addresses from your config file into the Interface Addresses section in your PFsense WireGuard tunnel configuration. Adding the IPv6 address is optional but recommended. If you're doing so, click the <code>Add Address</code> button to add another IP address field. For all entries, use the drop-down menu to configure the subnet. For the IPv4 address it should be /32, and for the IPv6 address it should be /64. There are some places on 44Net Connect that are labeled in a confusing way, and could be interpreted as your tunnel being allocated a /24 for IPv4, but a tunnel will always receive a /32 for IPv4.

[[File:pfsense_interface.png|A side-by-side view of the PFsense WireGuard interface configuration page, and a wg-quick config file opened in the Kate text editor. A red arrow indicates where one should copy the IP addresses from the config file into the configuration page.]]

PFsense won't let you add peers until you save the tunnel. Click <code>Save Tunnel</code> to save, and we'll add peers in the next step.

== Add Peer ==
Click the <code>Add Peer</code> button. Uncheck the <code>Dynamic Endpoint</code> box, as this will allow us to fill in a static IP and port for the endpoint. Fill in the endpoint IP and port from the <code>[Peer]</code> section of the WireGuard config file. Also copy in MTU, Keep Alive interval, the peer's public key, and if applicable, the pre-shared key.

[[File:pfsense_peer_configuration.png|A side-by-side view of the PFsense WireGuard peer configuration page and a wg-quick configuration file. Red numbered dots indicate where to copy the information from the config file to the configuration page.]]

Fill in the Allowed IPs section at the bottom using the values from the config file, which by default is <code>0.0.0.0/0</code> and <code>::/0</code>. This configuration allows all addresses, and will let you pass all traffic through the tunnel. If you want only traffic to and from your 44Net IP to go through the tunnel, change your AllowedIPs to <code>44.0.0.0/9</code> and <code>44.128.0.0/10</code>.

== Enable WireGuard ==
Go to <code>VPN > WireGuard > Settings</code> and check the <code>Enable WireGuard</code> box, then save your changes. If prompted with a banner at the top to save your WireGuard settings before applying, do so. Check the status of your tunnel by going to <code>Status > WireGuard</code>, clicking the arrow next to your tunnel to expand its section, and verifying that it's performed a handshake with the endpoint.

File:Pfsense peer configuration.png

2026-07-13T18:48:48Z

KN6DWI: A side-by-side view of the PFsense WireGuard peer configuration page and a wg-quick configuration file. Red numbered dots indicate where to copy the information from the config file to the configuration page.t

44Net Connect/Quick Start/PFsense

2026-07-13T18:10:31Z

KN6DWI: Added picture for filling in the tunnel IPs and made a minor grammatical edit

=== What you need ===
* A 44Net Portal account
* A verified amateur radio callsign
* A machine running PFsense
* Some sort of Internet access

If you haven't set up your Portal account or verified your callsign yet, see [[GetStarted|44Net: Get Started]] for instructions. If you haven't obtained a WireGuard tunnel configuration file from 44Net Connect, get one using the [[44Net_Connect/Quick_Start|the 44Net Connect quick start guide]]

Unlike other Quick Start guides, we aren't starting with a configuration file from 44Net Connect. Instead, we will be creating one during the course of this tutorial.

== Install the WireGuard Package ==
WireGuard is not installed by default on PFsense, so we need to install it. Go to <code>System > Package Manager > Available Packages</code> and install WireGuard.

== Generate keypair and create tunnel ==
After installing WireGuard, go to <code>VPN > WireGuard > Tunnels</code> and click the <code>Add Tunnel</code> button.
Click the <code>Generate</code> button to generate a new keypair.

[[File:pfsense_generate_keypair.png|A screenshot of the PFsense WireGuard tunnel configuration page. The button to generate a new WireGuard keypair is highlighted with a red box.]]

Then, open your [https://connect.44net.cloud/tunnels tunnels page in 44Net Connect], request a new tunnel, and select your preferred server.
In the <code>Public Key</code> field, paste the public key generated in PFsense, then click <code>Create Tunnel</code> to save. Retain the wg-quick WireGuard config for use in later steps.

== Fill in interface ==
Copy the interface addresses from your config file into the Interface Addresses section in your PFsense WireGuard tunnel configuration. Adding the IPv6 address is optional but recommended. If you're doing so, click the <code>Add Address</code> button to add another IP address field. For all entries, use the drop-down menu to configure the subnet. For the IPv4 address it should be /32, and for the IPv6 address it should be /64. There are some places on 44Net Connect that are labeled in a confusing way, and could be interpreted as your tunnel being allocated a /24 for IPv4, but a tunnel will always receive a /32 for IPv4.

[[File:pfsense_interface.png|A side-by-side view of the PFsense WireGuard interface configuration page, and a wg-quick config file opened in the Kate text editor. A red arrow indicates where one should copy the IP addresses from the config file into the configuration page.]]

PFsense won't let you add peers until you save the tunnel. Click <code>Save Tunnel</code> to save, and we'll add peers in the next step.

== Add Peer ==
Click the <code>Add Peer</code> button. Uncheck the <code>Dynamic Endpoint</code> box, as this will allow us to fill in a static IP and port for the endpoint. Fill in the endpoint IP and port from the <code>[Peer]</code> section of the WireGuard config file. Also copy in MTU, Keep Alive interval, the peer's public key, and if applicable, the pre-shared key.

Fill in the Allowed IPs section at the bottom using the values from the config file, which by default is <code>0.0.0.0/0</code> and <code>::/0</code>. This configuration allows all addresses, and will let you pass all traffic through the tunnel. If you want only traffic to and from your 44Net IP to go through the tunnel, change your AllowedIPs to <code>44.0.0.0/9</code> and <code>44.128.0.0/10</code>.

== Enable WireGuard ==
Go to <code>VPN > WireGuard > Settings</code> and check the <code>Enable WireGuard</code> box, then save your changes. If prompted with a banner at the top to save your WireGuard settings before applying, do so. Check the status of your tunnel by going to <code>Status > WireGuard</code>, clicking the arrow next to your tunnel to expand its section, and verifying that it's performed a handshake with the endpoint.

File:Pfsense interface.png

2026-07-13T18:08:57Z

KN6DWI: A side-by-side view of the PFsense WireGuard interface configuration page, and a wg-quick config file opened in the Kate text editor. A red arrow indicates where one should copy the IP addresses from the config file into the configuration page.

== Summary ==
A side-by-side view of the PFsense WireGuard interface configuration page, and a wg-quick config file opened in the Kate text editor. A red arrow indicates where one should copy the IP addresses from the config file into the configuration page.

44Net Connect/Quick Start/PFsense

2026-07-13T17:53:50Z

KN6DWI: Added picture of keypair generation button

File:Pfsense generate keypair.png

2026-07-13T17:52:50Z

KN6DWI: A screenshot of the PFsense WireGuard tunnel configuration page. The button to generate a new WireGuard keypair is highlighted with a red box.

== Summary ==
A screenshot of the PFsense WireGuard tunnel configuration page. The button to generate a new WireGuard keypair is highlighted with a red box.

44Net Connect/Quick Start/PFsense

2026-07-09T19:21:32Z

KN6DWI: Wrote Enable WireGuard section

44Net Connect/Quick Start/PFsense

2026-07-09T19:18:44Z

KN6DWI: Wrote section on adding peer

44Net Connect/Quick Start/PFsense

2026-07-09T18:51:48Z

KN6DWI: Wrote section on filling in interface

44Net Connect/Quick Start/PFsense

2026-07-09T18:01:23Z

KN6DWI: Wrote section on generating keypair and creating tunnel

44Net Connect/Quick Start/OPNsense

2026-07-09T18:00:07Z

KN6DWI: Grammatical improvement

=== What you need ===
* A 44Net Portal account
* A verified amateur radio callsign
* A machine running OPNsense
* Some sort of Internet access

If you haven't set up your Portal account or verified your callsign yet, see [[GetStarted|44Net: Get Started]] for instructions. If you haven't obtained a WireGuard tunnel configuration file from 44Net Connect, get one using the [[44Net_Connect/Quick_Start|the 44Net Connect quick start guide]]

Unlike other Quick Start guides, we aren't starting with a configuration file from 44Net Connect. Instead, we will be creating one during the course of this tutorial.

== Generate a keypair in OPNsense ==
Navigate to <code>VPN > WireGuard > Instances</code> in your OPNsense web GUI and create a new instance. Click the gear button to generate a public key/private key keypair.

[[File:opnsense_keypair_generation.png|500px|A screenshot of the OPNsense edit instance dialogue, with the gear button next to the public key field circled in red.]]

== Create a tunnel in 44Net Connect ==
Open your [https://connect.44net.cloud/tunnels tunnels page in 44Net Connect] and click <code>Request a Tunnel</code>. Select your preferred server. In the <code>Public Key</code> field, paste the public key generated in OPNsense, then click <code>Create Tunnel</code> to save. Save the wg-quick WireGuard config for use in later steps.

[[File:request_tunnel_44net_connect.png|A screenshot of the 44Net Connect tunnel page header with the Request Tunnel button highlighted in a red box]]

== Copy the tunnel details into OPNsense ==
=== Fill out instance ===
Go back to your OPNsense Web UI. Give your instance a name, and fill out the <code>Tunnel address</code> field with the addresses from the <code>[Interface]</code> section of the config. Check the <code>Disable routes</code> checkbox, then save your instance.

[[File:opnsense_populate_instance.png| A screenshot with a side by side view of a WireGuard config file and an OPNsense WireGuard instance configuration page. A red arrow indicates how to copy the tunnel addresses from the config file to the OPNsense configuration page. A red rectangle indicates that the user should check the "Disable Routes" box.]]

=== Fill out peer ===
Go to <code>VPN > WireGuard > Peers</code> in your OPNsense Web UI, and click the orange <code>+</code> button in the bottom right to create a new peer. Give it a name, and paste the <code>PublicKey</code> value from the <code>[Peer]</code> section of your config file into the peer's <code>Public key</code> field. If you configured a pre-shared key when creating your tunnel, enter it in
the <code>Pre-shared key</code> field. Also copy in <code>Allowed IPs</code>, <code>Endpoint address</code>, <code>Endpoint port</code>, and <code>Keepalive interval</code> from the <code>[Peer]</code> section of your config file.

[[File:opnsense_populate_peer_endpoint.png|A side by side screenshot of the OPNsense peer configuration dialogue next to a WireGuard configuration file. Two red arrows indicate where to copy the endpoint IP and port from the config file to the OPNsense configuration dialogue.]]

[[File:opnsense_populate_peer_keepalive_addresses.png|A side by side screenshot of the OPNsense peer configuration dialogue next to a WireGuard configuration file. Red arrows indicate where to copy the public key, keepalive interval, and allowed IPs from the config file to the OPNsense configuration dialogue.]]

In the <code>Instances</code> field, use the drop-down menu to select the instance you created earlier in this tutorial.

Finally, save your peer, go back to the configuration for your instance, and add the peer you just created.

=== Activate Instance ===
On the instances page, ensure your instance is enabled, check the box to enable WireGuard, then apply your changes.

[[File:opnsense_enable_instance.png|A screenshot of the OPNsense WireGuard instances page, with the "Enable WireGuard" checkbox and enable instance checkbox highlighted with red rectangles.]]

Go to <code>WireGuard > Status</code> and ensure that both your instance and your peer display green checkmarks. If they do, you're good to go!

[[File:opnsense_wireguard_status.png|A screenshot of the OPNsense WireGuard status page. Both the interface and the peer show green checkmarks in the status column.]]

== Troubleshooting ==
=== Peer status displays a question mark ===
Minor misconfiguration of the peer can cause a question mark in the status page and a nonfunctional tunnel. Double check that the peer's configuration matches the WireGuard config file, and make sure your peer is configured with a /32. There are some places on 44Net Connect that are labeled in a confusing way and could be interpreted as your tunnel being allocated a /24, but a tunnel will always receive a /32.

44Net Connect/Quick Start/PFsense

2026-07-09T17:56:20Z

KN6DWI: Created Install WireGuard section

44Net Connect/Quick Start/PFsense

2026-07-09T17:17:10Z

KN6DWI: Created page

44Net Connect/Quick Start/OPNsense

2026-07-09T17:16:29Z

KN6DWI: Grammatical improvement

=== What you need ===
* A 44Net Portal account
* A verified amateur radio callsign
* A machine running OPNsense
* Some sort of Internet access

If you haven't set up your Portal account or verified your callsign yet, see [[GetStarted|44Net: Get Started]] for instructions. If you haven't obtained a WireGuard tunnel configuration file from 44Net Connect, get one using the [[44Net_Connect/Quick_Start|the 44Net Connect quick start guide]]

Unlike other Quick Start guides, we aren't starting with a configuration file from 44Net Connect. Instead, we will be creating one during the course of this tutorial.

== Generate a keypair in OPNsense ==
Navigate to <code>VPN > WireGuard > Instances</code> in your OPNsense web GUI and create a new instance. Click the gear button to generate a public key/private key keypair.

[[File:opnsense_keypair_generation.png|500px|A screenshot of the OPNsense edit instance dialogue, with the gear button next to the public key field circled in red.]]

== Create a tunnel in 44Net Connect ==
Open your [https://connect.44net.cloud/tunnels tunnels page in 44Net Connect] and click <code>Request a Tunnel</code>. Select your preferred server. In the <code>Public Key</code> field, paste the public key generated in OPNsense, then <code>Create Tunnel</code>. Save the wg-quick WireGuard config for use in later steps.

[[File:request_tunnel_44net_connect.png|A screenshot of the 44Net Connect tunnel page header with the Request Tunnel button highlighted in a red box]]

== Copy the tunnel details into OPNsense ==
=== Fill out instance ===
Go back to your OPNsense Web UI. Give your instance a name, and fill out the <code>Tunnel address</code> field with the addresses from the <code>[Interface]</code> section of the config. Check the <code>Disable routes</code> checkbox, then save your instance.

[[File:opnsense_populate_instance.png| A screenshot with a side by side view of a WireGuard config file and an OPNsense WireGuard instance configuration page. A red arrow indicates how to copy the tunnel addresses from the config file to the OPNsense configuration page. A red rectangle indicates that the user should check the "Disable Routes" box.]]

=== Fill out peer ===
Go to <code>VPN > WireGuard > Peers</code> in your OPNsense Web UI, and click the orange <code>+</code> button in the bottom right to create a new peer. Give it a name, and paste the <code>PublicKey</code> value from the <code>[Peer]</code> section of your config file into the peer's <code>Public key</code> field. If you configured a pre-shared key when creating your tunnel, enter it in
the <code>Pre-shared key</code> field. Also copy in <code>Allowed IPs</code>, <code>Endpoint address</code>, <code>Endpoint port</code>, and <code>Keepalive interval</code> from the <code>[Peer]</code> section of your config file.

[[File:opnsense_populate_peer_endpoint.png|A side by side screenshot of the OPNsense peer configuration dialogue next to a WireGuard configuration file. Two red arrows indicate where to copy the endpoint IP and port from the config file to the OPNsense configuration dialogue.]]

[[File:opnsense_populate_peer_keepalive_addresses.png|A side by side screenshot of the OPNsense peer configuration dialogue next to a WireGuard configuration file. Red arrows indicate where to copy the public key, keepalive interval, and allowed IPs from the config file to the OPNsense configuration dialogue.]]

In the <code>Instances</code> field, use the drop-down menu to select the instance you created earlier in this tutorial.

Finally, save your peer, go back to the configuration for your instance, and add the peer you just created.

=== Activate Instance ===
On the instances page, ensure your instance is enabled, check the box to enable WireGuard, then apply your changes.

[[File:opnsense_enable_instance.png|A screenshot of the OPNsense WireGuard instances page, with the "Enable WireGuard" checkbox and enable instance checkbox highlighted with red rectangles.]]

Go to <code>WireGuard > Status</code> and ensure that both your instance and your peer display green checkmarks. If they do, you're good to go!

[[File:opnsense_wireguard_status.png|A screenshot of the OPNsense WireGuard status page. Both the interface and the peer show green checkmarks in the status column.]]

== Troubleshooting ==
=== Peer status displays a question mark ===
Minor misconfiguration of the peer can cause a question mark in the status page and a nonfunctional tunnel. Double check that the peer's configuration matches the WireGuard config file, and make sure your peer is configured with a /32. There are some places on 44Net Connect that are labeled in a confusing way and could be interpreted as your tunnel being allocated a /24, but a tunnel will always receive a /32.

44Net Connect/Single Device Tunnel

2026-07-09T17:15:23Z

KN6DWI: Added link to PFsense quick start page

<div class="toclimit-3">
__TOC__
</div>
{{DISPLAYTITLE:Single Device Tunnel - 44Net Connect}}

This page discusses the single device tunnel configuration for connecting a device to 44Net via 44Net Connect.

== What is a single device tunnel? ==
A single device tunnel is a configuration where one device can send and receive traffic from its 44Net address via one of ARDC's endpoint nodes. This is done using a WireGuard tunnel, with a configuration file issued by [[44Net Connect]]. Each device connected in this manner is issued a single IPv4 address and a single IPv6 address, and it does not depend on a local gateway for connection to 44Net. A host using a single device tunnel may choose whether or not to route non-44Net traffic via the tunnel. Routing only 44Net traffic over the tunnel is a common configuration, and is called a "split tunnel."

[[File:Single_device_tunnel.png|600px]]

== When should I use a single device tunnel? ==
If you only have a few devices to manage, you are not comfortable with router and firewall configuration, or you're not sure where to start, a single device tunnel is a good choice. Mobile devices, such as phones and laptops, cannot rely on always being behind an appropriate gateway or router, so they work best with a single device tunnel.

Devices that cannot run WireGuard, such as some embedded devices, do not support a single device tunnel. These should be placed in a [[44Net_Connect/Routed_Subnet|routed subnet]] where the router connects them to 44Net.

== Tutorials ==
* [[44Net_Connect/Quick_Start/Debian_based_distributions|44Net Connect Quick Start: Debian-based distributions]]
* [[44Net_Connect/Quick_Start/Raspberry_Pi|44Net Connect Quick Start: Raspberry Pi]]
* [[44Net_Connect/Quick_Start/Fedora|44Net Connect Quick Start: Fedora]]
* [[44Net_Connect/Quick_Start/OPNsense|44Net Connect Quick Start: OPNsense]]
* [[44Net_Connect/Quick_Start/PFsense|44Net Connect Quick Start: PFsense]]

[[Category:Topology]]
[[Category:Participation Methods]]

44Net Connect/Quick Start/OPNsense

2026-07-08T17:37:24Z

KN6DWI: Added Activate Instance section and Troubleshooting section

=== What you need ===
* A 44Net Portal account
* A verified amateur radio callsign
* A machine running OPNsense
* Some sort of Internet access

If you haven't set up your Portal account or verified your callsign yet, see [[GetStarted|44Net: Get Started]] for instructions. If you haven't obtained a WireGuard tunnel configuration file from 44Net Connect, get one using the [[44Net_Connect/Quick_Start|the 44Net Connect quick start guide]]

Unlike the other Quick Start guides, we aren't starting with a configuration file from 44Net Connect. Instead, we will be creating one during the course of this tutorial.

== Generate a keypair in OPNsense ==
Navigate to <code>VPN > WireGuard > Instances</code> in your OPNsense web GUI and create a new instance. Click the gear button to generate a public key/private key keypair.

[[File:opnsense_keypair_generation.png|500px|A screenshot of the OPNsense edit instance dialogue, with the gear button next to the public key field circled in red.]]

== Create a tunnel in 44Net Connect ==
Open your [https://connect.44net.cloud/tunnels tunnels page in 44Net Connect] and click <code>Request a Tunnel</code>. Select your preferred server. In the <code>Public Key</code> field, paste the public key generated in OPNsense, then <code>Create Tunnel</code>. Save the wg-quick WireGuard config for use in later steps.

[[File:request_tunnel_44net_connect.png|A screenshot of the 44Net Connect tunnel page header with the Request Tunnel button highlighted in a red box]]

== Copy the tunnel details into OPNsense ==
=== Fill out instance ===
Go back to your OPNsense Web UI. Give your instance a name, and fill out the <code>Tunnel address</code> field with the addresses from the <code>[Interface]</code> section of the config. Check the <code>Disable routes</code> checkbox, then save your instance.

[[File:opnsense_populate_instance.png| A screenshot with a side by side view of a WireGuard config file and an OPNsense WireGuard instance configuration page. A red arrow indicates how to copy the tunnel addresses from the config file to the OPNsense configuration page. A red rectangle indicates that the user should check the "Disable Routes" box.]]

=== Fill out peer ===
Go to <code>VPN > WireGuard > Peers</code> in your OPNsense Web UI, and click the orange <code>+</code> button in the bottom right to create a new peer. Give it a name, and paste the <code>PublicKey</code> value from the <code>[Peer]</code> section of your config file into the peer's <code>Public key</code> field. If you configured a pre-shared key when creating your tunnel, enter it in
the <code>Pre-shared key</code> field. Also copy in <code>Allowed IPs</code>, <code>Endpoint address</code>, <code>Endpoint port</code>, and <code>Keepalive interval</code> from the <code>[Peer]</code> section of your config file.

[[File:opnsense_populate_peer_endpoint.png|A side by side screenshot of the OPNsense peer configuration dialogue next to a WireGuard configuration file. Two red arrows indicate where to copy the endpoint IP and port from the config file to the OPNsense configuration dialogue.]]

[[File:opnsense_populate_peer_keepalive_addresses.png|A side by side screenshot of the OPNsense peer configuration dialogue next to a WireGuard configuration file. Red arrows indicate where to copy the public key, keepalive interval, and allowed IPs from the config file to the OPNsense configuration dialogue.]]

In the <code>Instances</code> field, use the drop-down menu to select the instance you created earlier in this tutorial.

Finally, save your peer, go back to the configuration for your instance, and add the peer you just created.

=== Activate Instance ===
On the instances page, ensure your instance is enabled, check the box to enable WireGuard, then apply your changes.

[[File:opnsense_enable_instance.png|A screenshot of the OPNsense WireGuard instances page, with the "Enable WireGuard" checkbox and enable instance checkbox highlighted with red rectangles.]]

Go to <code>WireGuard > Status</code> and ensure that both your instance and your peer display green checkmarks. If they do, you're good to go!

[[File:opnsense_wireguard_status.png|A screenshot of the OPNsense WireGuard status page. Both the interface and the peer show green checkmarks in the status column.]]

== Troubleshooting ==
=== Peer status displays a question mark ===
Minor misconfiguration of the peer can cause a question mark in the status page and a nonfunctional tunnel. Double check that the peer's configuration matches the WireGuard config file, and make sure your peer is configured with a /32. There are some places on 44Net Connect that are labeled in a confusing way and could be interpreted as your tunnel being allocated a /24, but a tunnel will always receive a /32.

File:Opnsense wireguard status.png

2026-07-08T17:33:32Z

KN6DWI: A screenshot of the OPNsense WireGuard status page. Both the interface and the peer show green checkmarks in the status column.

== Summary ==
A screenshot of the OPNsense WireGuard status page. Both the interface and the peer show green checkmarks in the status column.

File:Opnsense enable instance.png

2026-07-08T17:26:20Z

KN6DWI: A screenshot of the OPNsense WireGuard instances page, with the "Enable WireGuard" checkbox and enable instance checkbox highlighted with red rectangles.

== Summary ==
A screenshot of the OPNsense WireGuard instances page, with the "Enable WireGuard" checkbox and enable instance checkbox highlighted with red rectangles.

44Net Connect/Routed Subnet/Raspberry Pi

2026-07-07T23:31:37Z

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

<div class="toclimit-3">
__TOC__
</div>
{{DISPLAYTITLE:44Net Connect Routed Subnet: Raspberry Pi}}

== Prerequisites ==
Set up a [[44Net_Connect/Quick_Start/Raspberry_Pi | 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 <code>/etc/wireguard/wg0.conf</code>, then your
interface name is <code>wg0</code>. The IP of your WireGuard interface can be obtained from running <code>ifconfig <interface></code> and finding the IP listed under the interface in the <code>inet</code> field.

Below is some example output of <code>ifconfig wg0</code>.

<nowiki>
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</nowiki>

== 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.

== Setting Up The Network Interface ==
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. This section has the steps that are required regardless of whether you're using ethernet or WiFi. If you're using WiFi, you'll also need the steps in the following section. Otherwise, you can skip them.

=== Step 1: Create a new connection in nmcli ===
<code>nmcli</code> 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.
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>.

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 ===
Set the IPv4 method to manual using the following command:

<code>sudo nmcli con modify <name> ipv4.method manual</code>

Next, set the IP range for this interface.

<code>sudo nmcli con modify <name> ipv4.address <subnet></code>

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 ==

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
<code>sudo raspi-config</code> and going to <code>Localisation Options > WLAN Country</code>. Select your country, confirm, and exit. If you're not sure whether you set the
wireless regulatory domain, run the command <code>sudo iw reg get</code>. Look at the country
set under <code>global</code>. If it says <code>unset</code>, you have not set the regulatory domain.

=== Step 2: Configure WiFi settings for your nmcli connection ===
Set the access point security and password. First, we set the <code>wifi-sec.key-mgmt</code> parameter to <code>wpa-psk</code> to disable the older insecure WEP encryption method. At this point, you will also need to set a password.

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

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

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. Disable it by setting <code>wifi-sec.proto</code> to <code>rsn</code>.

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

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.

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

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

<code>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></code>

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 ==
[https://www.isc.org/kea/ Kea] is the recommended DHCP server for setting up a routed subnet. <code>dhcpd</code> is deprecated as of 2022.

Install <code>kea</code> by running

<code>sudo apt install kea</code>.

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

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

<nowiki>
"Dhcp4": {
"interfaces-config": {
"interfaces": [ "eth1" ]
}
}
</nowiki>

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

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

=== Configure your subnet ===
<code>subnet4</code> 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 <code>pools</code>, and define at least one router in the <code>option-data</code> field. Comment out or delete the example DHCP reservations in the <code>reservations</code> field, since they're for the wrong subnet.

<nowiki>
"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.
]
]
</nowiki>

=== 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:

<nowiki>
"Dhcp4": {
// Add names of your network interfaces to listen on.
"interfaces-config": {
// See section 8.2.4 for more details. You probably want to add just
// interface name (e.g. "eth0" or specific IPv4 address on that
// interface name (e.g. "eth0/192.0.2.1").
"interfaces": ["eth1" ],

// max retries is set to int64 max as a workaround for kea not supporting
// hot plugging of interfaces.
"service-sockets-max-retries": 9223372036854775807,
"service-sockets-retry-wait-time": 2000
},

// The rest of this config is omitted for brevity.
}</nowiki>

== Setting up Routing ==
=== 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
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>

Next, reload your system configuration from config files by running <code>sudo sysctl --system</code>. Verify that IP forwarding has been successfully enabled
by running <code>sysctl net.ipv4.ip_forward</code>, which should print <code>net.ipv4.ip_forward = 1</code>. If the number is 0 instead of 1, IP forwarding has not been properly enabled, and you should check your drop-in file <code>/etc/sysctl.d/98-rpi.conf</code> for typos.

=== Add the routing rule ===
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. 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:

<code>ip route get 1.1.1.1 from <address> iif <subnet interface></code>

<code><address></code> should be replaced by an address in your subnet, and <code><subnet interface></code> with the interface your routed subnet clients are connected to. This command will attempt to find the route to 1.1.1.1 (Cloudflare's DNS server, an arbitrary test IP) from an IP in the routed subnet. The output should look like this:

<code>1.1.1.1 from <address> dev wg0 table 51820</code>

If the output indicates that there is no route to host, or that your route does not proceed via the WireGuard interface, you may have an issue with your routing configuration.

This routing rule will not persist between reboots. To make it persist, we can add it to the <code>systemd</code> unit created for the tunnel. After the existing <code>ExecStart</code> line, add another that executes the rule we just added. Immediately after that one, before the existing <code>ExecStop</code> line, add an
<code>ExecStop</code> line that deletes the rule. This is done by running <code>ip rule del</code> rather than <code>ip rule add</code>. Your unit should look something like this:

<nowiki>
[Unit]
Description=WireGuard single device 44Net Connect tunnel
Requires=network-online.target

[Service]
Type=oneshot
RemainAfterExit=true

# Edit these lines if your config file is named differently.
ExecStart=wg-quick up /etc/wireguard/wg0.conf
ExecStart=ip rule add from 44.27.45.129/29 lookup 51820
ExecStop=ip rule del from 44.27.45.129/29 lookup 51820
ExecStop=wg-quick down /etc/wireguard/wg0.conf

[Install]
WantedBy=multi-user.target</nowiki>

== 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. 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 ===
Run <code>ip rule show</code> and ensure that:
# The rule directing your routed subnet to the 51820 table exists
# That rule's priority is a lower number (and thus higher priority) than any other rules that would override it, such as the default rule <code>from all lookup main</code>

Next, inspect the table using <code>ip route show table 51820</code> and ensure that its default route is through the WireGuard interface.

44Net Connect/Quick Start/OPNsense

2026-07-07T22:53:36Z

KN6DWI: Added pictures for populating OPNsense peer page

=== What you need ===
* A 44Net Portal account
* A verified amateur radio callsign
* A machine running OPNsense
* Some sort of Internet access

If you haven't set up your Portal account or verified your callsign yet, see [[GetStarted|44Net: Get Started]] for instructions. If you haven't obtained a WireGuard tunnel configuration file from 44Net Connect, get one using the [[44Net_Connect/Quick_Start|the 44Net Connect quick start guide]]

Unlike the other Quick Start guides, we aren't starting with a configuration file from 44Net Connect. Instead, we will be creating one during the course of this tutorial.

== Generate a keypair in OPNsense ==
Navigate to <code>VPN > WireGuard > Instances</code> in your OPNsense web GUI and create a new instance. Click the gear button to generate a public key/private key keypair.

[[File:opnsense_keypair_generation.png|500px|A screenshot of the OPNsense edit instance dialogue, with the gear button next to the public key field circled in red.]]

== Create a tunnel in 44Net Connect ==
Open your [https://connect.44net.cloud/tunnels tunnels page in 44Net Connect] and click <code>Request a Tunnel</code>. Select your preferred server. In the <code>Public Key</code> field, paste the public key generated in OPNsense, then <code>Create Tunnel</code>. Save the wg-quick WireGuard config for use in later steps.

[[File:request_tunnel_44net_connect.png|A screenshot of the 44Net Connect tunnel page header with the Request Tunnel button highlighted in a red box]]

== Copy the tunnel details into OPNsense ==
=== Fill out instance ===
Go back to your OPNsense Web UI. Give your instance a name, and fill out the <code>Tunnel address</code> field with the addresses from the <code>[Interface]</code> section of the config. Check the <code>Disable routes</code> checkbox, then save your instance.

[[File:opnsense_populate_instance.png| A screenshot with a side by side view of a WireGuard config file and an OPNsense WireGuard instance configuration page. A red arrow indicates how to copy the tunnel addresses from the config file to the OPNsense configuration page. A red rectangle indicates that the user should check the "Disable Routes" box.]]

=== Fill out peer ===
Go to <code>VPN > WireGuard > Peers</code> in your OPNsense Web UI, and click the orange <code>+</code> button in the bottom right to create a new peer. Give it a name, and paste the <code>PublicKey</code> value from the <code>[Peer]</code> section of your config file into the peer's <code>Public key</code> field. If you configured a pre-shared key when creating your tunnel, enter it in
the <code>Pre-shared key</code> field. Also copy in <code>Allowed IPs</code>, <code>Endpoint address</code>, <code>Endpoint port</code>, and <code>Keepalive interval</code> from the <code>[Peer]</code> section of your config file.

[[File:opnsense_populate_peer_endpoint.png|A side by side screenshot of the OPNsense peer configuration dialogue next to a WireGuard configuration file. Two red arrows indicate where to copy the endpoint IP and port from the config file to the OPNsense configuration dialogue.]]

[[File:opnsense_populate_peer_keepalive_addresses.png|A side by side screenshot of the OPNsense peer configuration dialogue next to a WireGuard configuration file. Red arrows indicate where to copy the public key, keepalive interval, and allowed IPs from the config file to the OPNsense configuration dialogue.]]

In the <code>Instances</code> field, use the drop-down menu to select the instance you created earlier in this tutorial.

Finally, save your peer, go back to the configuration for your instance, and add the peer you just created.

File:Opnsense populate peer keepalive addresses.png

2026-07-07T22:52:43Z

KN6DWI: A side by side screenshot of the OPNsense peer configuration dialogue next to a WireGuard configuration file. Red arrows indicate where to copy the public key, keepalive interval, and allowed IPs from the config file to the OPNsense configuration dialogue.

== Summary ==
A side by side screenshot of the OPNsense peer configuration dialogue next to a WireGuard configuration file. Red arrows indicate where to copy the public key, keepalive interval, and allowed IPs from the config file to the OPNsense configuration dialogue.

File:Opnsense populate peer endpoint.png

2026-07-07T22:29:23Z

KN6DWI: A side by side screenshot of the OPNsense peer configuration dialogue next to a WireGuard configuration file. Two red arrows indicate where to copy the endpoint IP and port from the config file to the OPNsense configuration dialogue.

== Summary ==
A side by side screenshot of the OPNsense peer configuration dialogue next to a WireGuard configuration file. Two red arrows indicate where to copy the endpoint IP and port from the config file to the OPNsense configuration dialogue.

44Net Connect/Quick Start/OPNsense

2026-07-07T21:59:33Z

KN6DWI: Added image for filling out instance

File:Opnsense populate instance.png

2026-07-07T21:57:57Z

KN6DWI: A screenshot with a side by side view of a WireGuard config file and an OPNsense WireGuard instance configuration page. A red arrow indicates how to copy the tunnel addresses from the config file to the OPNsense configuration page. A red rectangle indicates that the user should check the "Disable Routes" box.

== Summary ==
A screenshot with a side by side view of a WireGuard config file and an OPNsense WireGuard instance configuration page. A red arrow indicates how to copy the tunnel addresses from the config file to the OPNsense configuration page. A red rectangle indicates that the user should check the "Disable Routes" box.

44Net Connect/Quick Start/OPNsense

2026-07-07T18:45:53Z

KN6DWI: Added caption to image

44Net Connect/Quick Start/OPNsense

2026-07-07T18:45:24Z

KN6DWI: Added picture for requesting a tunnel

File:Request tunnel 44net connect.png

2026-07-07T18:44:47Z

KN6DWI: Screenshot of the 44Net Connect tunnel page header with the Request Tunnel button highlighted in a red box.

== Summary ==
Screenshot of the 44Net Connect tunnel page header with the Request Tunnel button highlighted in a red box.

44Net Connect/Quick Start/OPNsense

2026-07-07T18:00:00Z

KN6DWI: Added screenshot for keypair generation

File:Opnsense keypair generation.png

2026-07-07T17:50:55Z

KN6DWI: A screenshot of the OPNsense Edit Instance dialogue with the button for generating a WireGuard keypair circled in red.

== Summary ==
A screenshot of the OPNsense Edit Instance dialogue with the button for generating a WireGuard keypair circled in red.

44Net Connect/Quick Start/OPNsense

2026-07-03T00:50:42Z

KN6DWI: Wrote section on copying tunnel details into OPNsense

44Net Connect/Quick Start/OPNsense

2026-07-02T23:51:50Z

KN6DWI: Changed section title

44Net Connect/Quick Start/OPNsense

2026-07-02T23:35:32Z

KN6DWI: Created page and what you need section

44Net Connect/Single Device Tunnel

2026-07-02T23:27:46Z

KN6DWI: Added link to OPNsense quick start page

<div class="toclimit-3">
__TOC__
</div>
{{DISPLAYTITLE:Single Device Tunnel - 44Net Connect}}

This page discusses the single device tunnel configuration for connecting a device to 44Net via 44Net Connect.

== What is a single device tunnel? ==
A single device tunnel is a configuration where one device can send and receive traffic from its 44Net address via one of ARDC's endpoint nodes. This is done using a WireGuard tunnel, with a configuration file issued by [[44Net Connect]]. Each device connected in this manner is issued a single IPv4 address and a single IPv6 address, and it does not depend on a local gateway for connection to 44Net. A host using a single device tunnel may choose whether or not to route non-44Net traffic via the tunnel. Routing only 44Net traffic over the tunnel is a common configuration, and is called a "split tunnel."

[[File:Single_device_tunnel.png|600px]]

== When should I use a single device tunnel? ==
If you only have a few devices to manage, you are not comfortable with router and firewall configuration, or you're not sure where to start, a single device tunnel is a good choice. Mobile devices, such as phones and laptops, cannot rely on always being behind an appropriate gateway or router, so they work best with a single device tunnel.

Devices that cannot run WireGuard, such as some embedded devices, do not support a single device tunnel. These should be placed in a [[44Net_Connect/Routed_Subnet|routed subnet]] where the router connects them to 44Net.

== Tutorials ==
* [[44Net_Connect/Quick_Start/Debian_based_distributions|44Net Connect Quick Start: Debian-based distributions]]
* [[44Net_Connect/Quick_Start/Raspberry_Pi|44Net Connect Quick Start: Raspberry Pi]]
* [[44Net_Connect/Quick_Start/Fedora|44Net Connect Quick Start: Fedora]]
* [[44Net_Connect/Quick_Start/OPNsense|44Net Connect Quick Start: OPNsense]]

[[Category:Topology]]
[[Category:Participation Methods]]

44Net Connect/Routed Subnet/Raspberry Pi

2026-06-30T23:09:10Z

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

<div class="toclimit-3">
__TOC__
</div>
{{DISPLAYTITLE:44Net Connect Routed Subnet: Raspberry Pi}}

== Prerequisites ==
Set up a [[44Net_Connect/Quick_Start/Raspberry_Pi | 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 <code>/etc/wireguard/wg0.conf</code>, then your
interface name is <code>wg0</code>. The IP of your WireGuard interface can be obtained from running <code>ifconfig <interface></code> and finding the IP listed under the interface in the <code>inet</code> field.

Below is some example output of <code>ifconfig wg0</code>.

<nowiki>
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</nowiki>

== 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.

== Setting Up The Network Interface ==
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. This section has the steps that are required regardless of whether you're using ethernet or WiFi. If you're using WiFi, you'll also need the steps in the following section. Otherwise, you can skip them.

=== Step 1: Create a new connection in nmcli ===
<code>nmcli</code> 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.
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>.

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 ===
Set the IPv4 method to manual using the following command:

<code>sudo nmcli con modify <name> ipv4.method manual</code>

Next, set the IP range for this interface.

<code>sudo nmcli con modify <name> ipv4.address <subnet></code>

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 ==

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
<code>sudo raspi-config</code> and going to <code>Localisation Options > WLAN Country</code>. Select your country, confirm, and exit. If you're not sure whether you set the
wireless regulatory domain, run the command <code>sudo iw reg get</code>. Look at the country
set under <code>global</code>. If it says <code>unset</code>, you have not set the regulatory domain.

=== Step 2: Configure WiFi settings for your nmcli connection ===
Set the access point security and password. First, we set the <code>wifi-sec.key-mgmt</code> parameter to <code>wpa-psk</code> to disable the older insecure WEP encryption method. At this point, you will also need to set a password.

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

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

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. Disable it by setting <code>wifi-sec.proto</code> to <code>rsn</code>.

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

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.

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

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

<code>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></code>

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 ==
[https://www.isc.org/kea/ Kea] is the recommended DHCP server for setting up a routed subnet. <code>dhcpd</code> is deprecated as of 2022.

Install <code>kea</code> by running

<code>sudo apt install kea</code>.

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

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

<nowiki>
"Dhcp4": {
"interfaces-config": {
"interfaces": [ "eth1" ]
}
}
</nowiki>

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

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

=== Configure your subnet ===
<code>subnet4</code> 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 <code>pools</code>, and define at least one router in the <code>option-data</code> field. Comment out or delete the example DHCP reservations in the <code>reservations</code> field, since they're for the wrong subnet.

<nowiki>
"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.
]
]
</nowiki>

=== 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:

<nowiki>
"Dhcp4": {
// Add names of your network interfaces to listen on.
"interfaces-config": {
// See section 8.2.4 for more details. You probably want to add just
// interface name (e.g. "eth0" or specific IPv4 address on that
// interface name (e.g. "eth0/192.0.2.1").
"interfaces": ["eth1" ],

// max retries is set to int64 max as a workaround for kea not supporting
// hot plugging of interfaces.
"service-sockets-max-retries": 9223372036854775807,
"service-sockets-retry-wait-time": 2000
},

// The rest of this config is omitted for brevity.
}</nowiki>

== Setting up Routing ==
=== 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
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>

Next, reload your system configuration from config files by running <code>sudo sysctl --system</code>. Verify that IP forwarding has been successfully enabled
by running <code>sysctl net.ipv4.ip_forward</code>, which should print <code>net.ipv4.ip_forward = 1</code>. If the number is 0 instead of 1, IP forwarding has not been properly enabled, and you should check your drop-in file <code>/etc/sysctl.d/98-rpi.conf</code> for typos.

=== Add the routing rule ===
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.

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

<code>ip route get 1.1.1.1 from <address> iif <subnet interface></code>

<code><address></code> should be replaced by an address in your subnet, and <code><subnet interface></code> with the interface your routed subnet clients are connected to. This command will attempt to find the route to 1.1.1.1 (Cloudflare's DNS server, an arbitrary test IP) from an IP in the routed subnet. The output should look like this:

<code>1.1.1.1 from <address> dev wg0 table 51820</code>

If the output indicates that there is no route to host, or that your route does not proceed via the WireGuard interface, you may have an issue with your routing configuration.

This routing rule will not persist between reboots. To make it persist, we can add it to the <code>systemd</code> unit created for the tunnel. After the existing <code>ExecStart</code> line, add another that executes the rule we just added. Immediately after that one, before the existing <code>ExecStop</code> line, add an
<code>ExecStop</code> line that deletes the rule. This is done by running <code>ip rule del</code> rather than <code>ip rule add</code>. Your unit should look something like this:

<nowiki>
[Unit]
Description=WireGuard single device 44Net Connect tunnel
Requires=network-online.target

[Service]
Type=oneshot
RemainAfterExit=true

# Edit these lines if your config file is named differently.
ExecStart=wg-quick up /etc/wireguard/wg0.conf
ExecStart=ip rule add from 44.27.45.129/29 lookup 51820
ExecStop=ip rule del from 44.27.45.129/29 lookup 51820
ExecStop=wg-quick down /etc/wireguard/wg0.conf

[Install]
WantedBy=multi-user.target</nowiki>

== 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. 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 ===
Run <code>ip rule show</code> and ensure that:
# The rule directing your routed subnet to the 51820 table exists
# That rule's priority is a lower number (and thus higher priority) than any other rules that would override it, such as the default rule <code>from all lookup main</code>

Next, inspect the table using <code>ip route show table 51820</code> and ensure that its default route is through the WireGuard interface.

44Net Connect/Routed Subnet/Debian based distributions

2026-06-30T23:08:33Z

KN6DWI: Pasted in troubleshooting section

== Prerequisites ==
Set up a [[44Net_Connect/Quick_Start/Debian_based_distributions | single-device tunnel to your machine]].
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 <code>/etc/wireguard/wg0.conf</code>, then your
interface name is <code>wg0</code>. The IP of your WireGuard interface can be obtained from running <code>ifconfig <interface></code> and finding the IP listed under the interface in the <code>inet</code> field.

Below is some example output of <code>ifconfig wg0</code>.

<nowiki>
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</nowiki>

== 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.

== Setting Up The Network Interface ==
The recommended way to set up the router for your subnet is with two ethernet interfaces. The second can be provided by a USB ethernet adapter if necessary. This section has the steps that are required regardless of whether you're using ethernet or WiFi. If you're using WiFi, you'll also need the steps in the following section. Otherwise, you can skip them.

=== Step 1: Create a new connection in nmcli ===
<code>nmcli</code> is the CLI interface for NetworkManager, which is the high level network configuration tool included in most Debian-based distributions by default. These configuration steps can be completed using the NetworkManager GUI, but many people operate a "headless" machine (without a screen or keyboard) and use SSH to remotely configure it. Thus, this tutorial uses a CLI tool to accommodate that use case.
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>.

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 ===
Set the IPv4 method to manual using the following command:

<code>sudo nmcli con modify <name> ipv4.method manual</code>

Next, set the IP range for this interface.

<code>sudo nmcli con modify <name> ipv4.address <subnet></code>

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 Debian machine 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 ==

If you have wireless only clients, or wish to utilize an existing WiFi interface in lieu of an additional ethernet interface, you can configure the interface 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 device will use the right ones, making it work best with nearby devices and ensuring regulatory compliance.

Your regulatory domain may have already been set during OS installation. Run
<code>sudo iw reg get</code> to check whether it's been set. Look at the country set under <code>global</code>. If it says <code>unset</code>, you have not set the regulatory domain.

If your regulatory domain has not been set, set it with <code>sudo iw reg set <country code></code> where the country code is your [https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2 two letter ISO country code].

=== Step 2: Configure WiFi settings for your nmcli connection ===
Set the access point security and password. First, we set the <code>wifi-sec.key-mgmt</code> parameter to <code>wpa-psk</code> to disable the older insecure WEP encryption method. At this point, you will also need to set a password.

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

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

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. Disable it by setting <code>wifi-sec.proto</code> to <code>rsn</code>.

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

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.

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

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

<code>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></code>

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 device 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 ==
[https://www.isc.org/kea/ Kea] is the recommended DHCP server for setting up a routed subnet. <code>dhcpd</code> is deprecated as of 2022.

Install <code>kea</code> by running

<code>sudo apt install kea</code>.

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

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

<nowiki>
"Dhcp4": {
"interfaces-config": {
"interfaces": [ "eth1" ]
}
}
</nowiki>

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

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

=== Configure your subnet ===
<code>subnet4</code> 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 <code>pools</code>, and define at least one router in the <code>option-data</code> field. Comment out or delete the example DHCP reservations in the <code>reservations</code> field, since they're for the wrong subnet.

<nowiki>
"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.
]
]
</nowiki>

=== 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:

<nowiki>
"Dhcp4": {
// Add names of your network interfaces to listen on.
"interfaces-config": {
// See section 8.2.4 for more details. You probably want to add just
// interface name (e.g. "eth0" or specific IPv4 address on that
// interface name (e.g. "eth0/192.0.2.1").
"interfaces": ["eth1" ],

// max retries is set to int64 max as a workaround for kea not supporting
// hot plugging of interfaces.
"service-sockets-max-retries": 9223372036854775807,
"service-sockets-retry-wait-time": 2000
},

// The rest of this config is omitted for brevity.
}</nowiki>

== Setting up Routing ==
=== 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>, or create one and add this line. It's customary to prefix drop-in file names with a number indicating their priority.
Editing or creating the drop-in file will require superuser privileges. For example:

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

Next, reload your system configuration from config files by running <code>sudo sysctl --system</code>. Verify that IP forwarding has been successfully enabled
by running <code>sysctl net.ipv4.ip_forward</code>, which should print <code>net.ipv4.ip_forward = 1</code>. If the number is 0 instead of 1, IP forwarding has not been properly enabled, and you should check your drop-in file for typos.

=== Add the routing rule ===
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.

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

<code>ip route get 1.1.1.1 from <address> iif <subnet interface></code>

<code><address></code> should be replaced by an address in your subnet, and <code><subnet interface></code> with the interface your routed subnet clients are connected to. This command will attempt to find the route to 1.1.1.1 (Cloudflare's DNS server, an arbitrary test IP) from an IP in the routed subnet. The output should look like this:

<code>1.1.1.1 from <address> dev wg0 table 51820</code>

If the output indicates that there is no route to host, or that your route does not proceed via the WireGuard interface, you may have an issue with your routing configuration.

This routing rule will not persist between reboots. To make it persist, we can add it to the <code>systemd</code> unit created for the tunnel. After the existing <code>ExecStart</code> line, add another that executes the rule we just added. Immediately after that one, before the existing <code>ExecStop</code> line, add an
<code>ExecStop</code> line that deletes the rule. This is done by running <code>ip rule del</code> rather than <code>ip rule add</code>. Your unit should look something like this:

<nowiki>
[Unit]
Description=WireGuard single device 44Net Connect tunnel
Requires=network-online.target

[Service]
Type=oneshot
RemainAfterExit=true

# Edit these lines if your config file is named differently.
ExecStart=wg-quick up /etc/wireguard/wg0.conf
ExecStart=ip rule add from 44.27.45.129/29 lookup 51820
ExecStop=ip rule del from 44.27.45.129/29 lookup 51820
ExecStop=wg-quick down /etc/wireguard/wg0.conf

[Install]
WantedBy=multi-user.target</nowiki>

== 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. 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 ===
Run <code>ip rule show</code> and ensure that:
# The rule directing your routed subnet to the 51820 table exists
# That rule's priority is a lower number (and thus higher priority) than any other rules that would override it, such as the default rule <code>from all lookup main</code>

Next, inspect the table using <code>ip route show table 51820</code> and ensure that its default route is through the WireGuard interface.

44Net Connect/Routed Subnet/Debian based distributions

2026-06-30T23:06:34Z

KN6DWI: Filled out the section on setting up routing

44Net Connect/Routed Subnet/Raspberry Pi

2026-06-30T23:01:33Z

KN6DWI: Added missing space

<div class="toclimit-3">
__TOC__
</div>
{{DISPLAYTITLE:44Net Connect Routed Subnet: Raspberry Pi}}

== Prerequisites ==
Set up a [[44Net_Connect/Quick_Start/Raspberry_Pi | 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 <code>/etc/wireguard/wg0.conf</code>, then your
interface name is <code>wg0</code>. The IP of your WireGuard interface can be obtained from running <code>ifconfig <interface></code> and finding the IP listed under the interface in the <code>inet</code> field.

Below is some example output of <code>ifconfig wg0</code>.

<nowiki>
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</nowiki>

== 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.

== Setting Up The Network Interface ==
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. This section has the steps that are required regardless of whether you're using ethernet or WiFi. If you're using WiFi, you'll also need the steps in the following section. Otherwise, you can skip them.

=== Step 1: Create a new connection in nmcli ===
<code>nmcli</code> 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.
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>.

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 ===
Set the IPv4 method to manual using the following command:

<code>sudo nmcli con modify <name> ipv4.method manual</code>

Next, set the IP range for this interface.

<code>sudo nmcli con modify <name> ipv4.address <subnet></code>

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 ==

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
<code>sudo raspi-config</code> and going to <code>Localisation Options > WLAN Country</code>. Select your country, confirm, and exit. If you're not sure whether you set the
wireless regulatory domain, run the command <code>sudo iw reg get</code>. Look at the country
set under <code>global</code>. If it says <code>unset</code>, you have not set the regulatory domain.

=== Step 2: Configure WiFi settings for your nmcli connection ===
Set the access point security and password. First, we set the <code>wifi-sec.key-mgmt</code> parameter to <code>wpa-psk</code> to disable the older insecure WEP encryption method. At this point, you will also need to set a password.

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

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

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. Disable it by setting <code>wifi-sec.proto</code> to <code>rsn</code>.

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

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.

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

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

<code>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></code>

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 ==
[https://www.isc.org/kea/ Kea] is the recommended DHCP server for setting up a routed subnet. <code>dhcpd</code> is deprecated as of 2022.

Install <code>kea</code> by running

<code>sudo apt install kea</code>.

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

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

<nowiki>
"Dhcp4": {
"interfaces-config": {
"interfaces": [ "eth1" ]
}
}
</nowiki>

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

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

=== Configure your subnet ===
<code>subnet4</code> 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 <code>pools</code>, and define at least one router in the <code>option-data</code> field. Comment out or delete the example DHCP reservations in the <code>reservations</code> field, since they're for the wrong subnet.

<nowiki>
"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.
]
]
</nowiki>

=== 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:

<nowiki>
"Dhcp4": {
// Add names of your network interfaces to listen on.
"interfaces-config": {
// See section 8.2.4 for more details. You probably want to add just
// interface name (e.g. "eth0" or specific IPv4 address on that
// interface name (e.g. "eth0/192.0.2.1").
"interfaces": ["eth1" ],

// max retries is set to int64 max as a workaround for kea not supporting
// hot plugging of interfaces.
"service-sockets-max-retries": 9223372036854775807,
"service-sockets-retry-wait-time": 2000
},

// The rest of this config is omitted for brevity.
}</nowiki>

== Setting up Routing ==
=== 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
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>

Next, reload your system configuration from config files by running <code>sudo sysctl --system</code>. Verify that IP forwarding has been successfully enabled
by running <code>sysctl net.ipv4.ip_forward</code>, which should print <code>net.ipv4.ip_forward = 1</code>. If the number is 0 instead of 1, IP forwarding has not been properly enabled, and you should check your drop-in file <code>/etc/sysctl.d/98-rpi.conf</code> for typos.

=== Add the routing rule ===
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.

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

<code>ip route get 1.1.1.1 from <address> iif <subnet interface></code>

<code><address></code> should be replaced by an address in your subnet, and <code><subnet interface></code> with the interface your routed subnet clients are connected to. This command will attempt to find the route to 1.1.1.1 (Cloudflare's DNS server, an arbitrary test IP) from an IP in the routed subnet. The output should look like this:

<code>1.1.1.1 from <address> dev wg0 table 51820</code>

If the output indicates that there is no route to host, or that your route does not proceed via the WireGuard interface, you may have an issue with your routing configuration.

This routing rule will not persist between reboots. To make it persist, we can add it to the <code>systemd</code> unit created for the tunnel. After the existing <code>ExecStart</code> line, add another that executes the rule we just added. Immediately after that one, before the existing <code>ExecStop</code> line, add an
<code>ExecStop</code> line that deletes the rule. This is done by running <code>ip rule del</code> rather than <code>ip rule add</code>. Your unit should look something like this:

<nowiki>
[Unit]
Description=WireGuard single device 44Net Connect tunnel
Requires=network-online.target

[Service]
Type=oneshot
RemainAfterExit=true

# Edit these lines if your config file is named differently.
ExecStart=wg-quick up /etc/wireguard/wg0.conf
ExecStart=ip rule add from 44.27.45.129/29 lookup 51820
ExecStop=ip rule del from 44.27.45.129/29 lookup 51820
ExecStop=wg-quick down /etc/wireguard/wg0.conf

[Install]
WantedBy=multi-user.target</nowiki>

== 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.

=== Clients cannot find route to hosts ===
Run <code>ip rule show</code> and ensure that:
# The rule directing your routed subnet to the 51820 table exists
# That rule's priority is a lower number (and thus higher priority) than any other rules that would override it, such as the default rule <code>from all lookup main</code>

Next, inspect the table using <code>ip route show table 51820</code> and ensure that its default route is through the WireGuard interface.

44Net Connect/Routed Subnet/Debian based distributions

2026-06-30T18:47:56Z

KN6DWI: Pasted in section on configuring DHCP

44Net Connect/Routed Subnet/Debian based distributions

2026-06-30T18:45:55Z

KN6DWI: Filled out section on configuring WiFi interface for access point mode

44Net Connect/Routed Subnet/Raspberry Pi

2026-06-30T18:29:02Z

KN6DWI: Grammatical fix

<div class="toclimit-3">
__TOC__
</div>
{{DISPLAYTITLE:44Net Connect Routed Subnet: Raspberry Pi}}

== Prerequisites ==
Set up a [[44Net_Connect/Quick_Start/Raspberry_Pi | 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 <code>/etc/wireguard/wg0.conf</code>, then your
interface name is <code>wg0</code>. The IP of your WireGuard interface can be obtained from running <code>ifconfig <interface></code> and finding the IP listed under the interface in the <code>inet</code> field.

Below is some example output of <code>ifconfig wg0</code>.

<nowiki>
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</nowiki>

== 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.

== Setting Up The Network Interface ==
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. This section has the steps that are required regardless of whether you're using ethernet or WiFi. If you're using WiFi, you'll also need the steps in the following section. Otherwise, you can skip them.

=== Step 1: Create a new connection in nmcli ===
<code>nmcli</code> 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.
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>.

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 ===
Set the IPv4 method to manual using the following command:

<code>sudo nmcli con modify <name> ipv4.method manual</code>

Next, set the IP range for this interface.

<code>sudo nmcli con modify <name> ipv4.address <subnet></code>

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 ==

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
<code>sudo raspi-config</code> and going to <code>Localisation Options > WLAN Country</code>. Select your country, confirm, and exit. If you're not sure whether you set the
wireless regulatory domain, run the command <code>sudo iw reg get</code>. Look at the country
set under <code>global</code>. If it says <code>unset</code>, you have not set the regulatory domain.

=== Step 2: Configure WiFi settings for your nmcli connection ===
Set the access point security and password. First, we set the <code>wifi-sec.key-mgmt</code> parameter to <code>wpa-psk</code> to disable the older insecure WEP encryption method. At this point, you will also need to set a password.

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

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

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. Disable it by setting <code>wifi-sec.proto</code> to <code>rsn</code>.

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

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.

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

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

<code>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></code>

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 ==
[https://www.isc.org/kea/ Kea] is the recommended DHCP server for setting up a routed subnet. <code>dhcpd</code> is deprecated as of 2022.

Install <code>kea</code> by running

<code>sudo apt install kea</code>.

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

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

<nowiki>
"Dhcp4": {
"interfaces-config": {
"interfaces": [ "eth1" ]
}
}
</nowiki>

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

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

=== Configure your subnet ===
<code>subnet4</code> 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 <code>pools</code>, and define at least one router in the <code>option-data</code> field. Comment out or delete the example DHCP reservations in the <code>reservations</code> field, since they're for the wrong subnet.

<nowiki>
"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.
]
]
</nowiki>

=== 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:

<nowiki>
"Dhcp4": {
// Add names of your network interfaces to listen on.
"interfaces-config": {
// See section 8.2.4 for more details. You probably want to add just
// interface name (e.g. "eth0" or specific IPv4 address on that
// interface name (e.g. "eth0/192.0.2.1").
"interfaces": ["eth1" ],

// max retries is set to int64 max as a workaround for kea not supporting
// hot plugging of interfaces.
"service-sockets-max-retries": 9223372036854775807,
"service-sockets-retry-wait-time": 2000
},

// The rest of this config is omitted for brevity.
}</nowiki>

== Setting up Routing ==
=== 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
add the line to thatfile using your editor of choice. It will require superuser privileges. For example:

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

Next, reload your system configuration from config files by running <code>sudo sysctl --system</code>. Verify that IP forwarding has been successfully enabled
by running <code>sysctl net.ipv4.ip_forward</code>, which should print <code>net.ipv4.ip_forward = 1</code>. If the number is 0 instead of 1, IP forwarding has not been properly enabled, and you should check your drop-in file <code>/etc/sysctl.d/98-rpi.conf</code> for typos.

=== Add the routing rule ===
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.

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

<code>ip route get 1.1.1.1 from <address> iif <subnet interface></code>

<code><address></code> should be replaced by an address in your subnet, and <code><subnet interface></code> with the interface your routed subnet clients are connected to. This command will attempt to find the route to 1.1.1.1 (Cloudflare's DNS server, an arbitrary test IP) from an IP in the routed subnet. The output should look like this:

<code>1.1.1.1 from <address> dev wg0 table 51820</code>

If the output indicates that there is no route to host, or that your route does not proceed via the WireGuard interface, you may have an issue with your routing configuration.

This routing rule will not persist between reboots. To make it persist, we can add it to the <code>systemd</code> unit created for the tunnel. After the existing <code>ExecStart</code> line, add another that executes the rule we just added. Immediately after that one, before the existing <code>ExecStop</code> line, add an
<code>ExecStop</code> line that deletes the rule. This is done by running <code>ip rule del</code> rather than <code>ip rule add</code>. Your unit should look something like this:

<nowiki>
[Unit]
Description=WireGuard single device 44Net Connect tunnel
Requires=network-online.target

[Service]
Type=oneshot
RemainAfterExit=true

# Edit these lines if your config file is named differently.
ExecStart=wg-quick up /etc/wireguard/wg0.conf
ExecStart=ip rule add from 44.27.45.129/29 lookup 51820
ExecStop=ip rule del from 44.27.45.129/29 lookup 51820
ExecStop=wg-quick down /etc/wireguard/wg0.conf

[Install]
WantedBy=multi-user.target</nowiki>

== 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.

=== Clients cannot find route to hosts ===
Run <code>ip rule show</code> and ensure that:
# The rule directing your routed subnet to the 51820 table exists
# That rule's priority is a lower number (and thus higher priority) than any other rules that would override it, such as the default rule <code>from all lookup main</code>

Next, inspect the table using <code>ip route show table 51820</code> and ensure that its default route is through the WireGuard interface.

44Net Connect/Routed Subnet/Debian based distributions

2026-06-30T18:28:04Z

KN6DWI: Removed extra new line

44Net Connect/Routed Subnet/Debian based distributions

2026-06-30T18:27:39Z

KN6DWI: Copied in prerequisite section through network interface setup

44Net Connect/Routed Subnet

2026-06-30T17:51:38Z

KN6DWI: Added link to Debian-based distros page

== What is a routed subnet? ==
A routed subnet is a group of devices that are placed behind a router that directs traffic to their 44Net IP addresses. The router is provided with a WireGuard tunnel configuration that connects it to one of ARDC's nodes. In a typical routed subnet, all traffic from the devices in the subnet is routed through 44Net via the router. Devices do not have individual control over which traffic is proxied through the 44Net node. The router with the tunnel is in control of this.

[[File:Routed_subnet.png|600px]]

== When should I use a routed subnet? ==
If you have many devices to manage, or one of your devices is not capable of running WireGuard, a routed subnet is a good choice. A routed subnet eliminates the complexity of managing configuration for many individual devices, since there is only the router's configuration.

In some applications, it is important that all traffic associated with a service appear to come from the same public address. In those cases, a full-tunnel configuration or a gateway model may be more appropriate than per-host split tunneling.

== Tutorials ==
* [[44Net_Connect/Routed_Subnet/Raspberry_Pi | Raspberry Pi]]
* [[44Net_Connect/Routed_Subnet/Debian_based_distributions | Debian-based distributions]]

[[Category:Topology]]
[[Category:Participation Methods]]