44Net Wiki - User contributions [en]

CGNAT

2026-08-29T00:26:06Z

KN6DWI: Added diagram for CGNAT

Carrier Grade Network Address Translation (CGNAT) is a form of [https://en.wikipedia.org/wiki/Network_address_translation Network Address Translation] (NAT) performed by internet service providers (ISPs). It involves placing many customers behind a single publicly routable IP address, and is a workaround to partially mitigate the impact of [https://en.wikipedia.org/wiki/IPv4_address_exhaustion IPv4 address exhaustion]. This can be an issue for people looking to self-host. In a non-CGNAT setup, your home router controls the NAT between your LAN and the WAN, and thus can forward ports from LAN devices to the WAN. In a CGNAT setup, there is a second layer of NAT performed by an ISP-owned router, which does not allow you to control port forwarding, and thus prevents self-hosting. This can be worked around by using a [[44Net_Connect/Single_Device_Tunnel|44Net Connect tunnel]] to expose a device directly to the internet using a 44Net IPv4 address.

[[File:CGNAT_network.png]]

== How to tell if you have CGNAT ==
The Internet Assigned Numbers Authority (IANA) has designated the IP range 100.64.0.0/10 for CGNAT usage. If your router is assigned an IP address in this range, your ISP is using CGNAT. This information can be found on your router's configuration page. Using websites such as whatismyip.net or similar will not tell you whether your ISP uses CGNAT, because the CGNAT IP range is not publicly routable. This means that your router's packets originating from a CGNAT IP are relabeled with a publicly routable IP by the ISP router before they exit the ISP's network, so internet services are not able to see the CGNAT IP.

[[Category:Reference]]

File:CGNAT network.png

2026-08-29T00:17:15Z

KN6DWI: A diagram illustrating the network topology involved in CGNAT. Hosts behind the home router receive RFC1918 addresses, the home router receives a CGNAT address, and its traffic is translated to a public-facing address by the ISP address before being routed on the WAN.

== Summary ==
A diagram illustrating the network topology involved in CGNAT. Hosts behind the home router receive RFC1918 addresses, the home router receives a CGNAT address, and its traffic is translated to a public-facing address by the ISP address before being routed on the WAN.

CGNAT

2026-08-28T23:40:03Z

KN6DWI: Added Wikipedia link to network address translation

Carrier Grade Network Address Translation (CGNAT) is a form of [https://en.wikipedia.org/wiki/Network_address_translation Network Address Translation] (NAT) performed by internet service providers (ISPs). It involves placing many customers behind a single publicly routable IP address, and is a workaround to partially mitigate the impact of [https://en.wikipedia.org/wiki/IPv4_address_exhaustion IPv4 address exhaustion]. This can be an issue for people looking to self-host. In a non-CGNAT setup, your home router controls the NAT between your LAN and the WAN, and thus can forward ports from LAN devices to the WAN. In a CGNAT setup, there is a second layer of NAT performed by an ISP-owned router, which does not allow you to control port forwarding, and thus prevents self-hosting. This can be worked around by using a [[44Net_Connect/Single_Device_Tunnel|44Net Connect tunnel]] to expose a device directly to the internet using a 44Net IPv4 address.

== How to tell if you have CGNAT ==
The Internet Assigned Numbers Authority (IANA) has designated the IP range 100.64.0.0/10 for CGNAT usage. If your router is assigned an IP address in this range, your ISP is using CGNAT. This information can be found on your router's configuration page. Using websites such as whatismyip.net or similar will not tell you whether your ISP uses CGNAT, because the CGNAT IP range is not publicly routable. This means that your router's packets originating from a CGNAT IP are relabeled with a publicly routable IP by the ISP router before they exit the ISP's network, so internet services are not able to see the CGNAT IP.

[[Category:Reference]]

CGNAT

2026-08-28T23:39:12Z

KN6DWI: Added link to single device tunnel page

Carrier Grade Network Address Translation (CGNAT) is a form of Network Address Translation (NAT) performed by internet service providers (ISPs). It involves placing many customers behind a single publicly routable IP address, and is a workaround to partially mitigate the impact of [https://en.wikipedia.org/wiki/IPv4_address_exhaustion IPv4 address exhaustion]. This can be an issue for people looking to self-host. In a non-CGNAT setup, your home router controls the NAT between your LAN and the WAN, and thus can forward ports from LAN devices to the WAN. In a CGNAT setup, there is a second layer of NAT performed by an ISP-owned router, which does not allow you to control port forwarding, and thus prevents self-hosting. This can be worked around by using a [[44Net_Connect/Single_Device_Tunnel|44Net Connect tunnel]] to expose a device directly to the internet using a 44Net IPv4 address.

== How to tell if you have CGNAT ==
The Internet Assigned Numbers Authority (IANA) has designated the IP range 100.64.0.0/10 for CGNAT usage. If your router is assigned an IP address in this range, your ISP is using CGNAT. This information can be found on your router's configuration page. Using websites such as whatismyip.net or similar will not tell you whether your ISP uses CGNAT, because the CGNAT IP range is not publicly routable. This means that your router's packets originating from a CGNAT IP are relabeled with a publicly routable IP by the ISP router before they exit the ISP's network, so internet services are not able to see the CGNAT IP.

[[Category:Reference]]

CGNAT

2026-08-28T23:37:21Z

KN6DWI: Wrote how to tell if you have CGNAT

Carrier Grade Network Address Translation (CGNAT) is a form of Network Address Translation (NAT) performed by internet service providers (ISPs). It involves placing many customers behind a single publicly routable IP address, and is a workaround to partially mitigate the impact of [https://en.wikipedia.org/wiki/IPv4_address_exhaustion IPv4 address exhaustion]. This can be an issue for people looking to self-host. In a non-CGNAT setup, your home router controls the NAT between your LAN and the WAN, and thus can forward ports from LAN devices to the WAN. In a CGNAT setup, there is a second layer of NAT performed by an ISP-owned router, which does not allow you to control port forwarding, and thus prevents self-hosting. This can be worked around by using a 44Net Connect tunnel to expose a device directly to the internet using a 44Net IPv4 address.

== How to tell if you have CGNAT ==
The Internet Assigned Numbers Authority (IANA) has designated the IP range 100.64.0.0/10 for CGNAT usage. If your router is assigned an IP address in this range, your ISP is using CGNAT. This information can be found on your router's configuration page. Using websites such as whatismyip.net or similar will not tell you whether your ISP uses CGNAT, because the CGNAT IP range is not publicly routable. This means that your router's packets originating from a CGNAT IP are relabeled with a publicly routable IP by the ISP router before they exit the ISP's network, so internet services are not able to see the CGNAT IP.

[[Category:Reference]]

CGNAT

2026-08-28T22:50:35Z

KN6DWI: Created page

Ipv6

2026-08-28T22:30:08Z

KN6DWI: Fixed typos

'''IPv6 is an experimental area for hams. Here are a collection of notes and loose development in relation to that.'''

Back in 1998, Naoto Shimazaki, 7L4FEP described an idea for use of IPv6 over the amateur radio in a [http://www.qsl.net/k/kb9mwr//wapr/tcpip/Take_the_Next_Step_with_the_Next_Generation_Protocol.pdf document] he presented to a TAPR Digital Communication Conference:

''IPv6 has huge address space and it supports real-time traffic. IPv6 realize new applications. For example, managing IPv4 address is not easy. It is possible to encode our "call sign" into IPv6 address. It enables us to managing IP address much easier.''

In 2012 a few members from the [http://www.wm7rc.org/ Mesa Amateur Radio Club] of Arizona took this to code and announced:

''Club Members Jacques N1ZZH and Vinnie N1LQJ have developed a method of embedding a 2x5 (7 Character) callsign plus up to 185 nodes, plus 1 universal bit and three reserved bits in the 2nd octet, and a 16 bit amateur radio identifier at bit 24 of an IPv6 /64 Subnet address. Tools for encoding and decoding amateur radio callsigns, up to 2x4 and 185 nodes, from IPv6 /64 subnets with Universal bit support and Amateur Radio Flag at the 24bit. Experimental RFC to IETF is being submitted for this proposed amateur standard.''

[http://sourceforge.net/projects/hamv6/ http://sourceforge.net/projects/hamv6/]

----
Kevin, N8VNR contacted [http://en.wikipedia.org/wiki/Internet_Assigned_Numbers_Authority IANA] in February 2011 hoping to get an allocation for the whole of Amateur Radio in the same vein as 44.0.0.0/8 and received this response:

''Currently, the only policy we have been given for the allocation of global unicast IPv6 address space is for allocation to the RIRs. We do not have a policy allowing allocation to organisations like AMPRNet. For this reason, we would strongly suggest contacting an RIR for an IPv6 allocation''

Kevin says perhaps someone with some more influence could contact them and make our case. He mentions other options include:

- Get an AMPRnet allocation in each of the [http://en.wikipedia.org/wiki/Regional_Internet_registry RIR] regions. This has the disadvantage of fragmenting the routing table (one of the things IPv6 was designed to mitigate). There's also no guarantee all of the RIRs would grant such a request.

- Use [http://en.wikipedia.org/wiki/Unique_local_address ULA] space. This has the disadvantage of rendering the IPv6 AMPRnet non-globally routable. Then again, not much of the IPv4 AMPRnet is truly globally routed, with the gateway for the greater Internet being a single machine somewhere at UCSD.

----

In 2015, Robert, N6DRC coded an encoding method for radio callsigns into numeric identifiers:

''This document describes a mechanism for efficiently and reversibly encoding radio callsigns into compact numeric identifiers. It also defines two addressing mechanisms using this numeric encoding: A new adaptive link-layer addressing scheme (HAM-64) intended for use with new link-layer networking protocols like ARNGLL (Up to 12 characters), and an adaptation of EUI-48 and EUI-64 addresses (Up to 8 and 11 characters, respectively) intended for use with existing link layer protocols.''

[https://github.com/darconeous/ham-addr/ https://github.com/darconeous/ham-addr/]

----
At the 2016 Digital Communications Conference Brian, W9CR gave a presentation promoting the use and support of IPv6 within the amateur community:

''A historical overview of legacy Internet protocols and their limitations will be presented here. IPv6 is the internationally recognized standard replacing these protocols. A short introduction to IPv6 and a case for its support in the amateur radio community is lacking. Finally an overview of the coming IPv6 deployment in HamWAN Tampa Bay is presented as a study of deployment for use by radio amateurs. Some background in IPv4 and Internet protocols is assumed.''

[http://www.youtube.com/watch?v=VfOrF5pssCs Presentation on Youtube]

[http://www.qsl.net/k/kb9mwr//wapr/tcpip/DCC2016-IPV6.pdf Abstract]

----
In October 2017, Steve, VK5ASF posted to the 44Net mailing list a message titled Using IPv6 hosts for AMPRNET, which gave some details of some experiments he was performing to tunnel IPv4 inside IPv6:

''Hi All,

AMPRNET consists of IPv4 addresses 44.0.0.0/9 and 44.128.0.0/10. Tunnels used to support AMPRNET use IPv4 hosts as destinations for the tunnels, creating a "mesh-like" network.

Bent OZ6BL and I have been experimenting with using an IPv6 host to carry AMPRNET traffic. The reason you might want to do this is that IPv6 addresses, particularly static addresses, can be much more readily available than with IPv4. Also, it's an interesting thing to try! We have working tunneled 44.0.0.0/9 and 44.128.0.0/10 connectivity between three different IPv6 hosts. However, there are some issues that arise, mainly due to the way in which AMPRNET functions.

<pre>
Tunneling IPv4 inside IPv6 (ip4in6) is easily done and is well documented. In Linux, commands like these are all that's needed:

/sbin/ip -6 tunnel add ip6tnl1 mode ip4ip6 \
remote 2001:0DB8:112:35c::5630:6324 \
local 2001:0DB8:1245:5200::ca0c:5902
/sbin/ip link set dev ip6tnl1 up
/sbin/ip route replace 44.145.40.32/32 dev ip6tnl1 src 44.136.170.20</pre>

It's very similar to how conventional AMPRNET is set up. However, the first issue is that with ip4in6 you cant (unlike ip4in4) leave the "remote" address empty, and then use routing commands to set the destination for different AMPRNET hosts (you'd be trying to add an IPv4 route to an IPv6 gateway destination). So there's a scalability problem - you'd need to set up a different tunnel device for each subnet you communicate with!

The second issue is interoperability - if Alf, Bob and Charlie each only have IPv6 hosted AMPRNET, and Doug, Ed and Fred have only IPv4, then A, B, and C can communicate with themselves, as can D,E,F, but the two groups cannot interconnect from tunneled addresses. Of course, A,B and C could host IP4 tunnels as well, but that would somewhat defeat the purpose! Alternatively, one or more gateways (G) could host both IP4 and IP6 based tunnels, and route between the different type of network, a bit like this:

A,B,C <----> G <----> D,E,F

Could/should amprgw be configured to do this? Or maybe some hosts elsewhere do that function? But it adds complexity to the overall routing setup (and starts to become a more centralised network).

The final issue is dissemination of the information - can the Portal be modified to support IPv6 hosts, or do we need another mechanism? Can encap.txt be used still? Would facilities such as ampr-ripd and ripd44 need modifications?

So there's plenty to think about....

Steve, VK5ASF
''

----
'''Conclusion'''

At this time we have come to the conclusion that there won't be a amprnet conversion to IPv6. A new network will evolve. It seems very unlikely hams will need their own allocation as the smallest ipv6 prefix assigned to a residential connection is a /64 subnet yielding 18,446,744,073,709,551,616 hosts.

We just need a means of advertising the ham netblocks (possibly announced by RIP) and automatically configuring filtering (an iptables whitelist). A DNS to register the ham host in, etc. An ideal situation would be a totally self-service DNS that uses LoTW (Logbook of the World) P12 certificates to authenticate hams, where they could then enter the IPv6 address(es) from their residential connection that are for ham use.

[[Category:Reference]]

Minecraft

2026-08-27T19:31:35Z

KN6DWI: Wrote troubleshooting steps for connection failures

If you want to host a Minecraft server, but are behind {{Term|CGNAT}} or can't port forward for other reasons, 44Net Connect will let you make your server publicly accessible.
This will add latency, since connections are routed first through the 44Net Connect endpoint and then to your Minecraft server. This latency can be minimized by picking a 44Net Connect node
physically close to you and your players.

Prerequisites:
* 44Net Portal account
* Verified callsign
* Configuration file from 44Net Connect
* Some sort of internet access

== Step 1: Configure your firewall ==
Ensure you have a firewall program installed, and configure it so that only the desired ports are exposed. If you're using SSH, avoid exposing it to the internet unless you're willing to secure it against constant attack. Open port 25565 to TCP traffic to allow connections to your Minecraft server. For more information on firewall configuration, see [[Firewalling Basics]].

== Step 2: Set up 44Net Connect tunnel ==
Next, set up a single device tunnel on the machine that will host your Minecraft server. Go to the [[https://wiki.ampr.org/wiki/44Net_Connect/Single_Device_Tunnel#Tutorials list of single device tunnel tutorials]] and follow the one for your operating system.

== Step 3: Set up your Minecraft server ==
=== Download the server jar ===
Download a Minecraft server jar file [https://www.minecraft.net/en-us/download/server from the official Minecraft website], and put it in its own folder. When you run the jar file, other server files will be generated in this folder. The official website recommends starting it with the following command:

<code>java -Xmx4G -Xms4G -jar <server jar name>.jar nogui</code>

The flag <code>-Xms4G</code> sets the minimum memory allocation to 4 gigabytes, and the flag <code>-Xmx4G</code> sets the maximum memory allocation to 4 gigabytes. This allocation should always be at least 1 gigabyte less than the amount of memory in your entire system, as the operating system needs some memory for itself. If you have exactly 4 GB of RAM, decrease the amount allocated in these flags. If you have more memory, you can set them higher, but it's not required. Setting them to be the same forces the memory allocation to be a fixed size, which improves performance by avoiding the need to request more memory in real time.

=== Configure the server ===
The first time you start the server, it will tell you to agree to the End User License Agreement and create the <code>eula.txt</code> file, then quit. Read the [https://www.minecraft.net/en-us/eula Minecraft End User License Agreement], then change the last line of the <code>eula.txt</code> file from <code>eula=false</code> to <code>eula=true</code>.

Since your server will be exposed to the internet, you may want to enable the whitelist to prevent random people from joining. To do this, edit the <code>server.properties</code> text file, and set <code>enforce-whitelist=true</code> as well as <code>white-list=true</code>. Each player who wants to join will need to be added to the whitelist by running the command <code>whitelist add <username></code> in the server console or in the client of a server operator. Add someone as an operator by running <code>op <username></code>, and remove them by running <code>deop <username></code>.

After configuring the server, start it up again using the command specified in the previous section. Test connectivity by joining via the address of your 44Net Connect tunnel, which is visible in the 44Net Connect tunnels page, or in the configuration file for your tunnel.

== Troubleshooting ==
=== Can't connect to Minecraft server from either LAN or 44Net ===
Check that the port for your Minecraft server is opened in the firewall. If using a firewall such as <code>firewalld</code> that allows interfaces to be moved between zones, ensure the rules have been added to the zones containing your LAN and WireGuard interfaces.

=== Minecraft server is only accessible over LAN, not 44Net ===
Ensure that your 44Net tunnel is up. On Linux systems, check its status with <code>systemctl status <name of systemd unit</code>. The default <code>systemd</code> unit name for a WireGuard tunnel started with <code>wg-quick</code> is <code>wg-quick@wg0</code>. Also check the 44Net Connect tunnels page to see if the endpoint thinks your tunnel is connected. The webpage can take a few minutes to update after the tunnel is enabled. If after a few minutes, the device and endpoint still disagree on whether your tunnel is up, you may have configuration issues. Make sure your IPv4 address in the configuration file is set to a /32, not a /24, as this can prevent the endpoint from updating the status page properly.

If the tunnel is up and you're still having issues, double check your firewall configuration. <code>firewalld</code> users should make sure port 25565 is open in the zone(s) containing the LAN and WireGuard interfaces. (The recommended configuration is to place the WireGuard interface for your tunnel in a less permissive zone for security purposes.)

[[Category:Use Cases]]

Minecraft

2026-08-27T19:23:43Z

KN6DWI: Wrote Minecraft server setup section

Minecraft

2026-08-27T19:03:15Z

KN6DWI: Fix link formatting

Minecraft

2026-08-27T19:02:43Z

KN6DWI: Direct people to the list of OS-specific tutorials

Minecraft

2026-08-27T18:31:30Z

KN6DWI: Tell people to open port 25565

Minecraft

2026-08-27T18:14:45Z

KN6DWI: Added link to firewalling basics

Minecraft

2026-08-27T18:10:34Z

KN6DWI: Created categories

Minecraft

2026-08-27T00:55:54Z

KN6DWI: Discussed latency penalty

Minecraft

2026-08-27T00:18:33Z

KN6DWI: Created page

If you want to host a Minecraft server, but are behind {{Term|CGNAT}} or can't port forward for other reasons, 44Net Connect will let you make your server publicly accessible.

Prerequisites:
* 44Net Portal account
* Verified callsign
* Configuration file from 44Net Connect
* Some sort of internet access

[[Category:Use Cases]]

Home Assistant

2026-08-26T22:39:41Z

KN6DWI: Added category use cases

Home Assistant is an open source home automation server. It has integrations for a wide variety of devices, and allows you to create custom dashboards for viewing sensor information and controlling your devices. If you want to access your Home Assistant instance from anywhere, but cannot port forward due to {{Term|CGNAT}}, making your instance publicly accessible via 44Net is one solution. Even if your home internet isn't behind CGNAT, it likely has a dynamic IP, which would require you to set up dynamic DNS for your instance to maintain consistent external access. A 44Net IP lets your instance be publicly accessible at a fixed IPv4 address for free.

Prerequisites:
* A Home Assistant instance (set this up '''before''' exposing it to the internet so that setup cannot be hijacked)
* A 44Net Connect account

== Step 1: Set up your tunnel ==
Home Assistant OS is designed to operate less like a general purpose computing device and more like an appliance. There is no package manager with which to install higher level firewall tools, and the Home Assistant WireGuard application is unmaintained as of 2026. If you're setting up a fresh Home Assistant installation for the express purpose of exposing it to 44Net, the easiest option is running it as a docker container on a device with a [[44Net_Connect/Single Device Tunnel | single device tunnel]]. If you have a dedicated Home Assistant appliance, such as a Home Assistant Green or a Raspberry Pi running Home Assistant OS on {{Term|bare metal}}, the recommended configuration is to put it on a [[44Net_Connect/Routed Subnet | routed subnet]].

== Step 2: Open port ==
Now that your Home Assistant instance and 44Net Connect tunnel are set up, it's time to open the required port in your firewall to make Home Assistant publicly accessible. The default Home Assistant port is 8123, so unless you've changed it, you'll need to open <code>8123/tcp</code> in your firewall. If you're running a single device tunnel with a Home Assistant VM or docker container, it's as simple as opening the device's firewall on <code>8123/tcp</code>. If you have a Home Assistant appliance inside a routed subnet, you'll need to open the port in the router's firewall, and ensure the firewall's rule set allows {{Term|WAN}} devices to initiate connections on that port. The syntax for doing so varies based on your firewall tool.

* <code>firewalld</code>: <code>sudo firewall-ctl --zone=<wireguard interface zone> --add-port 8123/tcp --permanent</code>
* <code>ufw</code>: <code>sudo ufw allow 8123 proto tcp</code>

== Step 3: Verify connection ==
After opening the port, verify that Home Assistant is accessible via its 44Net IP address on the port you opened. Visit that IP and port in your browser by going to <code>http://<IP>:<port></code>. It's important to use <code>http</code> rather than <code>https</code> if you haven't set up TLS.

== Optional: Set up TLS without a domain ==
By default, your connection to Home Assistant is unencrypted. Since it contains control traffic that affects the physical devices in your home, encrypting that connection with TLS is recommended. TLS certificates can be obtained for free through Let's Encrypt, and renewal can be automated via the Certbot project from the Electronic Frontier Foundation.

Let's Encrypt will issue short-lived certificates for bare IP addresses, which are valid for 6 days. Unfortunately, the Let's Encrypt app for Home Assistant OS doesn't support this, so HAOS users should either use a domain or run Certbot on another machine and find a way to automate updating the certificate in HAOS. Users running Home Assistant in a container can run Certbot in the container or on the host system.

=== Set up Certbot ===
First, [https://certbot.eff.org/instructions?ws=other&os=pip install Certbot according to its instructions]. Stop before the "Choose how you'd like to run Certbot" step. We'll be using a slightly different command because we're request a short-lived certificate for a bare IP.

Next, ensure your firewall has port 80 open on the machine where you installed Certbot. When you request a certificate for an IP, Certbot will start a temporary web server on port 80, and tell the Let's Encrypt server to contact the requested IP on that port. The connection will be through your 44Net IP, so ensure port 80 is open in the correct network zone of your firewall. See [[Firewalling Basics]] for more information.

Users running Certbot inside the same Docker container as Home Assistant, but running their single device tunnel on the host OS, may need to [https://docs.docker.com/engine/network/port-publishing/ create a docker port mapping] in addition to opening the port on their host OS's firewall.

To run Certbot and acquire the certificate, run the following command:

<code>sudo certbot certonly --standalone --preferred-profile shortlived --ip-address <your 44Net IP></code>

If it succeeds, you should see output including the following:

<nowiki>Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/<your 44Net IP>/fullchain.pem
Key is saved at: /etc/letsencrypt/live/<your 44Net IP>/privkey.pem
This certificate expires on 2026-08-24.
These files will be updated when the certificate renews.</nowiki>

Set up automatic renewal of your certificate by running the following command:

<code>echo "0 0,12 * * * root /opt/certbot/bin/python -c 'import random; import time; time.sleep(random.random() * 3600)' && sudo certbot renew -q" | sudo tee -a /etc/crontab > /dev/null</code>

This will add a {{Term|cron job}} that checks every 12 hours whether it needs to renew your certificate, and renews the certificate if it's close to expiring.

=== Configure Docker bind mount ===
If you set up Certbot on your host machine rather than in your container, you'll need to set up a [https://docs.docker.com/get-started/docker-concepts/running-containers/sharing-local-files/#file-permissions-for-docker-access-to-host-files bind mount] for the certificate and private key to be accessible to Home Assistant. Keep track of the directory inside the container that the mount is mapped to, and use that path in the next step.

=== Configure SSL in Home Assistant ===
Next, go to <code>Settings > System > Network</code>, and in the HTTP server section, fill in the paths for your SSL certificate and SSL key.

[[File:Home_Assistant_TLS_Settings.png|500px]]

Then, go to the IP banning section, and set the number of login attempts before ban to something other than -1 to prevent people from brute forcing your Home Assistant password.Finally, verify that your configuration is working by restarting Home Assistant to make it use the new configuration, and then visiting your 44Net IP. Your browser should indicate that your connection to Home Assistant is now encrypted.

== Optional: Set up TLS with a domain ==
By default, your connection to Home Assistant is unencrypted. Since it contains control traffic that affects the physical devices in your home, encrypting that connection with TLS is recommended. TLS certificates can be obtained for free through Let's Encrypt, and renewal can be automated via the Certbot project from the Electronic Frontier Foundation.

If you have a domain name, it can be used with Let's Encrypt and Certbot to easily set up an automatically renewing TLS certificate. If you're running Home Assistant OS, you can use the [https://github.com/home-assistant/addons/blob/master/letsencrypt/DOCS.md instructions for the Let's Encrypt app]. If you're running Home Assistant in a docker container, apps are not supported, so you'll need to set up Certbot yourself.

=== Set up Certbot ===
First, [https://certbot.eff.org/instructions?ws=other&os=pip install Certbot according to its instructions]. Before running the <code>certbot</code> command, ensure your firewall has port 80 open on the machine where you installed Certbot. When you request a certificate for an IP, Certbot will start a temporary web server on port 80, and tell the Let's Encrypt server to contact the requested IP on that port. The connection will be through your 44Net IP, so ensure port 80 is open in the correct network zone of your firewall. See [[Firewalling Basics]] for more information.

Users running Certbot inside the same Docker container as Home Assistant, but running their single device tunnel on the host OS, may need to [https://docs.docker.com/engine/network/port-publishing/ create a docker port mapping] in addition to opening the port on their host OS's firewall.

Set up automatic renewal of your certificate by running the following command:

<code>echo "0 0,12 * * * root /opt/certbot/bin/python -c 'import random; import time; time.sleep(random.random() * 3600)' && sudo certbot renew -q" | sudo tee -a /etc/crontab > /dev/null</code>

This will add a {{Term|cron job}} that checks every 12 hours whether it needs to renew your certificate, and renews the certificate if it's close to expiring.

=== Configure SSL in Home Assistant ===
Next, go to <code>Settings > System > Network</code>, and in the HTTP server section, fill in the paths for your SSL certificate and SSL key.

[[File:Home_Assistant_TLS_Settings.png|500px]]

Then, go to the IP banning section, and set the number of login attempts before ban to something other than -1 to prevent people from brute forcing your Home Assistant password.Finally, verify that your configuration is working by restarting Home Assistant to make it use the new configuration, and then visiting your 44Net IP. Your browser should indicate that your connection to Home Assistant is now encrypted.

== Troubleshooting ==
=== Home Assistant is not accessible from the 44Net IP ===
* Ensure you are accessing the correct port for Home Assistant. If you don't specify a port in your web browser, it will attempt to use port 80 (HTTP) or port 443 (HTTPS) by default, but the default Home Assistant port is 8123.
* Verify that your firewall configuration has port 8123 (or whatever alternate port you're using) open.
* Verify that your 44Net Connect tunnel is up using the [https://connect.44net.cloud/tunnels the 44Net Connect tunnels page].

=== Certificate authority fails to download challenge from the Certbot temporary web server ===
This typically happens if your 44Net tunnel is not up, or if your firewall is not configured to allow inbound connections on port 80. Try the following troubleshooting steps
* Use <code>ifconfig</code> to verify that your 44Net Connect tunnel is up. You should see a WireGuard interface with your 44Net IP address.
* Visit [https://connect.44net.cloud/tunnels the 44Net Connect tunnels page] and ensure your tunnel shows up as being connected.
* Check your firewall configuration and make sure port 80 is open. If you have recently changed your firewall configuration, reload the firewall.
* If running Certbot inside your Home Assistant docker container, make sure the docker container has its port 80 mapped to the host's port 80.

[[Category:Use Cases]]

44Net Connect/Quick Start/Fedora

2026-08-20T17:42:58Z

KN6DWI: Updated automatic start instructions to use automatically generated systemd unit

=== What you need ===

* A 44Net Portal account
* A verified amateur radio callsign
* A configuration file from 44Net Connect
* A device running Fedora Linux
* 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]]

== Install Dependencies ==
=== Step 1: Ensure your OS is up to date ===
Update your system packages using either your GUI tool of choice, or by opening
a terminal and running <code>sudo dnf update && sudo dnf upgrade</code>.

=== Step 2: Install wireguard ===
Run <code>sudo dnf install wireguard-tools</code>.

=== Step 3: Verify that systemd-resolved is enabled ===
<code>systemd-resolved</code> comes installed by default on Fedora. Ensure that it's running by executing <code>systemctl status systemd-resolved</code> in your terminal. If the unit is running without issues, there will be a green circle at the top left. The second line, beginning with "Loaded," should indicate that the unit is enabled. If it's not, run <code>systemctl enable systemd-resolved</code> to enable the unit. This will ensure that the unit starts automatically when your Fedora machine boots from now on.

The third line, beginning with "Active," should indicate that the unit is active (running).
If it's not, run <code>systemctl start systemd-resolved</code> to start the unit. This will ensure that the unit is currently running.

== Configure your WireGuard client ==
* Create a new file for your WireGuard configuration in <code>/etc/wireguard/</code>, for example <code>/etc/wireguard/wg0.conf</code>.
* You can name this file however you want, but this file name will become the name of your WireGuard interface.
* Paste the configuration text in from 44Net Connect, or if you prefer to use the file that was emailed to you, upload that one.

[[File:wireguard_tunnel_config.png|500px]]

The first time you create your tunnel, the private key will be present in the config for you to copy. Every subsequent time you view the config in the portal, the private key will not be shown. Saving a backup of the private key in a secure place is recommended.

After creating your config file, set its permissions so that only the owner has read or write permissions. This can be done with the command <code>sudo chmod 600 /etc/wireguard/wg0.conf</code>. (Replace <code>wg0</code> with the name of your file.)

== Activate and connect ==
=== Activate your tunnel ===
Run the command <code>wg-quick up wg0</code> (replace <code>wg0</code> with the name of your configuration file if different).

=== Confirm Connection in the Connect dashboard ===
* Your tunnel status should show as "Active" with a green indicator.
[[File:wireguard_tunnel_connected.png|500px]]
* The <code>Endpoint</code> field should show the IP address your device is connecting from, as well as the port it's using. This is not the 44Net IP from which your device is publicly accessible.

=== Other Ways to Confirm Connection ===
* Visit https://connect.44net.cloud/myip in your browser, or query it from the command line using <code>curl https://connect.44net.cloud/myip</code>
* Use <code>traceroute</code> to inspect the path between you and some other device, such as <code>traceroute 1.1.1.1</code>. When the tunnel is working, the first hop will be through a 44Net gateway, so its IP will be in the <code>44.0.0.0/9</code> or <code>44.128.0.0/10</code> subnet.

== Starting the Tunnel Automatically ==
* On Linux distributions that use <code>systemd</code>, using the <code>systemd</code> unit automatically generated by <code>wg-quick</code> is the recommended way to automatically start the tunnel. These are automatically created for any config file in <code>/etc/wireguard</code>.
* The automatically created unit is called <code>wg-quick@<config file name>.service</code>, so a file <code>/etc/wireguard/wg0.conf</code> would make <code>wg-quick@wg0.service</code>.
* Enable and start the service by running <code>sudo systemctl enable --now wg-quick@<config file></code>, where <code><config file></code> is replaced with the name of your config file without the extension.
* Verify that the service has started by running <code>systemctl status wg-quick@<config file></code> and checking that it says enabled and active, the same way we previously checked that systemd-resolved was working.

[[Category:Tutorial]]
[[Category:How-To]]
[[Category:Participation Methods]]
[[Category:44Net Connect]]
[[Category:Getting Started]]

44Net Connect/Quick Start/Debian based distributions

2026-08-20T17:32:32Z

KN6DWI: Changed autostart instructions to use systemd unit automatically generated by wg-quick

<noinclude>
<div class="toclimit-3">
__TOC__
</div>
{{DISPLAYTITLE:44Net Connect Quick Start: Debian-based distributions}}

=== What you need ===

* A 44Net Portal account
* A verified amateur radio callsign
* A configuration file from 44Net Connect
* A machine running a Debian-based Linux distribution
* 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]]
</noinclude>

== Install Dependencies ==

=== Step 1: Ensure your OS is up to date ===
Open a terminal and run <code>sudo apt-get update</code>, then <code>sudo apt-get upgrade</code>.

=== Step 2: Install wireguard and systemd-resolved ===
Run <code>sudo apt-get install wireguard systemd-resolved</code>, then restart your Raspberry Pi. Restarting is required for <code>systemd-resolved</code> to function.

=== Step 3: Verify that systemd-resolved is enabled ===
Run <code>systemctl status systemd-resolved</code>. If the unit is running without issues, there will be a green asterisk or circle at the top left. The second line, beginning with "Loaded," should indicate that the unit is enabled. If it's not, run <code>systemctl enable systemd-resolved</code> to enable the unit. This will ensure that the unit starts automatically when your Raspberry Pi boots from now on.

The third line, beginning with "Active," should indicate that the unit is active (running).
If it's not, run <code>systemctl start systemd-resolved</code> to start the unit. This will ensure that the unit is currently running.

== Configure your WireGuard client ==
* Create a new file for your WireGuard configuration in <code>/etc/wireguard/</code>, for example <code>/etc/wireguard/wg0.conf</code>.
* You can name this file however you want, but this file name will become the name of your WireGuard interface.
* Paste the configuration text in from 44Net Connect, or if you prefer to use the file that was emailed to you, upload that one.

[[File:wireguard_tunnel_config.png|500px]]

The first time you create your tunnel, the private key will be present in the config for you to copy. Every subsequent time you view the config in the portal, the private key will not be shown. Saving a backup of the private key in a secure place is recommended.

After creating your config file, set its permissions so that only the owner has read or write permissions. This can be done with the command <code>sudo chmod 600 /etc/wireguard/wg0.conf</code>. (Replace <code>wg0</code> with the name of your file.)

== Activate and connect ==
=== Activate your tunnel ===
* Run the command <code>wg-quick up wg0</code> (replace <code>wg0</code> with the name of your configuration file if different).
* If at this step WireGuard reports the error <code>Failed to activate service 'org.freedesktop.resolve1': timed out</code>, you may have forgotten to restart your computer after installing <code>systemd-resolved</code>.

=== Confirm Connection in the Connect dashboard ===
* Your tunnel status should show as "Active" with a green indicator.
[[File:wireguard_tunnel_connected.png|500px]]
* The <code>Endpoint</code> field should show the IP address your device is connecting from, as well as the port it's using. This is not the 44Net IP from which your device is publicly accessible.

=== Other Ways to Confirm Connection ===
* Visit https://connect.44net.cloud/myip in your browser, or query it from the command line using <code>curl https://connect.44net.cloud/myip</code>
* Use <code>traceroute</code> to inspect the path between you and some other device, such as <code>traceroute 1.1.1.1</code>. When the tunnel is working, the first hop will be through a 44Net gateway, so its IP will be in the <code>44.0.0.0/9</code> or <code>44.128.0.0/10</code> subnet.

== Starting the Tunnel Automatically ==
* On Linux distributions that use <code>systemd</code>, using the <code>systemd</code> unit automatically generated by <code>wg-quick</code> is the recommended way to automatically start the tunnel. These are automatically created for any config file in <code>/etc/wireguard</code>.
* The automatically created unit is called <code>wg-quick@<config file name>.service</code>, so a file <code>/etc/wireguard/wg0.conf</code> would make <code>wg-quick@wg0.service</code>.
* Enable and start the service by running <code>sudo systemctl enable --now wg-quick@<config file></code>, where <code><config file></code> is replaced with the name of your config file without the extension.
* Verify that the service has started by running <code>systemctl status wg-quick@<config file></code> and checking that it says enabled and active, the same way we previously checked that systemd-resolved was working.

[[Category:Tutorial]]
[[Category:How-To]]
[[Category:Participation Methods]]
[[Category:44Net Connect]]
[[Category:Getting Started]]

Home Assistant

2026-08-19T22:47:42Z

KN6DWI: Added image of TLS configuration

Home Assistant

2026-08-19T22:46:51Z

KN6DWI: Added image of TLS configuration

Home Assistant is an open source home automation server. It has integrations for a wide variety of devices, and allows you to create custom dashboards for viewing sensor information and controlling your devices. If you want to access your Home Assistant instance from anywhere, but cannot port forward due to {{Term|CGNAT}}, making your instance publicly accessible via 44Net is one solution. Even if your home internet isn't behind CGNAT, it likely has a dynamic IP, which would require you to set up dynamic DNS for your instance to maintain consistent external access. A 44Net IP lets your instance be publicly accessible at a fixed IPv4 address for free.

Prerequisites:
* A Home Assistant instance (set this up '''before''' exposing it to the internet so that setup cannot be hijacked)
* A 44Net Connect account

== Step 1: Set up your tunnel ==
Home Assistant OS is designed to operate less like a general purpose computing device and more like an appliance. There is no package manager with which to install higher level firewall tools, and the Home Assistant WireGuard application is unmaintained as of 2026. If you're setting up a fresh Home Assistant installation for the express purpose of exposing it to 44Net, the easiest option is running it as a docker container on a device with a [[44Net_Connect/Single Device Tunnel | single device tunnel]]. If you have a dedicated Home Assistant appliance, such as a Home Assistant Green or a Raspberry Pi running Home Assistant OS on {{Term|bare metal}}, the recommended configuration is to put it on a [[44Net_Connect/Routed Subnet | routed subnet]].

== Step 2: Open port ==
Now that your Home Assistant instance and 44Net Connect tunnel are set up, it's time to open the required port in your firewall to make Home Assistant publicly accessible. The default Home Assistant port is 8123, so unless you've changed it, you'll need to open <code>8123/tcp</code> in your firewall. If you're running a single device tunnel with a Home Assistant VM or docker container, it's as simple as opening the device's firewall on <code>8123/tcp</code>. If you have a Home Assistant appliance inside a routed subnet, you'll need to open the port in the router's firewall, and ensure the firewall's rule set allows {{Term|WAN}} devices to initiate connections on that port. The syntax for doing so varies based on your firewall tool.

* <code>firewalld</code>: <code>sudo firewall-ctl --zone=<wireguard interface zone> --add-port 8123/tcp --permanent</code>
* <code>ufw</code>: <code>sudo ufw allow 8123 proto tcp</code>

== Step 3: Verify connection ==
After opening the port, verify that Home Assistant is accessible via its 44Net IP address on the port you opened. Visit that IP and port in your browser by going to <code>http://<IP>:<port></code>. It's important to use <code>http</code> rather than <code>https</code> if you haven't set up TLS.

== Optional: Set up TLS without a domain ==
By default, your connection to Home Assistant is unencrypted. Since it contains control traffic that affects the physical devices in your home, encrypting that connection with TLS is recommended. TLS certificates can be obtained for free through Let's Encrypt, and renewal can be automated via the Certbot project from the Electronic Frontier Foundation.

Let's Encrypt will issue short-lived certificates for bare IP addresses, which are valid for 6 days. Unfortunately, the Let's Encrypt app for Home Assistant OS doesn't support this, so HAOS users should either use a domain or run Certbot on another machine and find a way to automate updating the certificate in HAOS. Users running Home Assistant in a container can run Certbot in the container or on the host system.

=== Set up Certbot ===
First, [https://certbot.eff.org/instructions?ws=other&os=pip install Certbot according to its instructions]. Stop before the "Choose how you'd like to run Certbot" step. We'll be using a slightly different command because we're request a short-lived certificate for a bare IP.

Next, ensure your firewall has port 80 open on the machine where you installed Certbot. When you request a certificate for an IP, Certbot will start a temporary web server on port 80, and tell the Let's Encrypt server to contact the requested IP on that port. The connection will be through your 44Net IP, so ensure port 80 is open in the correct network zone of your firewall. See [[Firewalling Basics]] for more information.

Users running Certbot inside the same Docker container as Home Assistant, but running their single device tunnel on the host OS, may need to [https://docs.docker.com/engine/network/port-publishing/ create a docker port mapping] in addition to opening the port on their host OS's firewall.

To run Certbot and acquire the certificate, run the following command:

<code>sudo certbot certonly --standalone --preferred-profile shortlived --ip-address <your 44Net IP></code>

If it succeeds, you should see output including the following:

<nowiki>Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/<your 44Net IP>/fullchain.pem
Key is saved at: /etc/letsencrypt/live/<your 44Net IP>/privkey.pem
This certificate expires on 2026-08-24.
These files will be updated when the certificate renews.</nowiki>

Set up automatic renewal of your certificate by running the following command:

<code>echo "0 0,12 * * * root /opt/certbot/bin/python -c 'import random; import time; time.sleep(random.random() * 3600)' && sudo certbot renew -q" | sudo tee -a /etc/crontab > /dev/null</code>

This will add a {{Term|cron job}} that checks every 12 hours whether it needs to renew your certificate, and renews the certificate if it's close to expiring.

=== Configure Docker bind mount ===
If you set up Certbot on your host machine rather than in your container, you'll need to set up a [https://docs.docker.com/get-started/docker-concepts/running-containers/sharing-local-files/#file-permissions-for-docker-access-to-host-files bind mount] for the certificate and private key to be accessible to Home Assistant. Keep track of the directory inside the container that the mount is mapped to, and use that path in the next step.

=== Configure SSL in Home Assistant ===
Next, go to <code>Settings > System > Network</code>, and in the HTTP server section, fill in the paths for your SSL certificate and SSL key. Then, go to the IP banning section, and set the number of login attempts before ban to something other than -1 to prevent people from brute forcing your Home Assistant password.Finally, verify that your configuration is working by restarting Home Assistant to make it use the new configuration, and then visiting your 44Net IP. Your browser should indicate that your connection to Home Assistant is now encrypted.

== Optional: Set up TLS with a domain ==
By default, your connection to Home Assistant is unencrypted. Since it contains control traffic that affects the physical devices in your home, encrypting that connection with TLS is recommended. TLS certificates can be obtained for free through Let's Encrypt, and renewal can be automated via the Certbot project from the Electronic Frontier Foundation.

If you have a domain name, it can be used with Let's Encrypt and Certbot to easily set up an automatically renewing TLS certificate. If you're running Home Assistant OS, you can use the [https://github.com/home-assistant/addons/blob/master/letsencrypt/DOCS.md instructions for the Let's Encrypt app]. If you're running Home Assistant in a docker container, apps are not supported, so you'll need to set up Certbot yourself.

=== Set up Certbot ===
First, [https://certbot.eff.org/instructions?ws=other&os=pip install Certbot according to its instructions]. Before running the <code>certbot</code> command, ensure your firewall has port 80 open on the machine where you installed Certbot. When you request a certificate for an IP, Certbot will start a temporary web server on port 80, and tell the Let's Encrypt server to contact the requested IP on that port. The connection will be through your 44Net IP, so ensure port 80 is open in the correct network zone of your firewall. See [[Firewalling Basics]] for more information.

Users running Certbot inside the same Docker container as Home Assistant, but running their single device tunnel on the host OS, may need to [https://docs.docker.com/engine/network/port-publishing/ create a docker port mapping] in addition to opening the port on their host OS's firewall.

Set up automatic renewal of your certificate by running the following command:

<code>echo "0 0,12 * * * root /opt/certbot/bin/python -c 'import random; import time; time.sleep(random.random() * 3600)' && sudo certbot renew -q" | sudo tee -a /etc/crontab > /dev/null</code>

This will add a {{Term|cron job}} that checks every 12 hours whether it needs to renew your certificate, and renews the certificate if it's close to expiring.

=== Configure SSL in Home Assistant ===
Next, go to <code>Settings > System > Network</code>, and in the HTTP server section, fill in the paths for your SSL certificate and SSL key.

[[File:Home_Assistant_TLS_Settings.png|500px]]

Then, go to the IP banning section, and set the number of login attempts before ban to something other than -1 to prevent people from brute forcing your Home Assistant password.Finally, verify that your configuration is working by restarting Home Assistant to make it use the new configuration, and then visiting your 44Net IP. Your browser should indicate that your connection to Home Assistant is now encrypted.

== Troubleshooting ==
=== Home Assistant is not accessible from the 44Net IP ===
* Ensure you are accessing the correct port for Home Assistant. If you don't specify a port in your web browser, it will attempt to use port 80 (HTTP) or port 443 (HTTPS) by default, but the default Home Assistant port is 8123.
* Verify that your firewall configuration has port 8123 (or whatever alternate port you're using) open.
* Verify that your 44Net Connect tunnel is up using the [https://connect.44net.cloud/tunnels the 44Net Connect tunnels page].

=== Certificate authority fails to download challenge from the Certbot temporary web server ===
This typically happens if your 44Net tunnel is not up, or if your firewall is not configured to allow inbound connections on port 80. Try the following troubleshooting steps
* Use <code>ifconfig</code> to verify that your 44Net Connect tunnel is up. You should see a WireGuard interface with your 44Net IP address.
* Visit [https://connect.44net.cloud/tunnels the 44Net Connect tunnels page] and ensure your tunnel shows up as being connected.
* Check your firewall configuration and make sure port 80 is open. If you have recently changed your firewall configuration, reload the firewall.
* If running Certbot inside your Home Assistant docker container, make sure the docker container has its port 80 mapped to the host's port 80.

File:Home Assistant TLS Settings.png

2026-08-19T22:29:15Z

KN6DWI: A screenshot of the HTTP server section in Network Settings for Home Assistant.

== Summary ==
A screenshot of the HTTP server section in Network Settings for Home Assistant.

Home Assistant

2026-08-19T18:45:09Z

KN6DWI: Formatting fix

Home Assistant is an open source home automation server. It has integrations for a wide variety of devices, and allows you to create custom dashboards for viewing sensor information and controlling your devices. If you want to access your Home Assistant instance from anywhere, but cannot port forward due to {{Term|CGNAT}}, making your instance publicly accessible via 44Net is one solution. Even if your home internet isn't behind CGNAT, it likely has a dynamic IP, which would require you to set up dynamic DNS for your instance to maintain consistent external access. A 44Net IP lets your instance be publicly accessible at a fixed IPv4 address for free.

Prerequisites:
* A Home Assistant instance (set this up '''before''' exposing it to the internet so that setup cannot be hijacked)
* A 44Net Connect account

== Step 1: Set up your tunnel ==
Home Assistant OS is designed to operate less like a general purpose computing device and more like an appliance. There is no package manager with which to install higher level firewall tools, and the Home Assistant WireGuard application is unmaintained as of 2026. If you're setting up a fresh Home Assistant installation for the express purpose of exposing it to 44Net, the easiest option is running it as a docker container on a device with a [[44Net_Connect/Single Device Tunnel | single device tunnel]]. If you have a dedicated Home Assistant appliance, such as a Home Assistant Green or a Raspberry Pi running Home Assistant OS on {{Term|bare metal}}, the recommended configuration is to put it on a [[44Net_Connect/Routed Subnet | routed subnet]].

== Step 2: Open port ==
Now that your Home Assistant instance and 44Net Connect tunnel are set up, it's time to open the required port in your firewall to make Home Assistant publicly accessible. The default Home Assistant port is 8123, so unless you've changed it, you'll need to open <code>8123/tcp</code> in your firewall. If you're running a single device tunnel with a Home Assistant VM or docker container, it's as simple as opening the device's firewall on <code>8123/tcp</code>. If you have a Home Assistant appliance inside a routed subnet, you'll need to open the port in the router's firewall, and ensure the firewall's rule set allows {{Term|WAN}} devices to initiate connections on that port. The syntax for doing so varies based on your firewall tool.

* <code>firewalld</code>: <code>sudo firewall-ctl --zone=<wireguard interface zone> --add-port 8123/tcp --permanent</code>
* <code>ufw</code>: <code>sudo ufw allow 8123 proto tcp</code>

== Step 3: Verify connection ==
After opening the port, verify that Home Assistant is accessible via its 44Net IP address on the port you opened. Visit that IP and port in your browser by going to <code>http://<IP>:<port></code>. It's important to use <code>http</code> rather than <code>https</code> if you haven't set up TLS.

== Optional: Set up TLS without a domain ==
By default, your connection to Home Assistant is unencrypted. Since it contains control traffic that affects the physical devices in your home, encrypting that connection with TLS is recommended. TLS certificates can be obtained for free through Let's Encrypt, and renewal can be automated via the Certbot project from the Electronic Frontier Foundation.

Let's Encrypt will issue short-lived certificates for bare IP addresses, which are valid for 6 days. Unfortunately, the Let's Encrypt app for Home Assistant OS doesn't support this, so HAOS users should either use a domain or run Certbot on another machine and find a way to automate updating the certificate in HAOS. Users running Home Assistant in a container can run Certbot in the container or on the host system.

=== Set up Certbot ===
First, [https://certbot.eff.org/instructions?ws=other&os=pip install Certbot according to its instructions]. Stop before the "Choose how you'd like to run Certbot" step. We'll be using a slightly different command because we're request a short-lived certificate for a bare IP.

Next, ensure your firewall has port 80 open on the machine where you installed Certbot. When you request a certificate for an IP, Certbot will start a temporary web server on port 80, and tell the Let's Encrypt server to contact the requested IP on that port. The connection will be through your 44Net IP, so ensure port 80 is open in the correct network zone of your firewall. See [[Firewalling Basics]] for more information.

Users running Certbot inside the same Docker container as Home Assistant, but running their single device tunnel on the host OS, may need to [https://docs.docker.com/engine/network/port-publishing/ create a docker port mapping] in addition to opening the port on their host OS's firewall.

To run Certbot and acquire the certificate, run the following command:

<code>sudo certbot certonly --standalone --preferred-profile shortlived --ip-address <your 44Net IP></code>

If it succeeds, you should see output including the following:

<nowiki>Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/<your 44Net IP>/fullchain.pem
Key is saved at: /etc/letsencrypt/live/<your 44Net IP>/privkey.pem
This certificate expires on 2026-08-24.
These files will be updated when the certificate renews.</nowiki>

Set up automatic renewal of your certificate by running the following command:

<code>echo "0 0,12 * * * root /opt/certbot/bin/python -c 'import random; import time; time.sleep(random.random() * 3600)' && sudo certbot renew -q" | sudo tee -a /etc/crontab > /dev/null</code>

This will add a {{Term|cron job}} that checks every 12 hours whether it needs to renew your certificate, and renews the certificate if it's close to expiring.

=== Configure Docker bind mount ===
If you set up Certbot on your host machine rather than in your container, you'll need to set up a [https://docs.docker.com/get-started/docker-concepts/running-containers/sharing-local-files/#file-permissions-for-docker-access-to-host-files bind mount] for the certificate and private key to be accessible to Home Assistant. Keep track of the directory inside the container that the mount is mapped to, and use that path in the next step.

=== Configure SSL in Home Assistant ===
Next, go to <code>Settings > System > Network</code>, and in the HTTP server section, fill in the paths for your SSL certificate and SSL key. Then, go to the IP banning section, and set the number of login attempts before ban to something other than -1 to prevent people from brute forcing your Home Assistant password.Finally, verify that your configuration is working by restarting Home Assistant to make it use the new configuration, and then visiting your 44Net IP. Your browser should indicate that your connection to Home Assistant is now encrypted.

== Optional: Set up TLS with a domain ==
By default, your connection to Home Assistant is unencrypted. Since it contains control traffic that affects the physical devices in your home, encrypting that connection with TLS is recommended. TLS certificates can be obtained for free through Let's Encrypt, and renewal can be automated via the Certbot project from the Electronic Frontier Foundation.

If you have a domain name, it can be used with Let's Encrypt and Certbot to easily set up an automatically renewing TLS certificate. If you're running Home Assistant OS, you can use the [https://github.com/home-assistant/addons/blob/master/letsencrypt/DOCS.md instructions for the Let's Encrypt app]. If you're running Home Assistant in a docker container, apps are not supported, so you'll need to set up Certbot yourself.

=== Set up Certbot ===
First, [https://certbot.eff.org/instructions?ws=other&os=pip install Certbot according to its instructions]. Before running the <code>certbot</code> command, ensure your firewall has port 80 open on the machine where you installed Certbot. When you request a certificate for an IP, Certbot will start a temporary web server on port 80, and tell the Let's Encrypt server to contact the requested IP on that port. The connection will be through your 44Net IP, so ensure port 80 is open in the correct network zone of your firewall. See [[Firewalling Basics]] for more information.

Users running Certbot inside the same Docker container as Home Assistant, but running their single device tunnel on the host OS, may need to [https://docs.docker.com/engine/network/port-publishing/ create a docker port mapping] in addition to opening the port on their host OS's firewall.

Set up automatic renewal of your certificate by running the following command:

<code>echo "0 0,12 * * * root /opt/certbot/bin/python -c 'import random; import time; time.sleep(random.random() * 3600)' && sudo certbot renew -q" | sudo tee -a /etc/crontab > /dev/null</code>

This will add a {{Term|cron job}} that checks every 12 hours whether it needs to renew your certificate, and renews the certificate if it's close to expiring.

=== Configure SSL in Home Assistant ===
Next, go to <code>Settings > System > Network</code>, and in the HTTP server section, fill in the paths for your SSL certificate and SSL key. Then, go to the IP banning section, and set the number of login attempts before ban to something other than -1 to prevent people from brute forcing your Home Assistant password.Finally, verify that your configuration is working by restarting Home Assistant to make it use the new configuration, and then visiting your 44Net IP. Your browser should indicate that your connection to Home Assistant is now encrypted.

== Troubleshooting ==
=== Home Assistant is not accessible from the 44Net IP ===
* Ensure you are accessing the correct port for Home Assistant. If you don't specify a port in your web browser, it will attempt to use port 80 (HTTP) or port 443 (HTTPS) by default, but the default Home Assistant port is 8123.
* Verify that your firewall configuration has port 8123 (or whatever alternate port you're using) open.
* Verify that your 44Net Connect tunnel is up using the [https://connect.44net.cloud/tunnels the 44Net Connect tunnels page].

=== Certificate authority fails to download challenge from the Certbot temporary web server ===
This typically happens if your 44Net tunnel is not up, or if your firewall is not configured to allow inbound connections on port 80. Try the following troubleshooting steps
* Use <code>ifconfig</code> to verify that your 44Net Connect tunnel is up. You should see a WireGuard interface with your 44Net IP address.
* Visit [https://connect.44net.cloud/tunnels the 44Net Connect tunnels page] and ensure your tunnel shows up as being connected.
* Check your firewall configuration and make sure port 80 is open. If you have recently changed your firewall configuration, reload the firewall.
* If running Certbot inside your Home Assistant docker container, make sure the docker container has its port 80 mapped to the host's port 80.

Home Assistant

2026-08-19T18:44:46Z

KN6DWI: Added troubleshooting section for not being able to access Home Assistant

Home Assistant is an open source home automation server. It has integrations for a wide variety of devices, and allows you to create custom dashboards for viewing sensor information and controlling your devices. If you want to access your Home Assistant instance from anywhere, but cannot port forward due to {{Term|CGNAT}}, making your instance publicly accessible via 44Net is one solution. Even if your home internet isn't behind CGNAT, it likely has a dynamic IP, which would require you to set up dynamic DNS for your instance to maintain consistent external access. A 44Net IP lets your instance be publicly accessible at a fixed IPv4 address for free.

Prerequisites:
* A Home Assistant instance (set this up '''before''' exposing it to the internet so that setup cannot be hijacked)
* A 44Net Connect account

== Step 1: Set up your tunnel ==
Home Assistant OS is designed to operate less like a general purpose computing device and more like an appliance. There is no package manager with which to install higher level firewall tools, and the Home Assistant WireGuard application is unmaintained as of 2026. If you're setting up a fresh Home Assistant installation for the express purpose of exposing it to 44Net, the easiest option is running it as a docker container on a device with a [[44Net_Connect/Single Device Tunnel | single device tunnel]]. If you have a dedicated Home Assistant appliance, such as a Home Assistant Green or a Raspberry Pi running Home Assistant OS on {{Term|bare metal}}, the recommended configuration is to put it on a [[44Net_Connect/Routed Subnet | routed subnet]].

== Step 2: Open port ==
Now that your Home Assistant instance and 44Net Connect tunnel are set up, it's time to open the required port in your firewall to make Home Assistant publicly accessible. The default Home Assistant port is 8123, so unless you've changed it, you'll need to open <code>8123/tcp</code> in your firewall. If you're running a single device tunnel with a Home Assistant VM or docker container, it's as simple as opening the device's firewall on <code>8123/tcp</code>. If you have a Home Assistant appliance inside a routed subnet, you'll need to open the port in the router's firewall, and ensure the firewall's rule set allows {{Term|WAN}} devices to initiate connections on that port. The syntax for doing so varies based on your firewall tool.

* <code>firewalld</code>: <code>sudo firewall-ctl --zone=<wireguard interface zone> --add-port 8123/tcp --permanent</code>
* <code>ufw</code>: <code>sudo ufw allow 8123 proto tcp</code>

== Step 3: Verify connection ==
After opening the port, verify that Home Assistant is accessible via its 44Net IP address on the port you opened. Visit that IP and port in your browser by going to <code>http://<IP>:<port></code>. It's important to use <code>http</code> rather than <code>https</code> if you haven't set up TLS.

== Optional: Set up TLS without a domain ==
By default, your connection to Home Assistant is unencrypted. Since it contains control traffic that affects the physical devices in your home, encrypting that connection with TLS is recommended. TLS certificates can be obtained for free through Let's Encrypt, and renewal can be automated via the Certbot project from the Electronic Frontier Foundation.

Let's Encrypt will issue short-lived certificates for bare IP addresses, which are valid for 6 days. Unfortunately, the Let's Encrypt app for Home Assistant OS doesn't support this, so HAOS users should either use a domain or run Certbot on another machine and find a way to automate updating the certificate in HAOS. Users running Home Assistant in a container can run Certbot in the container or on the host system.

=== Set up Certbot ===
First, [https://certbot.eff.org/instructions?ws=other&os=pip install Certbot according to its instructions]. Stop before the "Choose how you'd like to run Certbot" step. We'll be using a slightly different command because we're request a short-lived certificate for a bare IP.

Next, ensure your firewall has port 80 open on the machine where you installed Certbot. When you request a certificate for an IP, Certbot will start a temporary web server on port 80, and tell the Let's Encrypt server to contact the requested IP on that port. The connection will be through your 44Net IP, so ensure port 80 is open in the correct network zone of your firewall. See [[Firewalling Basics]] for more information.

Users running Certbot inside the same Docker container as Home Assistant, but running their single device tunnel on the host OS, may need to [https://docs.docker.com/engine/network/port-publishing/ create a docker port mapping] in addition to opening the port on their host OS's firewall.

To run Certbot and acquire the certificate, run the following command:

<code>sudo certbot certonly --standalone --preferred-profile shortlived --ip-address <your 44Net IP></code>

If it succeeds, you should see output including the following:

<nowiki>Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/<your 44Net IP>/fullchain.pem
Key is saved at: /etc/letsencrypt/live/<your 44Net IP>/privkey.pem
This certificate expires on 2026-08-24.
These files will be updated when the certificate renews.</nowiki>

Set up automatic renewal of your certificate by running the following command:

<code>echo "0 0,12 * * * root /opt/certbot/bin/python -c 'import random; import time; time.sleep(random.random() * 3600)' && sudo certbot renew -q" | sudo tee -a /etc/crontab > /dev/null</code>

This will add a {{Term|cron job}} that checks every 12 hours whether it needs to renew your certificate, and renews the certificate if it's close to expiring.

=== Configure Docker bind mount ===
If you set up Certbot on your host machine rather than in your container, you'll need to set up a [https://docs.docker.com/get-started/docker-concepts/running-containers/sharing-local-files/#file-permissions-for-docker-access-to-host-files bind mount] for the certificate and private key to be accessible to Home Assistant. Keep track of the directory inside the container that the mount is mapped to, and use that path in the next step.

=== Configure SSL in Home Assistant ===
Next, go to <code>Settings > System > Network</code>, and in the HTTP server section, fill in the paths for your SSL certificate and SSL key. Then, go to the IP banning section, and set the number of login attempts before ban to something other than -1 to prevent people from brute forcing your Home Assistant password.Finally, verify that your configuration is working by restarting Home Assistant to make it use the new configuration, and then visiting your 44Net IP. Your browser should indicate that your connection to Home Assistant is now encrypted.

== Optional: Set up TLS with a domain ==
By default, your connection to Home Assistant is unencrypted. Since it contains control traffic that affects the physical devices in your home, encrypting that connection with TLS is recommended. TLS certificates can be obtained for free through Let's Encrypt, and renewal can be automated via the Certbot project from the Electronic Frontier Foundation.

If you have a domain name, it can be used with Let's Encrypt and Certbot to easily set up an automatically renewing TLS certificate. If you're running Home Assistant OS, you can use the [https://github.com/home-assistant/addons/blob/master/letsencrypt/DOCS.md instructions for the Let's Encrypt app]. If you're running Home Assistant in a docker container, apps are not supported, so you'll need to set up Certbot yourself.

=== Set up Certbot ===
First, [https://certbot.eff.org/instructions?ws=other&os=pip install Certbot according to its instructions]. Before running the <code>certbot</code> command, ensure your firewall has port 80 open on the machine where you installed Certbot. When you request a certificate for an IP, Certbot will start a temporary web server on port 80, and tell the Let's Encrypt server to contact the requested IP on that port. The connection will be through your 44Net IP, so ensure port 80 is open in the correct network zone of your firewall. See [[Firewalling Basics]] for more information.

Users running Certbot inside the same Docker container as Home Assistant, but running their single device tunnel on the host OS, may need to [https://docs.docker.com/engine/network/port-publishing/ create a docker port mapping] in addition to opening the port on their host OS's firewall.

Set up automatic renewal of your certificate by running the following command:

<code>echo "0 0,12 * * * root /opt/certbot/bin/python -c 'import random; import time; time.sleep(random.random() * 3600)' && sudo certbot renew -q" | sudo tee -a /etc/crontab > /dev/null</code>

This will add a {{Term|cron job}} that checks every 12 hours whether it needs to renew your certificate, and renews the certificate if it's close to expiring.

=== Configure SSL in Home Assistant ===
Next, go to <code>Settings > System > Network</code>, and in the HTTP server section, fill in the paths for your SSL certificate and SSL key. Then, go to the IP banning section, and set the number of login attempts before ban to something other than -1 to prevent people from brute forcing your Home Assistant password.Finally, verify that your configuration is working by restarting Home Assistant to make it use the new configuration, and then visiting your 44Net IP. Your browser should indicate that your connection to Home Assistant is now encrypted.

== Troubleshooting ==
=== Home Assistant is not accessible from the 44Net IP ===
- Ensure you are accessing the correct port for Home Assistant. If you don't specify a port in your web browser, it will attempt to use port 80 (HTTP) or port 443 (HTTPS) by default, but the default Home Assistant port is 8123.
- Verify that your firewall configuration has port 8123 (or whatever alternate port you're using) open.
- Verify that your 44Net Connect tunnel is up using the [https://connect.44net.cloud/tunnels the 44Net Connect tunnels page].

=== Certificate authority fails to download challenge from the Certbot temporary web server ===
This typically happens if your 44Net tunnel is not up, or if your firewall is not configured to allow inbound connections on port 80. Try the following troubleshooting steps
* Use <code>ifconfig</code> to verify that your 44Net Connect tunnel is up. You should see a WireGuard interface with your 44Net IP address.
* Visit [https://connect.44net.cloud/tunnels the 44Net Connect tunnels page] and ensure your tunnel shows up as being connected.
* Check your firewall configuration and make sure port 80 is open. If you have recently changed your firewall configuration, reload the firewall.
* If running Certbot inside your Home Assistant docker container, make sure the docker container has its port 80 mapped to the host's port 80.

Home Assistant

2026-08-19T18:41:08Z

KN6DWI: Added inline Term reference for cron job

Home Assistant is an open source home automation server. It has integrations for a wide variety of devices, and allows you to create custom dashboards for viewing sensor information and controlling your devices. If you want to access your Home Assistant instance from anywhere, but cannot port forward due to {{Term|CGNAT}}, making your instance publicly accessible via 44Net is one solution. Even if your home internet isn't behind CGNAT, it likely has a dynamic IP, which would require you to set up dynamic DNS for your instance to maintain consistent external access. A 44Net IP lets your instance be publicly accessible at a fixed IPv4 address for free.

Prerequisites:
* A Home Assistant instance (set this up '''before''' exposing it to the internet so that setup cannot be hijacked)
* A 44Net Connect account

== Step 1: Set up your tunnel ==
Home Assistant OS is designed to operate less like a general purpose computing device and more like an appliance. There is no package manager with which to install higher level firewall tools, and the Home Assistant WireGuard application is unmaintained as of 2026. If you're setting up a fresh Home Assistant installation for the express purpose of exposing it to 44Net, the easiest option is running it as a docker container on a device with a [[44Net_Connect/Single Device Tunnel | single device tunnel]]. If you have a dedicated Home Assistant appliance, such as a Home Assistant Green or a Raspberry Pi running Home Assistant OS on {{Term|bare metal}}, the recommended configuration is to put it on a [[44Net_Connect/Routed Subnet | routed subnet]].

== Step 2: Open port ==
Now that your Home Assistant instance and 44Net Connect tunnel are set up, it's time to open the required port in your firewall to make Home Assistant publicly accessible. The default Home Assistant port is 8123, so unless you've changed it, you'll need to open <code>8123/tcp</code> in your firewall. If you're running a single device tunnel with a Home Assistant VM or docker container, it's as simple as opening the device's firewall on <code>8123/tcp</code>. If you have a Home Assistant appliance inside a routed subnet, you'll need to open the port in the router's firewall, and ensure the firewall's rule set allows {{Term|WAN}} devices to initiate connections on that port. The syntax for doing so varies based on your firewall tool.

* <code>firewalld</code>: <code>sudo firewall-ctl --zone=<wireguard interface zone> --add-port 8123/tcp --permanent</code>
* <code>ufw</code>: <code>sudo ufw allow 8123 proto tcp</code>

== Step 3: Verify connection ==
After opening the port, verify that Home Assistant is accessible via its 44Net IP address on the port you opened. Visit that IP and port in your browser by going to <code>http://<IP>:<port></code>. It's important to use <code>http</code> rather than <code>https</code> if you haven't set up TLS.

== Optional: Set up TLS without a domain ==
By default, your connection to Home Assistant is unencrypted. Since it contains control traffic that affects the physical devices in your home, encrypting that connection with TLS is recommended. TLS certificates can be obtained for free through Let's Encrypt, and renewal can be automated via the Certbot project from the Electronic Frontier Foundation.

Let's Encrypt will issue short-lived certificates for bare IP addresses, which are valid for 6 days. Unfortunately, the Let's Encrypt app for Home Assistant OS doesn't support this, so HAOS users should either use a domain or run Certbot on another machine and find a way to automate updating the certificate in HAOS. Users running Home Assistant in a container can run Certbot in the container or on the host system.

=== Set up Certbot ===
First, [https://certbot.eff.org/instructions?ws=other&os=pip install Certbot according to its instructions]. Stop before the "Choose how you'd like to run Certbot" step. We'll be using a slightly different command because we're request a short-lived certificate for a bare IP.

Next, ensure your firewall has port 80 open on the machine where you installed Certbot. When you request a certificate for an IP, Certbot will start a temporary web server on port 80, and tell the Let's Encrypt server to contact the requested IP on that port. The connection will be through your 44Net IP, so ensure port 80 is open in the correct network zone of your firewall. See [[Firewalling Basics]] for more information.

Users running Certbot inside the same Docker container as Home Assistant, but running their single device tunnel on the host OS, may need to [https://docs.docker.com/engine/network/port-publishing/ create a docker port mapping] in addition to opening the port on their host OS's firewall.

To run Certbot and acquire the certificate, run the following command:

<code>sudo certbot certonly --standalone --preferred-profile shortlived --ip-address <your 44Net IP></code>

If it succeeds, you should see output including the following:

<nowiki>Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/<your 44Net IP>/fullchain.pem
Key is saved at: /etc/letsencrypt/live/<your 44Net IP>/privkey.pem
This certificate expires on 2026-08-24.
These files will be updated when the certificate renews.</nowiki>

Set up automatic renewal of your certificate by running the following command:

<code>echo "0 0,12 * * * root /opt/certbot/bin/python -c 'import random; import time; time.sleep(random.random() * 3600)' && sudo certbot renew -q" | sudo tee -a /etc/crontab > /dev/null</code>

This will add a {{Term|cron job}} that checks every 12 hours whether it needs to renew your certificate, and renews the certificate if it's close to expiring.

=== Configure Docker bind mount ===
If you set up Certbot on your host machine rather than in your container, you'll need to set up a [https://docs.docker.com/get-started/docker-concepts/running-containers/sharing-local-files/#file-permissions-for-docker-access-to-host-files bind mount] for the certificate and private key to be accessible to Home Assistant. Keep track of the directory inside the container that the mount is mapped to, and use that path in the next step.

=== Configure SSL in Home Assistant ===
Next, go to <code>Settings > System > Network</code>, and in the HTTP server section, fill in the paths for your SSL certificate and SSL key. Then, go to the IP banning section, and set the number of login attempts before ban to something other than -1 to prevent people from brute forcing your Home Assistant password.Finally, verify that your configuration is working by restarting Home Assistant to make it use the new configuration, and then visiting your 44Net IP. Your browser should indicate that your connection to Home Assistant is now encrypted.

== Optional: Set up TLS with a domain ==
By default, your connection to Home Assistant is unencrypted. Since it contains control traffic that affects the physical devices in your home, encrypting that connection with TLS is recommended. TLS certificates can be obtained for free through Let's Encrypt, and renewal can be automated via the Certbot project from the Electronic Frontier Foundation.

If you have a domain name, it can be used with Let's Encrypt and Certbot to easily set up an automatically renewing TLS certificate. If you're running Home Assistant OS, you can use the [https://github.com/home-assistant/addons/blob/master/letsencrypt/DOCS.md instructions for the Let's Encrypt app]. If you're running Home Assistant in a docker container, apps are not supported, so you'll need to set up Certbot yourself.

=== Set up Certbot ===
First, [https://certbot.eff.org/instructions?ws=other&os=pip install Certbot according to its instructions]. Before running the <code>certbot</code> command, ensure your firewall has port 80 open on the machine where you installed Certbot. When you request a certificate for an IP, Certbot will start a temporary web server on port 80, and tell the Let's Encrypt server to contact the requested IP on that port. The connection will be through your 44Net IP, so ensure port 80 is open in the correct network zone of your firewall. See [[Firewalling Basics]] for more information.

Users running Certbot inside the same Docker container as Home Assistant, but running their single device tunnel on the host OS, may need to [https://docs.docker.com/engine/network/port-publishing/ create a docker port mapping] in addition to opening the port on their host OS's firewall.

Set up automatic renewal of your certificate by running the following command:

<code>echo "0 0,12 * * * root /opt/certbot/bin/python -c 'import random; import time; time.sleep(random.random() * 3600)' && sudo certbot renew -q" | sudo tee -a /etc/crontab > /dev/null</code>

This will add a {{Term|cron job}} that checks every 12 hours whether it needs to renew your certificate, and renews the certificate if it's close to expiring.

=== Configure SSL in Home Assistant ===
Next, go to <code>Settings > System > Network</code>, and in the HTTP server section, fill in the paths for your SSL certificate and SSL key. Then, go to the IP banning section, and set the number of login attempts before ban to something other than -1 to prevent people from brute forcing your Home Assistant password.Finally, verify that your configuration is working by restarting Home Assistant to make it use the new configuration, and then visiting your 44Net IP. Your browser should indicate that your connection to Home Assistant is now encrypted.

== Troubleshooting ==
=== Certificate authority fails to download challenge from the Certbot temporary web server ===
This typically happens if your 44Net tunnel is not up, or if your firewall is not configured to allow inbound connections on port 80. Try the following troubleshooting steps
* Use <code>ifconfig</code> to verify that your 44Net Connect tunnel is up. You should see a WireGuard interface with your 44Net IP address.
* Visit [https://connect.44net.cloud/tunnels the 44Net Connect tunnels page] and ensure your tunnel shows up as being connected.
* Check your firewall configuration and make sure port 80 is open. If you have recently changed your firewall configuration, reload the firewall.
* If running Certbot inside your Home Assistant docker container, make sure the docker container has its port 80 mapped to the host's port 80.

Home Assistant

2026-08-19T18:40:31Z

KN6DWI: Formatting fix for inline term usage

Home Assistant is an open source home automation server. It has integrations for a wide variety of devices, and allows you to create custom dashboards for viewing sensor information and controlling your devices. If you want to access your Home Assistant instance from anywhere, but cannot port forward due to {{Term|CGNAT}}, making your instance publicly accessible via 44Net is one solution. Even if your home internet isn't behind CGNAT, it likely has a dynamic IP, which would require you to set up dynamic DNS for your instance to maintain consistent external access. A 44Net IP lets your instance be publicly accessible at a fixed IPv4 address for free.

Prerequisites:
* A Home Assistant instance (set this up '''before''' exposing it to the internet so that setup cannot be hijacked)
* A 44Net Connect account

== Step 1: Set up your tunnel ==
Home Assistant OS is designed to operate less like a general purpose computing device and more like an appliance. There is no package manager with which to install higher level firewall tools, and the Home Assistant WireGuard application is unmaintained as of 2026. If you're setting up a fresh Home Assistant installation for the express purpose of exposing it to 44Net, the easiest option is running it as a docker container on a device with a [[44Net_Connect/Single Device Tunnel | single device tunnel]]. If you have a dedicated Home Assistant appliance, such as a Home Assistant Green or a Raspberry Pi running Home Assistant OS on {{Term|bare metal}}, the recommended configuration is to put it on a [[44Net_Connect/Routed Subnet | routed subnet]].

== Step 2: Open port ==
Now that your Home Assistant instance and 44Net Connect tunnel are set up, it's time to open the required port in your firewall to make Home Assistant publicly accessible. The default Home Assistant port is 8123, so unless you've changed it, you'll need to open <code>8123/tcp</code> in your firewall. If you're running a single device tunnel with a Home Assistant VM or docker container, it's as simple as opening the device's firewall on <code>8123/tcp</code>. If you have a Home Assistant appliance inside a routed subnet, you'll need to open the port in the router's firewall, and ensure the firewall's rule set allows {{Term|WAN}} devices to initiate connections on that port. The syntax for doing so varies based on your firewall tool.

* <code>firewalld</code>: <code>sudo firewall-ctl --zone=<wireguard interface zone> --add-port 8123/tcp --permanent</code>
* <code>ufw</code>: <code>sudo ufw allow 8123 proto tcp</code>

== Step 3: Verify connection ==
After opening the port, verify that Home Assistant is accessible via its 44Net IP address on the port you opened. Visit that IP and port in your browser by going to <code>http://<IP>:<port></code>. It's important to use <code>http</code> rather than <code>https</code> if you haven't set up TLS.

== Optional: Set up TLS without a domain ==
By default, your connection to Home Assistant is unencrypted. Since it contains control traffic that affects the physical devices in your home, encrypting that connection with TLS is recommended. TLS certificates can be obtained for free through Let's Encrypt, and renewal can be automated via the Certbot project from the Electronic Frontier Foundation.

Let's Encrypt will issue short-lived certificates for bare IP addresses, which are valid for 6 days. Unfortunately, the Let's Encrypt app for Home Assistant OS doesn't support this, so HAOS users should either use a domain or run Certbot on another machine and find a way to automate updating the certificate in HAOS. Users running Home Assistant in a container can run Certbot in the container or on the host system.

=== Set up Certbot ===
First, [https://certbot.eff.org/instructions?ws=other&os=pip install Certbot according to its instructions]. Stop before the "Choose how you'd like to run Certbot" step. We'll be using a slightly different command because we're request a short-lived certificate for a bare IP.

Next, ensure your firewall has port 80 open on the machine where you installed Certbot. When you request a certificate for an IP, Certbot will start a temporary web server on port 80, and tell the Let's Encrypt server to contact the requested IP on that port. The connection will be through your 44Net IP, so ensure port 80 is open in the correct network zone of your firewall. See [[Firewalling Basics]] for more information.

Users running Certbot inside the same Docker container as Home Assistant, but running their single device tunnel on the host OS, may need to [https://docs.docker.com/engine/network/port-publishing/ create a docker port mapping] in addition to opening the port on their host OS's firewall.

To run Certbot and acquire the certificate, run the following command:

<code>sudo certbot certonly --standalone --preferred-profile shortlived --ip-address <your 44Net IP></code>

If it succeeds, you should see output including the following:

<nowiki>Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/<your 44Net IP>/fullchain.pem
Key is saved at: /etc/letsencrypt/live/<your 44Net IP>/privkey.pem
This certificate expires on 2026-08-24.
These files will be updated when the certificate renews.</nowiki>

Set up automatic renewal of your certificate by running the following command:

<code>echo "0 0,12 * * * root /opt/certbot/bin/python -c 'import random; import time; time.sleep(random.random() * 3600)' && sudo certbot renew -q" | sudo tee -a /etc/crontab > /dev/null</code>

This will add a {{Term|cron job}} that checks every 12 hours whether it needs to renew your certificate, and renews the certificate if it's close to expiring.

=== Configure Docker bind mount ===
If you set up Certbot on your host machine rather than in your container, you'll need to set up a [https://docs.docker.com/get-started/docker-concepts/running-containers/sharing-local-files/#file-permissions-for-docker-access-to-host-files bind mount] for the certificate and private key to be accessible to Home Assistant. Keep track of the directory inside the container that the mount is mapped to, and use that path in the next step.

=== Configure SSL in Home Assistant ===
Next, go to <code>Settings > System > Network</code>, and in the HTTP server section, fill in the paths for your SSL certificate and SSL key. Then, go to the IP banning section, and set the number of login attempts before ban to something other than -1 to prevent people from brute forcing your Home Assistant password.Finally, verify that your configuration is working by restarting Home Assistant to make it use the new configuration, and then visiting your 44Net IP. Your browser should indicate that your connection to Home Assistant is now encrypted.

== Optional: Set up TLS with a domain ==
By default, your connection to Home Assistant is unencrypted. Since it contains control traffic that affects the physical devices in your home, encrypting that connection with TLS is recommended. TLS certificates can be obtained for free through Let's Encrypt, and renewal can be automated via the Certbot project from the Electronic Frontier Foundation.

If you have a domain name, it can be used with Let's Encrypt and Certbot to easily set up an automatically renewing TLS certificate. If you're running Home Assistant OS, you can use the [https://github.com/home-assistant/addons/blob/master/letsencrypt/DOCS.md instructions for the Let's Encrypt app]. If you're running Home Assistant in a docker container, apps are not supported, so you'll need to set up Certbot yourself.

=== Set up Certbot ===
First, [https://certbot.eff.org/instructions?ws=other&os=pip install Certbot according to its instructions]. Before running the <code>certbot</code> command, ensure your firewall has port 80 open on the machine where you installed Certbot. When you request a certificate for an IP, Certbot will start a temporary web server on port 80, and tell the Let's Encrypt server to contact the requested IP on that port. The connection will be through your 44Net IP, so ensure port 80 is open in the correct network zone of your firewall. See [[Firewalling Basics]] for more information.

Users running Certbot inside the same Docker container as Home Assistant, but running their single device tunnel on the host OS, may need to [https://docs.docker.com/engine/network/port-publishing/ create a docker port mapping] in addition to opening the port on their host OS's firewall.

Set up automatic renewal of your certificate by running the following command:

<code>echo "0 0,12 * * * root /opt/certbot/bin/python -c 'import random; import time; time.sleep(random.random() * 3600)' && sudo certbot renew -q" | sudo tee -a /etc/crontab > /dev/null</code>

This will add a cron job that checks every 12 hours whether it needs to renew your certificate, and renews the certificate if it's close to expiring.

=== Configure SSL in Home Assistant ===
Next, go to <code>Settings > System > Network</code>, and in the HTTP server section, fill in the paths for your SSL certificate and SSL key. Then, go to the IP banning section, and set the number of login attempts before ban to something other than -1 to prevent people from brute forcing your Home Assistant password.Finally, verify that your configuration is working by restarting Home Assistant to make it use the new configuration, and then visiting your 44Net IP. Your browser should indicate that your connection to Home Assistant is now encrypted.

== Troubleshooting ==
=== Certificate authority fails to download challenge from the Certbot temporary web server ===
This typically happens if your 44Net tunnel is not up, or if your firewall is not configured to allow inbound connections on port 80. Try the following troubleshooting steps
* Use <code>ifconfig</code> to verify that your 44Net Connect tunnel is up. You should see a WireGuard interface with your 44Net IP address.
* Visit [https://connect.44net.cloud/tunnels the 44Net Connect tunnels page] and ensure your tunnel shows up as being connected.
* Check your firewall configuration and make sure port 80 is open. If you have recently changed your firewall configuration, reload the firewall.
* If running Certbot inside your Home Assistant docker container, make sure the docker container has its port 80 mapped to the host's port 80.

Term:Cron job

2026-08-19T18:39:42Z

KN6DWI: Formatting fix

{{TermDefinition
| short = Recurring task executed at the specified interval by the cron daemon
| long = Cron is a daemon (background process) that executes commands at specified intervals. Each user has their own crontab file where the tasks are described, and there's a system crontab file as well. Your crontab file can be edited with the command crontab -e.
| mode = {{{mode|view}}}
}}

Term:Cron job

2026-08-19T18:39:22Z

KN6DWI: Created term

{{TermDefinition
| short = Recurring task executed at the specified interval by the cron daemon }}
| long = Cron is a daemon (background process) that executes commands at specified intervals. Each user has their own crontab file where the tasks are described, and there's a system crontab file as well. Your crontab file can be edited with the command crontab -e.
| mode = {{{mode|view}}}
}}

Home Assistant

2026-08-19T18:36:40Z

KN6DWI: Create cron job term

Home Assistant is an open source home automation server. It has integrations for a wide variety of devices, and allows you to create custom dashboards for viewing sensor information and controlling your devices. If you want to access your Home Assistant instance from anywhere, but cannot port forward due to {{Term|CGNAT}}, making your instance publicly accessible via 44Net is one solution. Even if your home internet isn't behind CGNAT, it likely has a dynamic IP, which would require you to set up dynamic DNS for your instance to maintain consistent external access. A 44Net IP lets your instance be publicly accessible at a fixed IPv4 address for free.

Prerequisites:
* A Home Assistant instance (set this up '''before''' exposing it to the internet so that setup cannot be hijacked)
* A 44Net Connect account

== Step 1: Set up your tunnel ==
Home Assistant OS is designed to operate less like a general purpose computing device and more like an appliance. There is no package manager with which to install higher level firewall tools, and the Home Assistant WireGuard application is unmaintained as of 2026. If you're setting up a fresh Home Assistant installation for the express purpose of exposing it to 44Net, the easiest option is running it as a docker container on a device with a [[44Net_Connect/Single Device Tunnel | single device tunnel]]. If you have a dedicated Home Assistant appliance, such as a Home Assistant Green or a Raspberry Pi running Home Assistant OS on {{Term|bare metal}}, the recommended configuration is to put it on a [[44Net_Connect/Routed Subnet | routed subnet]].

== Step 2: Open port ==
Now that your Home Assistant instance and 44Net Connect tunnel are set up, it's time to open the required port in your firewall to make Home Assistant publicly accessible. The default Home Assistant port is 8123, so unless you've changed it, you'll need to open <code>8123/tcp</code> in your firewall. If you're running a single device tunnel with a Home Assistant VM or docker container, it's as simple as opening the device's firewall on <code>8123/tcp</code>. If you have a Home Assistant appliance inside a routed subnet, you'll need to open the port in the router's firewall, and ensure the firewall's rule set allows {{Term|WAN}} devices to initiate connections on that port. The syntax for doing so varies based on your firewall tool.

* <code>firewalld</code>: <code>sudo firewall-ctl --zone=<wireguard interface zone> --add-port 8123/tcp --permanent</code>
* <code>ufw</code>: <code>sudo ufw allow 8123 proto tcp</code>

== Step 3: Verify connection ==
After opening the port, verify that Home Assistant is accessible via its 44Net IP address on the port you opened. Visit that IP and port in your browser by going to <code>http://<IP>:<port></code>. It's important to use <code>http</code> rather than <code>https</code> if you haven't set up TLS.

== Optional: Set up TLS without a domain ==
By default, your connection to Home Assistant is unencrypted. Since it contains control traffic that affects the physical devices in your home, encrypting that connection with TLS is recommended. TLS certificates can be obtained for free through Let's Encrypt, and renewal can be automated via the Certbot project from the Electronic Frontier Foundation.

Let's Encrypt will issue short-lived certificates for bare IP addresses, which are valid for 6 days. Unfortunately, the Let's Encrypt app for Home Assistant OS doesn't support this, so HAOS users should either use a domain or run Certbot on another machine and find a way to automate updating the certificate in HAOS. Users running Home Assistant in a container can run Certbot in the container or on the host system.

=== Set up Certbot ===
First, [https://certbot.eff.org/instructions?ws=other&os=pip install Certbot according to its instructions]. Stop before the "Choose how you'd like to run Certbot" step. We'll be using a slightly different command because we're request a short-lived certificate for a bare IP.

Next, ensure your firewall has port 80 open on the machine where you installed Certbot. When you request a certificate for an IP, Certbot will start a temporary web server on port 80, and tell the Let's Encrypt server to contact the requested IP on that port. The connection will be through your 44Net IP, so ensure port 80 is open in the correct network zone of your firewall. See [[Firewalling Basics]] for more information.

Users running Certbot inside the same Docker container as Home Assistant, but running their single device tunnel on the host OS, may need to [https://docs.docker.com/engine/network/port-publishing/ create a docker port mapping] in addition to opening the port on their host OS's firewall.

To run Certbot and acquire the certificate, run the following command:

<code>sudo certbot certonly --standalone --preferred-profile shortlived --ip-address <your 44Net IP></code>

If it succeeds, you should see output including the following:

<nowiki>Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/<your 44Net IP>/fullchain.pem
Key is saved at: /etc/letsencrypt/live/<your 44Net IP>/privkey.pem
This certificate expires on 2026-08-24.
These files will be updated when the certificate renews.</nowiki>

Set up automatic renewal of your certificate by running the following command:

<code>echo "0 0,12 * * * root /opt/certbot/bin/python -c 'import random; import time; time.sleep(random.random() * 3600)' && sudo certbot renew -q" | sudo tee -a /etc/crontab > /dev/null</code>

This will add a {{Term:cron job}} that checks every 12 hours whether it needs to renew your certificate, and renews the certificate if it's close to expiring.

=== Configure Docker bind mount ===
If you set up Certbot on your host machine rather than in your container, you'll need to set up a [https://docs.docker.com/get-started/docker-concepts/running-containers/sharing-local-files/#file-permissions-for-docker-access-to-host-files bind mount] for the certificate and private key to be accessible to Home Assistant. Keep track of the directory inside the container that the mount is mapped to, and use that path in the next step.

=== Configure SSL in Home Assistant ===
Next, go to <code>Settings > System > Network</code>, and in the HTTP server section, fill in the paths for your SSL certificate and SSL key. Then, go to the IP banning section, and set the number of login attempts before ban to something other than -1 to prevent people from brute forcing your Home Assistant password.Finally, verify that your configuration is working by restarting Home Assistant to make it use the new configuration, and then visiting your 44Net IP. Your browser should indicate that your connection to Home Assistant is now encrypted.

== Optional: Set up TLS with a domain ==
By default, your connection to Home Assistant is unencrypted. Since it contains control traffic that affects the physical devices in your home, encrypting that connection with TLS is recommended. TLS certificates can be obtained for free through Let's Encrypt, and renewal can be automated via the Certbot project from the Electronic Frontier Foundation.

If you have a domain name, it can be used with Let's Encrypt and Certbot to easily set up an automatically renewing TLS certificate. If you're running Home Assistant OS, you can use the [https://github.com/home-assistant/addons/blob/master/letsencrypt/DOCS.md instructions for the Let's Encrypt app]. If you're running Home Assistant in a docker container, apps are not supported, so you'll need to set up Certbot yourself.

=== Set up Certbot ===
First, [https://certbot.eff.org/instructions?ws=other&os=pip install Certbot according to its instructions]. Before running the <code>certbot</code> command, ensure your firewall has port 80 open on the machine where you installed Certbot. When you request a certificate for an IP, Certbot will start a temporary web server on port 80, and tell the Let's Encrypt server to contact the requested IP on that port. The connection will be through your 44Net IP, so ensure port 80 is open in the correct network zone of your firewall. See [[Firewalling Basics]] for more information.

Users running Certbot inside the same Docker container as Home Assistant, but running their single device tunnel on the host OS, may need to [https://docs.docker.com/engine/network/port-publishing/ create a docker port mapping] in addition to opening the port on their host OS's firewall.

Set up automatic renewal of your certificate by running the following command:

<code>echo "0 0,12 * * * root /opt/certbot/bin/python -c 'import random; import time; time.sleep(random.random() * 3600)' && sudo certbot renew -q" | sudo tee -a /etc/crontab > /dev/null</code>

This will add a cron job that checks every 12 hours whether it needs to renew your certificate, and renews the certificate if it's close to expiring.

=== Configure SSL in Home Assistant ===
Next, go to <code>Settings > System > Network</code>, and in the HTTP server section, fill in the paths for your SSL certificate and SSL key. Then, go to the IP banning section, and set the number of login attempts before ban to something other than -1 to prevent people from brute forcing your Home Assistant password.Finally, verify that your configuration is working by restarting Home Assistant to make it use the new configuration, and then visiting your 44Net IP. Your browser should indicate that your connection to Home Assistant is now encrypted.

== Troubleshooting ==
=== Certificate authority fails to download challenge from the Certbot temporary web server ===
This typically happens if your 44Net tunnel is not up, or if your firewall is not configured to allow inbound connections on port 80. Try the following troubleshooting steps
* Use <code>ifconfig</code> to verify that your 44Net Connect tunnel is up. You should see a WireGuard interface with your 44Net IP address.
* Visit [https://connect.44net.cloud/tunnels the 44Net Connect tunnels page] and ensure your tunnel shows up as being connected.
* Check your firewall configuration and make sure port 80 is open. If you have recently changed your firewall configuration, reload the firewall.
* If running Certbot inside your Home Assistant docker container, make sure the docker container has its port 80 mapped to the host's port 80.

Home Assistant

2026-08-19T17:30:31Z

KN6DWI: Formatting fix

Home Assistant is an open source home automation server. It has integrations for a wide variety of devices, and allows you to create custom dashboards for viewing sensor information and controlling your devices. If you want to access your Home Assistant instance from anywhere, but cannot port forward due to {{Term|CGNAT}}, making your instance publicly accessible via 44Net is one solution. Even if your home internet isn't behind CGNAT, it likely has a dynamic IP, which would require you to set up dynamic DNS for your instance to maintain consistent external access. A 44Net IP lets your instance be publicly accessible at a fixed IPv4 address for free.

Prerequisites:
* A Home Assistant instance (set this up '''before''' exposing it to the internet so that setup cannot be hijacked)
* A 44Net Connect account

== Step 1: Set up your tunnel ==
Home Assistant OS is designed to operate less like a general purpose computing device and more like an appliance. There is no package manager with which to install higher level firewall tools, and the Home Assistant WireGuard application is unmaintained as of 2026. If you're setting up a fresh Home Assistant installation for the express purpose of exposing it to 44Net, the easiest option is running it as a docker container on a device with a [[44Net_Connect/Single Device Tunnel | single device tunnel]]. If you have a dedicated Home Assistant appliance, such as a Home Assistant Green or a Raspberry Pi running Home Assistant OS on {{Term|bare metal}}, the recommended configuration is to put it on a [[44Net_Connect/Routed Subnet | routed subnet]].

== Step 2: Open port ==
Now that your Home Assistant instance and 44Net Connect tunnel are set up, it's time to open the required port in your firewall to make Home Assistant publicly accessible. The default Home Assistant port is 8123, so unless you've changed it, you'll need to open <code>8123/tcp</code> in your firewall. If you're running a single device tunnel with a Home Assistant VM or docker container, it's as simple as opening the device's firewall on <code>8123/tcp</code>. If you have a Home Assistant appliance inside a routed subnet, you'll need to open the port in the router's firewall, and ensure the firewall's rule set allows {{Term|WAN}} devices to initiate connections on that port. The syntax for doing so varies based on your firewall tool.

* <code>firewalld</code>: <code>sudo firewall-ctl --zone=<wireguard interface zone> --add-port 8123/tcp --permanent</code>
* <code>ufw</code>: <code>sudo ufw allow 8123 proto tcp</code>

== Step 3: Verify connection ==
After opening the port, verify that Home Assistant is accessible via its 44Net IP address on the port you opened. Visit that IP and port in your browser by going to <code>http://<IP>:<port></code>. It's important to use <code>http</code> rather than <code>https</code> if you haven't set up TLS.

== Optional: Set up TLS without a domain ==
By default, your connection to Home Assistant is unencrypted. Since it contains control traffic that affects the physical devices in your home, encrypting that connection with TLS is recommended. TLS certificates can be obtained for free through Let's Encrypt, and renewal can be automated via the Certbot project from the Electronic Frontier Foundation.

Let's Encrypt will issue short-lived certificates for bare IP addresses, which are valid for 6 days. Unfortunately, the Let's Encrypt app for Home Assistant OS doesn't support this, so HAOS users should either use a domain or run Certbot on another machine and find a way to automate updating the certificate in HAOS. Users running Home Assistant in a container can run Certbot in the container or on the host system.

=== Set up Certbot ===
First, [https://certbot.eff.org/instructions?ws=other&os=pip install Certbot according to its instructions]. Stop before the "Choose how you'd like to run Certbot" step. We'll be using a slightly different command because we're request a short-lived certificate for a bare IP.

Next, ensure your firewall has port 80 open on the machine where you installed Certbot. When you request a certificate for an IP, Certbot will start a temporary web server on port 80, and tell the Let's Encrypt server to contact the requested IP on that port. The connection will be through your 44Net IP, so ensure port 80 is open in the correct network zone of your firewall. See [[Firewalling Basics]] for more information.

Users running Certbot inside the same Docker container as Home Assistant, but running their single device tunnel on the host OS, may need to [https://docs.docker.com/engine/network/port-publishing/ create a docker port mapping] in addition to opening the port on their host OS's firewall.

To run Certbot and acquire the certificate, run the following command:

<code>sudo certbot certonly --standalone --preferred-profile shortlived --ip-address <your 44Net IP></code>

If it succeeds, you should see output including the following:

<nowiki>Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/<your 44Net IP>/fullchain.pem
Key is saved at: /etc/letsencrypt/live/<your 44Net IP>/privkey.pem
This certificate expires on 2026-08-24.
These files will be updated when the certificate renews.</nowiki>

Set up automatic renewal of your certificate by running the following command:

<code>echo "0 0,12 * * * root /opt/certbot/bin/python -c 'import random; import time; time.sleep(random.random() * 3600)' && sudo certbot renew -q" | sudo tee -a /etc/crontab > /dev/null</code>

This will add a cron job that checks every 12 hours whether it needs to renew your certificate, and renews the certificate if it's close to expiring.

=== Configure Docker bind mount ===
If you set up Certbot on your host machine rather than in your container, you'll need to set up a [https://docs.docker.com/get-started/docker-concepts/running-containers/sharing-local-files/#file-permissions-for-docker-access-to-host-files bind mount] for the certificate and private key to be accessible to Home Assistant. Keep track of the directory inside the container that the mount is mapped to, and use that path in the next step.

=== Configure SSL in Home Assistant ===
Next, go to <code>Settings > System > Network</code>, and in the HTTP server section, fill in the paths for your SSL certificate and SSL key. Then, go to the IP banning section, and set the number of login attempts before ban to something other than -1 to prevent people from brute forcing your Home Assistant password.Finally, verify that your configuration is working by restarting Home Assistant to make it use the new configuration, and then visiting your 44Net IP. Your browser should indicate that your connection to Home Assistant is now encrypted.

== Optional: Set up TLS with a domain ==
By default, your connection to Home Assistant is unencrypted. Since it contains control traffic that affects the physical devices in your home, encrypting that connection with TLS is recommended. TLS certificates can be obtained for free through Let's Encrypt, and renewal can be automated via the Certbot project from the Electronic Frontier Foundation.

If you have a domain name, it can be used with Let's Encrypt and Certbot to easily set up an automatically renewing TLS certificate. If you're running Home Assistant OS, you can use the [https://github.com/home-assistant/addons/blob/master/letsencrypt/DOCS.md instructions for the Let's Encrypt app]. If you're running Home Assistant in a docker container, apps are not supported, so you'll need to set up Certbot yourself.

=== Set up Certbot ===
First, [https://certbot.eff.org/instructions?ws=other&os=pip install Certbot according to its instructions]. Before running the <code>certbot</code> command, ensure your firewall has port 80 open on the machine where you installed Certbot. When you request a certificate for an IP, Certbot will start a temporary web server on port 80, and tell the Let's Encrypt server to contact the requested IP on that port. The connection will be through your 44Net IP, so ensure port 80 is open in the correct network zone of your firewall. See [[Firewalling Basics]] for more information.

Users running Certbot inside the same Docker container as Home Assistant, but running their single device tunnel on the host OS, may need to [https://docs.docker.com/engine/network/port-publishing/ create a docker port mapping] in addition to opening the port on their host OS's firewall.

Set up automatic renewal of your certificate by running the following command:

<code>echo "0 0,12 * * * root /opt/certbot/bin/python -c 'import random; import time; time.sleep(random.random() * 3600)' && sudo certbot renew -q" | sudo tee -a /etc/crontab > /dev/null</code>

This will add a cron job that checks every 12 hours whether it needs to renew your certificate, and renews the certificate if it's close to expiring.

=== Configure SSL in Home Assistant ===
Next, go to <code>Settings > System > Network</code>, and in the HTTP server section, fill in the paths for your SSL certificate and SSL key. Then, go to the IP banning section, and set the number of login attempts before ban to something other than -1 to prevent people from brute forcing your Home Assistant password.Finally, verify that your configuration is working by restarting Home Assistant to make it use the new configuration, and then visiting your 44Net IP. Your browser should indicate that your connection to Home Assistant is now encrypted.

== Troubleshooting ==
=== Certificate authority fails to download challenge from the Certbot temporary web server ===
This typically happens if your 44Net tunnel is not up, or if your firewall is not configured to allow inbound connections on port 80. Try the following troubleshooting steps
* Use <code>ifconfig</code> to verify that your 44Net Connect tunnel is up. You should see a WireGuard interface with your 44Net IP address.
* Visit [https://connect.44net.cloud/tunnels the 44Net Connect tunnels page] and ensure your tunnel shows up as being connected.
* Check your firewall configuration and make sure port 80 is open. If you have recently changed your firewall configuration, reload the firewall.
* If running Certbot inside your Home Assistant docker container, make sure the docker container has its port 80 mapped to the host's port 80.

Home Assistant

2026-08-19T17:29:44Z

KN6DWI: Wrote TLS setup with domain and troubleshooting

Home Assistant is an open source home automation server. It has integrations for a wide variety of devices, and allows you to create custom dashboards for viewing sensor information and controlling your devices. If you want to access your Home Assistant instance from anywhere, but cannot port forward due to {{Term|CGNAT}}, making your instance publicly accessible via 44Net is one solution. Even if your home internet isn't behind CGNAT, it likely has a dynamic IP, which would require you to set up dynamic DNS for your instance to maintain consistent external access. A 44Net IP lets your instance be publicly accessible at a fixed IPv4 address for free.

Prerequisites:
* A Home Assistant instance (set this up '''before''' exposing it to the internet so that setup cannot be hijacked)
* A 44Net Connect account

== Step 1: Set up your tunnel ==
Home Assistant OS is designed to operate less like a general purpose computing device and more like an appliance. There is no package manager with which to install higher level firewall tools, and the Home Assistant WireGuard application is unmaintained as of 2026. If you're setting up a fresh Home Assistant installation for the express purpose of exposing it to 44Net, the easiest option is running it as a docker container on a device with a [[44Net_Connect/Single Device Tunnel | single device tunnel]]. If you have a dedicated Home Assistant appliance, such as a Home Assistant Green or a Raspberry Pi running Home Assistant OS on {{Term|bare metal}}, the recommended configuration is to put it on a [[44Net_Connect/Routed Subnet | routed subnet]].

== Step 2: Open port ==
Now that your Home Assistant instance and 44Net Connect tunnel are set up, it's time to open the required port in your firewall to make Home Assistant publicly accessible. The default Home Assistant port is 8123, so unless you've changed it, you'll need to open <code>8123/tcp</code> in your firewall. If you're running a single device tunnel with a Home Assistant VM or docker container, it's as simple as opening the device's firewall on <code>8123/tcp</code>. If you have a Home Assistant appliance inside a routed subnet, you'll need to open the port in the router's firewall, and ensure the firewall's rule set allows {{Term|WAN}} devices to initiate connections on that port. The syntax for doing so varies based on your firewall tool.

* <code>firewalld</code>: <code>sudo firewall-ctl --zone=<wireguard interface zone> --add-port 8123/tcp --permanent</code>
* <code>ufw</code>: <code>sudo ufw allow 8123 proto tcp</code>

== Step 3: Verify connection ==
After opening the port, verify that Home Assistant is accessible via its 44Net IP address on the port you opened. Visit that IP and port in your browser by going to <code>http://<IP>:<port></code>. It's important to use <code>http</code> rather than <code>https</code> if you haven't set up TLS.

== Optional: Set up TLS without a domain ==
By default, your connection to Home Assistant is unencrypted. Since it contains control traffic that affects the physical devices in your home, encrypting that connection with TLS is recommended. TLS certificates can be obtained for free through Let's Encrypt, and renewal can be automated via the Certbot project from the Electronic Frontier Foundation.

Let's Encrypt will issue short-lived certificates for bare IP addresses, which are valid for 6 days. Unfortunately, the Let's Encrypt app for Home Assistant OS doesn't support this, so HAOS users should either use a domain or run Certbot on another machine and find a way to automate updating the certificate in HAOS. Users running Home Assistant in a container can run Certbot in the container or on the host system.

=== Set up Certbot ===
First, [https://certbot.eff.org/instructions?ws=other&os=pip install Certbot according to its instructions]. Stop before the "Choose how you'd like to run Certbot" step. We'll be using a slightly different command because we're request a short-lived certificate for a bare IP.

Next, ensure your firewall has port 80 open on the machine where you installed Certbot. When you request a certificate for an IP, Certbot will start a temporary web server on port 80, and tell the Let's Encrypt server to contact the requested IP on that port. The connection will be through your 44Net IP, so ensure port 80 is open in the correct network zone of your firewall. See [[Firewalling Basics]] for more information.

Users running Certbot inside the same Docker container as Home Assistant, but running their single device tunnel on the host OS, may need to [https://docs.docker.com/engine/network/port-publishing/ create a docker port mapping] in addition to opening the port on their host OS's firewall.

To run Certbot and acquire the certificate, run the following command:

<code>sudo certbot certonly --standalone --preferred-profile shortlived --ip-address <your 44Net IP></code>

If it succeeds, you should see output including the following:

<nowiki>Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/<your 44Net IP>/fullchain.pem
Key is saved at: /etc/letsencrypt/live/<your 44Net IP>/privkey.pem
This certificate expires on 2026-08-24.
These files will be updated when the certificate renews.</nowiki>

Set up automatic renewal of your certificate by running the following command:

<code>echo "0 0,12 * * * root /opt/certbot/bin/python -c 'import random; import time; time.sleep(random.random() * 3600)' && sudo certbot renew -q" | sudo tee -a /etc/crontab > /dev/null</code>

This will add a cron job that checks every 12 hours whether it needs to renew your certificate, and renews the certificate if it's close to expiring.

=== Configure Docker bind mount ===
If you set up Certbot on your host machine rather than in your container, you'll need to set up a [https://docs.docker.com/get-started/docker-concepts/running-containers/sharing-local-files/#file-permissions-for-docker-access-to-host-files bind mount] for the certificate and private key to be accessible to Home Assistant. Keep track of the directory inside the container that the mount is mapped to, and use that path in the next step.

=== Configure SSL in Home Assistant ===
Next, go to <code>Settings > System > Network</code>, and in the HTTP server section, fill in the paths for your SSL certificate and SSL key. Then, go to the IP banning section, and set the number of login attempts before ban to something other than -1 to prevent people from brute forcing your Home Assistant password.Finally, verify that your configuration is working by restarting Home Assistant to make it use the new configuration, and then visiting your 44Net IP. Your browser should indicate that your connection to Home Assistant is now encrypted.

== Optional: Set up TLS with a domain ==
By default, your connection to Home Assistant is unencrypted. Since it contains control traffic that affects the physical devices in your home, encrypting that connection with TLS is recommended. TLS certificates can be obtained for free through Let's Encrypt, and renewal can be automated via the Certbot project from the Electronic Frontier Foundation.

If you have a domain name, it can be used with Let's Encrypt and Certbot to easily set up an automatically renewing TLS certificate. If you're running Home Assistant OS, you can use the [https://github.com/home-assistant/addons/blob/master/letsencrypt/DOCS.md instructions for the Let's Encrypt app]. If you're running Home Assistant in a docker container, apps are not supported, so you'll need to set up Certbot yourself.

=== Set up Certbot ===
First, [https://certbot.eff.org/instructions?ws=other&os=pip install Certbot according to its instructions]. Before running the <code>certbot</code> command, ensure your firewall has port 80 open on the machine where you installed Certbot. When you request a certificate for an IP, Certbot will start a temporary web server on port 80, and tell the Let's Encrypt server to contact the requested IP on that port. The connection will be through your 44Net IP, so ensure port 80 is open in the correct network zone of your firewall. See [[Firewalling Basics]] for more information.

Users running Certbot inside the same Docker container as Home Assistant, but running their single device tunnel on the host OS, may need to [https://docs.docker.com/engine/network/port-publishing/ create a docker port mapping] in addition to opening the port on their host OS's firewall.

Set up automatic renewal of your certificate by running the following command:

<code>echo "0 0,12 * * * root /opt/certbot/bin/python -c 'import random; import time; time.sleep(random.random() * 3600)' && sudo certbot renew -q" | sudo tee -a /etc/crontab > /dev/null</code>

This will add a cron job that checks every 12 hours whether it needs to renew your certificate, and renews the certificate if it's close to expiring.

=== Configure SSL in Home Assistant ===
Next, go to <code>Settings > System > Network</code>, and in the HTTP server section, fill in the paths for your SSL certificate and SSL key. Then, go to the IP banning section, and set the number of login attempts before ban to something other than -1 to prevent people from brute forcing your Home Assistant password.Finally, verify that your configuration is working by restarting Home Assistant to make it use the new configuration, and then visiting your 44Net IP. Your browser should indicate that your connection to Home Assistant is now encrypted.

== Troubleshooting ==
=== Certificate authority fails to download challenge from the Certbot temporary web server ===
This typically happens if your 44Net tunnel is not up, or if your firewall is not configured to allow inbound connections on port 80. Try the following troubleshooting steps
- Use <code>ifconfig</code> to verify that your 44Net Connect tunnel is up. You should see a WireGuard interface with your 44Net IP address.
- Visit [https://connect.44net.cloud/tunnels the 44Net Connect tunnels page] and ensure your tunnel shows up as being connected.
- Check your firewall configuration and make sure port 80 is open. If you have recently changed your firewall configuration, reload the firewall.
- If running Certbot inside your Home Assistant docker container, make sure the docker container has its port 80 mapped to the host's port 80.

Home Assistant

2026-08-19T16:54:29Z

KN6DWI: Minor phrasing edits

Home Assistant

2026-08-19T01:38:12Z

KN6DWI: Added configuring bind mount step

Home Assistant

2026-08-19T01:19:27Z

KN6DWI: Use more specific certbot tutorial link

Home Assistant

2026-08-18T23:15:04Z

KN6DWI: Made both TLS sections H2

Home Assistant

2026-08-18T23:13:24Z

KN6DWI: Section reorganization

Home Assistant

2026-08-17T23:00:38Z

KN6DWI: Added config example and cron job

Home Assistant

2026-08-17T19:00:53Z

KN6DWI: Started explanation on using CertBot without a domain

Home Assistant

2026-08-17T16:53:12Z

KN6DWI: Created without domain and with domain sections

Home Assistant

2026-08-13T18:02:43Z

KN6DWI: Added instructions for setting up TLS

Home Assistant

2026-08-13T17:34:42Z

KN6DWI: Added verify connection, TLS, and troubleshooting sections

Home Assistant

2026-08-07T23:26:35Z

KN6DWI: Added examples for opening the port

Home Assistant

2026-08-07T18:36:36Z

KN6DWI: Added prerequisites and wrote step 2

Home Assistant

2026-08-06T22:25:51Z

KN6DWI: Created Step 1 section

Home Assistant

2026-08-05T22:38:05Z

KN6DWI: Mentioned that the HA WireGuard app is unmaintained

Home Assistant

2026-08-05T22:21:55Z

KN6DWI: Mention that there's no package manager in HA OS

Home Assistant

2026-08-05T22:20:40Z

KN6DWI: Describe recommended configuration, recommend against exposing bare HA OS appliance

Home Assistant

2026-08-03T21:37:29Z

KN6DWI: Remind users they probably have a dynamic IP even if they don't have CGNAT

Firewalling Basics

2026-08-03T19:10:25Z

KN6DWI: /* ufw */

== 44Net Connect and Security ==
44Net Connect provides every device with a public facing IPv4 address, and does not inspect, filter, or block any traffic directed towards 44Net devices. Devices with publicly routable IP addresses face a constant barrage of traffic from various scanners and bots on the internet. Some of them are malicious, and correctly configuring your firewall is a key part of defending against them.

== What does a firewall do? ==
At its most basic, a firewall inspects incoming and outgoing packets, and based on its set of rules, decides whether each packet should be allowed through, dropped, or diverted. Rules may consider a packet's source and destination IP, source and destination interface, port, protocol (TCP vs UDP), or various special flags that may be set. Basic firewall usage is primarily concerned with source/destination IP, source/destination interface, and port. There are several goals we can achieve via firewall rules: allow outside connections to public-facing services, block outside connections to private services, and in case your device is compromised, block outgoing malicious traffic originating from your device.

Outside connections to a public-facing service are typically allowed using a firewall rule that accepts all packets on the port that service is using, regardless of the packet's source IP. Private services, such as those only intended for your LAN, are typically protected by a firewall rule that only accepts packets whose source IP is inside your LAN. Packets sent to that port that originate externally will be dropped. You may have services that are only meant to be accessed from <code>localhost</code>, such as control interfaces accessed only by other software on the same device.

=== Stateful Firewalls ===
Stateful firewalls are capable of remembering information about previous packets, and using it when making later decisions. The most common use for this is connection tracking, a feature enabled by default on many firewalls. Connection tracking remembers when a trusted device, usually one inside your LAN, has initiated a connection to an external device. When the return traffic from the external device comes in, it will be allowed through the firewall, even if the default policy would have otherwise dropped it. It's important to remember this feature when testing your firewall. Even if your device is able to initiate connections to an untrusted device on the outside of your firewall, that device may not be able to initiate a connection to your device, depending on your firewall rules. Most modern firewalls, such as those based on <code>iptables</code> or <code>nftables</code>, are stateful. If for some reason this behavior is undesirable, it can be overridden with rules that explicitly drop the unwanted external traffic.

Stateful firewalls also enable various advanced security features that are outside the scope of this guide, such as those utilizing TCP sequence numbers.

Stateless firewalls are not capable of remembering previous packets, and handle each packet as if it's completely unrelated to all other packets.

== Configuration Recommendations ==
When configuring any kind of security policy, best practice is to apply the '''principle of least privilege.''' This means that a person or device is given the minimum level of access to perform their job. This minimizes attack surface (the ways in which a malicious party can attack your network) and minimizes damage if a device or user's credentials are compromised. When it comes to configuring a firewall, that means only opening the ports on which you're actually running services, and only allowing communication between network segments if it's actually necessary.

For example, some people confine Internet of Things (IoT) devices to their own {{term|VLAN}} due to their often poor security. In such a configuration, you might allow devices from the regular LAN to initiate connections to the IoT devices, but not the other way around, to prevent a compromised IoT device from attacking the rest of your network. We recommend a similar configuration for your 44Net subnet. Some take it a step further, and block {{term|WAN}} access from the IoT VLAN to prevent devices from sending telemetry to their manufacturer.

When restricting access between devices on your internal network, it can be helpful to use a policy that explicitly rejects disallowed packets rather than silently dropping them. This feedback can be helpful when troubleshooting, as it immediately lets you know that packets are being blocked by firewall policy rather than something like a port mismatch or a hostname/IP typo. Reject policies should not be used for WAN-facing interfaces, otherwise you may spend lots of compute power sending packet rejections to automated scanners and other malicious actors on the wider internet.

== Low Level Tools ==
=== iptables ===
<code>iptables</code> is a Linux firewall rule management tool that was deprecated in favor of <code>nftables</code> in 2014. It allows system administrators to define ''tables'' containing ''chains'' of ''rules'' for the treatment of packets.<ref>https://en.wikipedia.org/wiki/Iptables</ref> Both <code>iptables</code> and <code>nftables</code> use the netfilter framework to interface with the Linux kernel.

Modern systems no longer ship with an actual copy of <code>iptables</code>, instead using a compatibility layer that translates its rules to <code>nftables</code>.

=== nftables ===
nftables is the currently maintained Linux firewall rule management tool. It interfaces with the Linux kernel via the netfilter framework, and can be administrated with the <code>nft</code> command line tool as well as editing <code>/etc/nftables.conf</code>. Changes made with the <code>nft</code> tool will not persist between reboots, and must be written into the config file to ensure persistence. It functions similarly to <code>iptables</code>, employing tables of chains of rules, but with no predefined chains and more flexible rules.

[[ File:Netfilter.png | 500px | A diagram illustrating the table, chain, and rule hierarchy used by iptables and nftables. A packet proceeds into the table, through the first chain, and does not match any rules. It proceeds through the second chain, matches the second rule, and makes a routing decision. ]]

While firewall rules can be directly configured with <code>nft</code>, this is not recommended. The output of <code>sudo nft list ruleset</code> is extremely verbose and not well formatted. <code>nft</code> provides few formatting options for this output. See the next section for user-friendly tools that interface with nftables.

== High Level Tools ==
=== firewalld ===
<code>firewalld</code> is an <code>nftables</code>-based CLI firewall management tool. It ships by default on CentOS, Fedora, OpenSUSE, RHEL, SUSE Enterprise, and EndeavourOS, and is packaged for many more distributions. It introduces the idea of a "zone," which is a named set of policies that an interface can be assigned to. Each zone has a target, which is set to <code>default</code>, <code>DROP</code>, <code>REJECT</code>, or <code>ACCEPT</code>. These targets determine what action will be taken on packets in the zone that don't match any of the rules, services, or ports.

* <code>default</code> will accept ICMP and drop everything else.
* <code>DROP</code> will discard packets without notifying the sender.
* <code>REJECT</code> will discard the packet and notify the sender of its rejection.
* <code>ACCEPT</code> will allow the packet through.

Check your current zone configuration by running <code>sudo firewalld --list-all-zones</code>.

It's best to put public-facing interfaces into a <code>default</code> or <code>DROP</code> target zone. <code>ACCEPT</code> will allow unwanted or malicious traffic, and <code>REJECT</code> will spend lots of bandwidth replying to the barrage of traffic from bots scanning the internet. Devices owned by you but publicly accessible from the internet are typically put in a demilitarized zone (DMZ), a network area with only some access to the LAN. This typically involves preventing DMZ devices from initiating connections to LAN devices, but allowing the opposite. <code>firewalld</code> comes with a <code>dmz</code> zone by default, and this is a good place to put the interface that faces your 44Net subnet. (Note that your LAN interface must also be in a default accept zone for it to allow initiating connections to DMZ devices.)

<code>firewalld</code> can be controlled using the <code>firewall-cmd</code> utility, or by editing the config file at <code>/etc/firewalld</code>. Typical policy changes introduced using <code>firewall-cmd</code> are called "runtime" changes, and will not persist after a restart of the service or a reboot. Permanent changes can be made by adding the <code>--permanent</code> flag, or by introducing runtime changes and then invoking <code>firewall-cmd --runtime-to-permanent</code>, which saves all current runtime changes to permanent configuration.

Services are a <code>firewalld</code> abstraction containing a list of ports, protocols, destinations, and optionally a list of firewall helper modules to be loaded if the service is enabled. They make it easy to toggle these configuration groups, rather than having to toggle every rule in them individually. They can be configured using <code>firewall-cmd</code> or by creating an XML file in <code>/etc/firewalld/services/</code>. See <code>man firewalld.service</code> for more information on services. As an example, the following command would enable the <code>ssh</code> service in the <code>public</code> zone.

<nowiki>sudo firewall-cmd --permanent --zone public --add-service ssh</nowiki>

Another advantage of using services is that the service definition can be edited, and then it will apply to all zones with that service enabled when firewalld is reloaded. firewalld can be reloaded using <code>sudo firewall-cmd --reload</code>.

=== ufw ===
Uncomplicated Firewall is a CLI program designed for easily managing a netfilter firewall. It also supports GUI management via the <code>gufw</code> tool. When running, the active firewall rules can be viewed with <code>sudo ufw status</code>. If you want to see the firewall rules while <code>ufw</code> is not running, use <code>sudo ufw show added</code>. It uses a simple syntax with property names rather than flags. For the very simple operation of opening a port without utilizing any optional parameters, you need not even specify property names. One can allow TCP connections on port 22 (for example, to allow an SSH server) and start UFW as follows:

<nowiki>sudo ufw allow 22/tcp
sudo ufw enable</nowiki>

It also allows comments by specifying the <code>comment</code> property and enclosing the actual comment in quotes. For example,

<code>sudo ufw allow 22/tcp comment 'SSH port'</code>

will show in the <code>ufw status</code> output as

<nowiki>
To Action From
-- ------ ----
22/tcp ALLOW Anywhere # SSH port</nowiki>

<code>ufw</code> uses similar targets to <code>firewalld</code>, except it uses <code>deny</code> instead of <code>DROP</code>. To put a 44Net subnet in a {{term:DMZ}}, apply the following rules.
<nowiki>
sudo ufw reject in on <subnet interface> to <LAN interface>
sudo ufw accept in on <LAN interface> to <subnet interface></nowiki>

By default, Docker writes its own <code>iptables</code> rules and ignores <code>ufw</code> rules. This can cause conflicts and security issues in combination with <code>ufw</code>.<ref>“Uncomplicated Firewall - ArchWiki.” 2024. Archlinux.Org. https://wiki.archlinux.org/title/Uncomplicated_Firewall.</ref>
If you wish to use <code>ufw</code> on a system that has Docker, consider [https://docs.docker.com/engine/network/firewall-nftables#migrating-from-iptables-to-nftables migrating Docker to nftables.]

== Verifying Configuration ==
After configuring your firewall, it's important to test the configuration to ensure that it's working how you think it is. This can be done with the help of a few command line tools.

=== Verify that a port is open or closed ===
To test whether a port is properly opened or closed, you can use set up a <code>netcat</code> listener a device behind the firewall, and use <code>curl</code> to connect to it with a device outside the firewall. On the inside device, run <code>nc -l -p <port></code> (but replace <code>port</code> with your desired port) to start the listener. If you have a service that normally runs on this port, you'll need to temporarily stop it so that <code>netcat</code> can bind to the port. On the outside device, run <code>curl <hostname>:<port></code>, and if the port is open, you'll see some text pop up on the <code>netcat</code> listener indicating that it received an HTTP GET request.

== Troubleshooting ==
=== Traffic is supposed to pass but only works intermittently ===
This can happen when you have duplicate or conflicting firewall rules. This can happen if you add runtime rules that are already part of persistent configuration, or add the same rules to multiple scripts or configuration files. Re-read your firewall rules and ensure there are no duplicates or conflicting rules. It may help to restore the last known working configuration, and start from there.

=== Traffic is supposed to pass but is not going through ===
Common causes:
* The firewall was not reloaded after changing configuration files
* The device has its own firewall ''and'' is behind the router firewall, and one of them is missing allow rules.
* Traffic has not been allowed on the correct protocol (TCP instead of UDP, or vice versa)

== References ==

Firewalling Basics

2026-08-03T18:22:21Z

KN6DWI: Recommend putting 44Net devices in a DMZ

== 44Net Connect and Security ==
44Net Connect provides every device with a public facing IPv4 address, and does not inspect, filter, or block any traffic directed towards 44Net devices. Devices with publicly routable IP addresses face a constant barrage of traffic from various scanners and bots on the internet. Some of them are malicious, and correctly configuring your firewall is a key part of defending against them.

== What does a firewall do? ==
At its most basic, a firewall inspects incoming and outgoing packets, and based on its set of rules, decides whether each packet should be allowed through, dropped, or diverted. Rules may consider a packet's source and destination IP, source and destination interface, port, protocol (TCP vs UDP), or various special flags that may be set. Basic firewall usage is primarily concerned with source/destination IP, source/destination interface, and port. There are several goals we can achieve via firewall rules: allow outside connections to public-facing services, block outside connections to private services, and in case your device is compromised, block outgoing malicious traffic originating from your device.

Outside connections to a public-facing service are typically allowed using a firewall rule that accepts all packets on the port that service is using, regardless of the packet's source IP. Private services, such as those only intended for your LAN, are typically protected by a firewall rule that only accepts packets whose source IP is inside your LAN. Packets sent to that port that originate externally will be dropped. You may have services that are only meant to be accessed from <code>localhost</code>, such as control interfaces accessed only by other software on the same device.

=== Stateful Firewalls ===
Stateful firewalls are capable of remembering information about previous packets, and using it when making later decisions. The most common use for this is connection tracking, a feature enabled by default on many firewalls. Connection tracking remembers when a trusted device, usually one inside your LAN, has initiated a connection to an external device. When the return traffic from the external device comes in, it will be allowed through the firewall, even if the default policy would have otherwise dropped it. It's important to remember this feature when testing your firewall. Even if your device is able to initiate connections to an untrusted device on the outside of your firewall, that device may not be able to initiate a connection to your device, depending on your firewall rules. Most modern firewalls, such as those based on <code>iptables</code> or <code>nftables</code>, are stateful. If for some reason this behavior is undesirable, it can be overridden with rules that explicitly drop the unwanted external traffic.

Stateful firewalls also enable various advanced security features that are outside the scope of this guide, such as those utilizing TCP sequence numbers.

Stateless firewalls are not capable of remembering previous packets, and handle each packet as if it's completely unrelated to all other packets.

== Configuration Recommendations ==
When configuring any kind of security policy, best practice is to apply the '''principle of least privilege.''' This means that a person or device is given the minimum level of access to perform their job. This minimizes attack surface (the ways in which a malicious party can attack your network) and minimizes damage if a device or user's credentials are compromised. When it comes to configuring a firewall, that means only opening the ports on which you're actually running services, and only allowing communication between network segments if it's actually necessary.

For example, some people confine Internet of Things (IoT) devices to their own {{term|VLAN}} due to their often poor security. In such a configuration, you might allow devices from the regular LAN to initiate connections to the IoT devices, but not the other way around, to prevent a compromised IoT device from attacking the rest of your network. We recommend a similar configuration for your 44Net subnet. Some take it a step further, and block {{term|WAN}} access from the IoT VLAN to prevent devices from sending telemetry to their manufacturer.

When restricting access between devices on your internal network, it can be helpful to use a policy that explicitly rejects disallowed packets rather than silently dropping them. This feedback can be helpful when troubleshooting, as it immediately lets you know that packets are being blocked by firewall policy rather than something like a port mismatch or a hostname/IP typo. Reject policies should not be used for WAN-facing interfaces, otherwise you may spend lots of compute power sending packet rejections to automated scanners and other malicious actors on the wider internet.

== Low Level Tools ==
=== iptables ===
<code>iptables</code> is a Linux firewall rule management tool that was deprecated in favor of <code>nftables</code> in 2014. It allows system administrators to define ''tables'' containing ''chains'' of ''rules'' for the treatment of packets.<ref>https://en.wikipedia.org/wiki/Iptables</ref> Both <code>iptables</code> and <code>nftables</code> use the netfilter framework to interface with the Linux kernel.

Modern systems no longer ship with an actual copy of <code>iptables</code>, instead using a compatibility layer that translates its rules to <code>nftables</code>.

=== nftables ===
nftables is the currently maintained Linux firewall rule management tool. It interfaces with the Linux kernel via the netfilter framework, and can be administrated with the <code>nft</code> command line tool as well as editing <code>/etc/nftables.conf</code>. Changes made with the <code>nft</code> tool will not persist between reboots, and must be written into the config file to ensure persistence. It functions similarly to <code>iptables</code>, employing tables of chains of rules, but with no predefined chains and more flexible rules.

[[ File:Netfilter.png | 500px | A diagram illustrating the table, chain, and rule hierarchy used by iptables and nftables. A packet proceeds into the table, through the first chain, and does not match any rules. It proceeds through the second chain, matches the second rule, and makes a routing decision. ]]

While firewall rules can be directly configured with <code>nft</code>, this is not recommended. The output of <code>sudo nft list ruleset</code> is extremely verbose and not well formatted. <code>nft</code> provides few formatting options for this output. See the next section for user-friendly tools that interface with nftables.

== High Level Tools ==
=== firewalld ===
<code>firewalld</code> is an <code>nftables</code>-based CLI firewall management tool. It ships by default on CentOS, Fedora, OpenSUSE, RHEL, SUSE Enterprise, and EndeavourOS, and is packaged for many more distributions. It introduces the idea of a "zone," which is a named set of policies that an interface can be assigned to. Each zone has a target, which is set to <code>default</code>, <code>DROP</code>, <code>REJECT</code>, or <code>ACCEPT</code>. These targets determine what action will be taken on packets in the zone that don't match any of the rules, services, or ports.

* <code>default</code> will accept ICMP and drop everything else.
* <code>DROP</code> will discard packets without notifying the sender.
* <code>REJECT</code> will discard the packet and notify the sender of its rejection.
* <code>ACCEPT</code> will allow the packet through.

Check your current zone configuration by running <code>sudo firewalld --list-all-zones</code>.

It's best to put public-facing interfaces into a <code>default</code> or <code>DROP</code> target zone. <code>ACCEPT</code> will allow unwanted or malicious traffic, and <code>REJECT</code> will spend lots of bandwidth replying to the barrage of traffic from bots scanning the internet. Devices owned by you but publicly accessible from the internet are typically put in a demilitarized zone (DMZ), a network area with only some access to the LAN. This typically involves preventing DMZ devices from initiating connections to LAN devices, but allowing the opposite. <code>firewalld</code> comes with a <code>dmz</code> zone by default, and this is a good place to put the interface that faces your 44Net subnet. (Note that your LAN interface must also be in a default accept zone for it to allow initiating connections to DMZ devices.)

<code>firewalld</code> can be controlled using the <code>firewall-cmd</code> utility, or by editing the config file at <code>/etc/firewalld</code>. Typical policy changes introduced using <code>firewall-cmd</code> are called "runtime" changes, and will not persist after a restart of the service or a reboot. Permanent changes can be made by adding the <code>--permanent</code> flag, or by introducing runtime changes and then invoking <code>firewall-cmd --runtime-to-permanent</code>, which saves all current runtime changes to permanent configuration.

Services are a <code>firewalld</code> abstraction containing a list of ports, protocols, destinations, and optionally a list of firewall helper modules to be loaded if the service is enabled. They make it easy to toggle these configuration groups, rather than having to toggle every rule in them individually. They can be configured using <code>firewall-cmd</code> or by creating an XML file in <code>/etc/firewalld/services/</code>. See <code>man firewalld.service</code> for more information on services. As an example, the following command would enable the <code>ssh</code> service in the <code>public</code> zone.

<nowiki>sudo firewall-cmd --permanent --zone public --add-service ssh</nowiki>

Another advantage of using services is that the service definition can be edited, and then it will apply to all zones with that service enabled when firewalld is reloaded. firewalld can be reloaded using <code>sudo firewall-cmd --reload</code>.

=== ufw ===
Uncomplicated Firewall is a CLI program designed for easily managing a netfilter firewall. It also supports GUI management via the <code>gufw</code> tool. When running, the active firewall rules can be viewed with <code>sudo ufw status</code>. If you want to see the firewall rules while <code>ufw</code> is not running, use <code>sudo ufw show added</code>. It uses a simple syntax with property names rather than flags. For the very simple operation of opening a port without utilizing any optional parameters, you need not even specify property names. One can allow TCP connections on port 22 (for example, to allow an SSH server) and start UFW as follows:

<nowiki>sudo ufw allow 22/tcp
sudo ufw enable</nowiki>

It also allows comments by specifying the <code>comment</code> property and enclosing the actual comment in quotes. For example,

<code>sudo ufw allow 22/tcp comment 'SSH port'</code>

will show in the <code>ufw status</code> output as

<nowiki>
To Action From
-- ------ ----
22/tcp ALLOW Anywhere # SSH port</nowiki>

By default, Docker writes its own <code>iptables</code> rules and ignores <code>ufw</code> rules. This can cause conflicts and security issues in combination with <code>ufw</code>.<ref>“Uncomplicated Firewall - ArchWiki.” 2024. Archlinux.Org. https://wiki.archlinux.org/title/Uncomplicated_Firewall.</ref>
If you wish to use <code>ufw</code> on a system that has Docker, consider [https://docs.docker.com/engine/network/firewall-nftables#migrating-from-iptables-to-nftables migrating Docker to nftables.]

== Verifying Configuration ==
After configuring your firewall, it's important to test the configuration to ensure that it's working how you think it is. This can be done with the help of a few command line tools.

=== Verify that a port is open or closed ===
To test whether a port is properly opened or closed, you can use set up a <code>netcat</code> listener a device behind the firewall, and use <code>curl</code> to connect to it with a device outside the firewall. On the inside device, run <code>nc -l -p <port></code> (but replace <code>port</code> with your desired port) to start the listener. If you have a service that normally runs on this port, you'll need to temporarily stop it so that <code>netcat</code> can bind to the port. On the outside device, run <code>curl <hostname>:<port></code>, and if the port is open, you'll see some text pop up on the <code>netcat</code> listener indicating that it received an HTTP GET request.

== Troubleshooting ==
=== Traffic is supposed to pass but only works intermittently ===
This can happen when you have duplicate or conflicting firewall rules. This can happen if you add runtime rules that are already part of persistent configuration, or add the same rules to multiple scripts or configuration files. Re-read your firewall rules and ensure there are no duplicates or conflicting rules. It may help to restore the last known working configuration, and start from there.

=== Traffic is supposed to pass but is not going through ===
Common causes:
* The firewall was not reloaded after changing configuration files
* The device has its own firewall ''and'' is behind the router firewall, and one of them is missing allow rules.
* Traffic has not been allowed on the correct protocol (TCP instead of UDP, or vice versa)

== References ==