What’s 44Net?
44Net is simply a collection of IP version 4 addresses on the public internet. The 44.0.0.0/9 and 44.128.0.0/10 networks are put aside strictly for amateur radio use and are managed by the ARDC, or Amateur Radio Digital Communications for the exclusive use of hams worldwide. The ARDC sold a block of this address space back in 2019 to fund grants for amateur radio projects, including a major shack upgrade at Michigan State University and for infrastructure on the Central Michigan Emergency Network, among others.
I already have internet at my house. What does 44Net allow that’s different?
Address space in the version 4 specification of IP has long been used up. With each average household using a dozen or more addresses for phones, TVs, laptops, smart lightbulbs and much more, we’ve had to resort to two things: IP version 6 uses a much larger address space, but the addresses are very long and not every device supports it. For those that needed to stick to version 4, we’ve been using NAT, or Network Address Translation, to use a single IP address across every device in a home.
44Net has a wide range of usable IP space that’s only available to ham radio operators and networks. By keeping corporations out of that address space, each ham can have an individual address for each of their ham-related devices. Why is that important?
When we have a REAL public IP address, we don’t have to perform all these “hacks” to get multiple computers to use the same space. That means you can run multiple of the same service on your network without having to screw around with port forwarding and convoluted firewall settings. For example, Echolink only allows one connection per IP address. In your home, that currently means that only one person with one device can be on Echolink at a time. With 44Net addresses for each device, that restriction is lifted. This also means you could have multiple AllStarLink nodes, multiple packet nodes, ham radio related websites, and whatever other internet-ham related things you can think of, all on your own home network.
This ALSO, however, means that each individual computer using a 44.x.x.x address is also exposed to the negative aspects of the public internet, like folks attempting to take control of your computer for nefarious purposes. That means you need to have enough knowledge to properly protect yourself, somewhat unlike the cable or fiber connection to your regular internet provider where they take care of much of that for you.
In short: 44Net is a free and unencumbered IPv4 internet experience that’s great for hosting services to the rest of the amateur radio community.
So what’s 44Net-Connect?
In the past, each individual ham operator who wanted to use 44.x.x.x network addresses had to jump through a lot of hoops (BGP, IPIP Mesh, etc) in order to connect and advertise their address space to the rest of the public internet. This meant that the technical knowledge required to pull it off was often overwhelming.
44Net Connect is a new (as of 2026) way to connect with the greater 44 network address space that just involves using a Wireguard VPN, a very common type of connection often used with businesses, advanced homelab users, and privacy-focused VPN providers. If all you want to do is acquire a 44.x.x.x address to use for a single computer, there’s nothing you need to do except to request and set up this type of connection. You’ll get a single 44Net address to use as you see fit.
If you want to run a series of these addresses on the same network, that’s a little bit more involved. We’ll go over both scenarios.
Let’s grab a 44Net-Connect tunnel (VPN) for a single IP address.
If you only need a single IP address or you want to keep the complexity of this process to a minimum, follow this section. If you want to use a whole subnet allocation of 44.x.x.x addresses, skip to the ADVANCED section after requesting your tunnel.
Head over to https://connect.44net.cloud/ and log in. If you don’t already have an account, create one and follow any instructions for validating your amateur radio callsign.

In the Dashboard on the left bar, click MY RESOURCES, then Tunnels.

Request a new tunnel.

Select the server closest to your location from a network latency standpoint. If you select purely based on physical distance, you may not have the network performance you expect. Also try to choose a server with the least amount of tunnels, since that will be less congested.

Fill out the tunnel name. Leave the “Public Key” and “Preshared Key” blank unless you have experience with using your own. Don’t worry about “Adding Extra IPs” for now.

Save Changes.

You’re all set to use your new tunnel! Just copy/paste the wg-quick configuration into a text file then import into your Wireguard installation for your particular platform.
If you want to use a whole subnet allocation of 44.x.x.x addresses, skip to the ADVANCED section NOW.
Since we’re going to focus on getting a little more out of this connection, let’s quickly go over how to configure Wireguard on a modern Linux system. In my case, I chose Ubuntu 24.04 Server. The directions for any Linux platform will be similar.
First, make sure your system is up-to-date:
# sudo apt update && sudo apt upgrade -y
Now let’s grab Wireguard and a couple other useful tools:
# sudo apt install net-tools wireguard mtr
Next, let’s create the Wireguard configuration file that will be used to enable the VPN tunnel and utilize your single 44.x.x.x IP address:
# sudo nano /etc/wireguard/44net-connect.conf
Paste your configuration from 44Net-Connect into this file. Save and Exit.
Let’s start it!
# wg-quick up 44net-connect
Check to see if the interface is up and running with “ifconfig”:

You should see your new public 44.x.x.x IP in the output like above. Now let’s test it:
# mtr google.com

On the top line, note your IP address. Verify it’s on the 44 network. Now let’s make sure this connection automatically reconnects after a power cycle or reboot:
# systemctl enable wg-quick@44net-connect.service
# systemctl daemon-reload
Go ahead and reboot to test. Rerun the “mtr” command to verify. Ping a few websites like portal.ardc.org, google.com, or others to ensure wide connectivity with the greater internet.
That’s it! You’re now connected to the ham-internet and the wider public internet with 44Net Connect!
WARNING!!!!!!!!!
You are now connected to the PUBLIC internet with absolutely no safety net in place. Things that used to protect you are no longer doing so, like your internet company firewall, or NAT (network address translation). You absolutely MUST build your own firewall on each public machine using this above 44Net Connect method!
Doing this is beyond the scope of this document, however, on some platforms it can be rather simple, like enabling Windows Defender Firewall on any Windows 10 or 11 machines, installing a firewall app on your Android phone, or enabling the firewall on your MacOS system. On Linux, you’d better just know what you’re doing.
Very briefly, on Linux:
# sudo apt install ufw
then enable the firewall:
# ufw enable
This will by default allow any outgoing connection and BLOCK any incoming connections. You will need to do some reading about how to enable incoming connections for certain services. For example, to allow incoming AllStarLink connections to your node:
# ufw allow 4569/udp
Or to allow SSH connections:
# ufw allow ssh
After each change, you must reload “ufw” for it to take effect:
# ufw reload
There are a million different ways to do the same thing with “ufw”, so take the time to read from the following resources:
https://blog.rtsp.us/ufw-uncomplicated-firewall-cheat-sheet-a9fe61933330
https://ni2o.ampr.org/documents/UFW%20rules%20for%20AMPR%20VPN%20.pdf
https://manpages.ubuntu.com/manpages/focal/man8/ufw.8.html
Advanced: Run your own 44Net Subnet with the VPN and Proxmox.
This next section is completely optional and requires a few things. First, we’re going to create a dedicated 44Net network and a new LXC in Proxmox. Next, we’re going to configure the LXC as a Linux router, just like your home or business router hardware. This will allow multiple devices on your network to access 44.x.x.x IP addresses with only a single VPN tunnel, and to talk back and forth with each other AND your home network without having to go back out over the VPN tunnel to do so.
This guide assumes the following:
- Basic networking experience
- Basic modern Linux OS experience
- Proxmox 9 or higher installed
- Knowledge of how to make containers and networks in Proxmox
- A downloaded LXC template for Debian 13 or Ubuntu 24.04 or newer
- A free and available NIC if you want to use your new network on physical computers outside of VMs and containers
Request a 44Net subnet in 44Net Connect and apply it to the tunnel
Under MY RESOURCES > Networks, select Request Network Allocation.

Select a pool to request a a subnet from.

Name your network and select an appropriate subnet size. a /29 network is often a reasonable starting point for experimentation. This will give you a total of 5 usable 44.x.x.x IPs for your projects. Don’t forget that if you grow beyond that allocation, you can request more later. No need to unnecessarily tie up resources.
It may take a while to get this new allocation approved. Periodically check back to see if it’s been approved under “My Requests”.
Back under MY RESOURCES > Tunnels, edit your previously created tunnel, or make a new one.

Under “Route additional Networks Through This Tunnel”, select “Static” for the Routing Protocol, then place a checkbox next to the network allocation you wish to use within this tunnel. Save it.
Configure a new Proxmox Network for 44Net
Select your PVE node root, then System > Network. Create a new Linux Bridge.

I named it vmbr44 (virtual machine bridge number 44) to remind me of what network it’s connecting to. Place a comment to do the same. Lastly, if you plan on using this network in the physical world, select your UNUSED network card in “Bridge ports:”. If you only plan on using this with other virtual machines and containers in Proxmox, omit this. Change the MTU under Advanced to 1300. You’ll certainly need this later since the tunnel has an MTU of 1380. Create.
Create a new Proxmox LXC to make a 44Net router
Create a new LXC which we’ll configure as a router. Choose a suitable name, and enter a new password.

Choose a template for the LXC. I personally like Ubuntu Server, so I installed 24.04-2 LTS. This would need to be pre-downloaded to your Proxmox server before starting this process.
The rest of the specs are as follows:
- 1 core (if you’ll be serving light ham applications like a web server or AllStar node)
- 256 MB – 512 MB of RAM and equal swap
- 2 GB of disk space (my total system configured is only just over 512MB)
- Network
- eth0 with a bridged network of vmbr0, your regular default internet connection. Set a static IP, or use DHCP.
- Any public DNS server like 1.1.1.1 or 9.9.9.9
Confirm and hit Finish.
Start your new container, update it, then install some tools:
# apt update && apt upgrade -y
# apt install net-tools wireguard ufw resolvconf mtr
Copy your newly modified Wireguard config which includes your new subnet to the system:
# nano /etc/wireguard/44net-connect.conf
Bring it up and perform testing just like earlier in the document:
# wg-quick up 44net-connect
# ping google.com
# mtr google.com
# systemctl enable wg-quick@44net-connect.service
# systemctl daemon-reload
Shut down the container, then add a network adapter to your LXC.

Name the interface “eth1”, select your 44Net bridge device you made earlier. In the IPv4 section, you’ll enter your 44Net allocation. In this case, we’ll use the first available IP address of the allocation and use that as our router address. So, if my allocation is 44.27.27.8/29, I would enter the first address of 44.27.27.9/29 in the IPv4/CIDR box. DO NOT ENTER A GATEWAY. Hit Add.
Start the LXC back up, and run a few commands to make sure the new adapter and address come up properly:

Now check the routing table. You should also see the new 44.x.x.x address there.

Enable routing in the Linux kernel and make it persistent:
# sysctl -w net.ipv4.ip_forward=1
# nano /etc/sysctl.d/99-sysctl.conf
Uncomment net.ipv4.ip_forward=1 in the file:

Save and exit.
Firewall it!
Here, you can choose to employ a basic firewall, or you can make this the primary place in which you block/permit network traffic from entering. I would recommend the latter.
# ufw enable
And here’s a very basic set of rules. Replace the relevant IPs with your internal private network AND your 44Net allocation subnet. Again, this is beyond the scope of this document, but will get you going. Special thanks to Mark NI2O for this information:
# ufw route deny in on 44net-connect to 192.168.0.10/24 # Your IP/subnet on eth0 of the LXC
# ufw route deny in on eth1 to 192.168.0.10/24 # Your IP/subnet on eth0 of the LXC
# ufw route allow in on eth0 to 44.27.27.8/29 # Your IP/subnet of your 44Net allocation, as written on 44Net.cloud. NOT your router IP.
# ufw route allow in on 44net-connect to 44.27.27.8/29 # Your IP/subnet of your 44Net allocation, as written on 44Net.cloud. NOT your router IP.
# ufw route allow from 44.27.27.8/29 to any # Your IP/subnet of your 44Net allocation, as written on 44Net.cloud. NOT your router IP.
The last command there is different from Mark’s documentation because his line didn’t work for me on the latest version of ufw supplied in Ubuntu 24.04. His documentation may well work perfectly on Debian 13.
And once again, study up on “ufw” and MAKE A BETTER FIREWALL! You’ll need to do this in order to allow services to pass onto your network.
You’re all done! To use your next available IP address after the router, simply use your 44Net bridge adapter “vmbr44” (or whatever you named it) when creating your new LXC or VMs instead of your regular 192.168.x.x internal network on “vmbr0”. Remember to use static IPs instead of DHCP. You could potentially configure a DHCP server on your router container as well, which will land outside the scope of this document, however if you’re using these addresses to provide public services, dynamic IPs are usually a hinderance to that process.
Troubleshooting
Slow connections, dropped packets, stalled downloads, etc…
The standard MTU of a network adapter in Proxmox is 1500, but the MTU of the Wireguard tunnel is 1380 by default. This creates a problem where packets sized at 1500 will not make it through the tunnel! In this guide when we created vmbr44, we changed the MTU to 1300, hopefully to avoid this issue, however, if your LXC or virtual machine still insists on trying to cram 1500 through a 1380 slot, things will not work correctly. Check the documentation for your operating system and make sure the MTU of your interface is set to 1300 or lower to fix the issue.
Here’s how you can test whether you’re being impacted by this:
# ping -s 1500 google.com # will probably fail
# ping -s 1300 google.com # will probably succeed
# ping -s 1350 google.com # try intermediate values to see how far you can push it
References
https://ni2o.ampr.org/documents/LXC%20container%20as%20a%2044Net%20VPN%20Subnet%20Router.pdf
https://ni2o.ampr.org/documents/LXC%20container%20as%20a%2044Net%20VPN%20Router_Firewall.pdf
https://blog.rtsp.us/ufw-uncomplicated-firewall-cheat-sheet-a9fe61933330
https://allstarlink.github.io/adv-topics/44net-connect
https://www.reddit.com/r/mikrotik/comments/1f0kpji/networking_in_linux_only_really_slow
https://superuser.com/questions/1771165/change-mtu-size-using-netsh-interface-ipv4-command