44Net Wiki - Recent changes [en]

44Net Connect/Quick Start/Fedora

KN6DWI — Thu, 20 Aug 2026 17:42:58 GMT

Updated automatic start instructions to use automatically generated systemd unit

@@ Line 50: / Line 50: @@
 == Starting the Tunnel Automatically ==
-* On Linux distributions that use <code>systemd</code>, creating a <code>systemd</code> unit is the recommended way to automatically start the tunnel.
+* 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>.
-* Create a unit file in <code>/etc/systemd/system/</code>, for example <code>/etc/systemd/system/44net-tunnel.service</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>.
-* Paste the following into the file.
+* 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.
- <nowiki>
+* 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]]

RPKI and ROAs on 44Net

KI5QKX — Thu, 20 Aug 2026 17:39:44 GMT

mw push

New page

{{DISPLAYTITLE:RPKI and ROAs on 44Net}}

This page answers a recurring question:

''Why can’t 44Net publish ROAs?''

The short answer is that 44Net subnets are administered by ARIN under "legacy" status, and ARIN does not provide RPKI or IRR services for legacy resources that not covered by an ARIN service agreement.

== The basics ==

RPKI (Resource Public Key Infrastructure) is the system used to make cryptographically verifiable statements about Internet number resources.

A ROA (Route Origin Authorization) is one of those statements. It says which ASN is authorized to originate a prefix.

On many modern networks, operators expect ROAs to be 'Valid'. If a route is announced without a valid ROA, some providers may treat it as 'Invalid' and filter it out. Others may treat it as 'NotFound' and accept it, but that is not guaranteed.

== What that means for 44Net ==

Operationally, that means some providers support 44Net prefixes without a valid ROA, while others may not. Right now, there is no alternative but to petition the provider to make an exception for the route, or to use a provider that is already familiar with handling 44Net space.

== What is ARDC doing about it? ==

The foundation monitors the situation and available options as part of its responsibility to steward the address space. If and when there is a development worth sharing, ARDC will update the community. In the meantime, ARDC is happy to discuss exceptions with providers and customers on a case-by-case basis.

== What about SWIP? ==

ARDC does not SWIP customer subnets, because the address space is leased to the customer, not transferred. We also cannot currently add customer- or provider-specific text to the parent ARIN Whois or RDAP record.

== External references ==

* [https://www.arin.net/resources/guide/legacy/ ARIN: Legacy Resources at ARIN]
* [https://www.arin.net/resources/manage/routingsecurity/ ARIN: Routing Security Eligibility FAQs]
* [https://www.arin.net/resources/manage/rpki/ ARIN: Resource Public Key Infrastructure]
* [https://www.arin.net/resources/registry/manage/netmod/ ARIN: Network Modifications]

== Related pages ==

* [[44Net and Modern Internet Assumptions]]
* [[Routing your allocation via BGP]]
* [[Guide for ISPs]]
* [[BGP]]
* [[FAQ]]

[[Category:Reference]]
[[Category:Infrastructure]]
[[Category:BGP]]
[[Category:Routing]]

44Net Connect/Quick Start/Debian based distributions

KN6DWI — Thu, 20 Aug 2026 17:32:32 GMT

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

@@ Line 57: / Line 57: @@
 == Starting the Tunnel Automatically ==
-* On Linux distributions that use <code>systemd</code>, creating a <code>systemd</code> unit is the recommended way to automatically start the tunnel.
+* 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>.
-* Create a unit file in <code>/etc/systemd/system/</code>, for example <code>/etc/systemd/system/44net-tunnel.service</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>.
-* Paste the following into the file.
+* 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.
- <nowiki>
+* 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]]

Guide for ISPs

KI5QKX — Thu, 20 Aug 2026 17:02:12 GMT

mw push

New page

{{DISPLAYTITLE:Guide for ISPs and upstream providers}}

This guide is for an ISP, hosting company, cloud provider, or transit provider whose customer wants to route a 44Net IPv4 prefix.

44Net is a community network for amateur radio, experimentation, education, and research that includes globally routable IPv4 address space stewarded by Amateur Radio Digital Communications (ARDC).

ARDC remains responsible for the address space. We authorize eligible users to use particular subnets, but we do not sell or transfer them. The [[EULA|44Net End User License Agreement]] contains the formal terms.

In practical terms, your customer has permission from ARDC to use a 44Net subnet, and they want to announce it to the global routing table through your network.

This guide explains how the pieces generally fit together. It is not an agreement between ARDC and the provider. You and your customer can arrange the service according to your normal policies and practices. The customer remains responsible for following ARDC's terms.

== ARDC's role ==

ARDC administers the address space, approves its use, and supplies documentation that an approved user is authorized to announce a prefix.

ARDC is not the customer's ISP. ARDC does not itself provide transit, peering, or BGP sessions, nor does it operate the customer's router, circuit, or hosting environment. All that is done by the customer and its chosen provider.

== Common service arrangements ==

Providers support customer prefixes in several ways. For example:

* '''Provider-originated route:''' the provider originates the customer's prefix from the provider's ASN and delivers the traffic to the customer over a circuit, VLAN, tunnel, or hosted environment.
* '''BGP with the customer:''' the provider establishes a BGP session with the customer. The customer advertises the prefix using its own public ASN or a private ASN assigned or accepted by the provider.
* '''Customer-operated multihoming or transit:''' the customer operates a router under its own public ASN and establishes BGP sessions with one or more transit providers or peers.

ARDC does not require any particular arrangement. Which one works depends on the services you offer and what you and your customer decide to set up.

== Information the provider and customer should agree on ==

Before activation, confirm at least the following where relevant:

=== General ===

* The exact IPv4 prefix to be announced
* Whether the provider or customer will originate the route
* The public origin ASN that will appear in the global routing table
* Any private ASNs used only between the customer and provider

=== BGP session details ===

* BGP neighbor addresses, address families, authentication, timers, and maximum-prefix limits, where applicable
* Import and export policy, including accepted prefix lengths and AS-path requirements
* Any provider communities the customer may use, including blackhole or traffic-engineering communities

=== Practical details ===

* How traffic will be delivered to the customer
* Which party is responsible for the routed interface, VLAN, tunnel, or circuit
* Routing-security and anti-spoofing filters, including acceptance of the 44Net source prefix from the customer
* Any relevant operational contacts, maintenance procedures, monitoring, and the process for withdrawing the route

== Documentation and validation ARDC can provide ==

=== Letter of Authorization ===

The customer can download a Letter of Authorization (LOA) from the [[Portal|44Net Portal]]. The LOA identifies the approved prefix and authorizes the customer to advertise it using BGP. The customer should give the current LOA to the provider.

The LOA shows the prefix, the approved origin ASN or ASNs, and how long the authorization is valid. It confirms that the customer may advertise the prefix, but it does not transfer the address space or create a service agreement between ARDC and the provider.

The ASN in the LOA should match the public origin ASN you expect to see. If the design changes, ask the customer to update the Portal, generate a new LOA, and send it to you before changing the origin, as this allows ARDC to maintain accurate records and ensure compliance with the EULA.

=== Assignment validation ===

ARDC can help a provider confirm that the customer is currently authorized to use the prefix and that the proposed origin ASN matches ARDC's records. The customer's LOA includes a QR code linking to a public 44Net Portal record showing the prefix, authorized user, issue and expiry dates, BGP authorization, and authorized origin ASN or ASNs.

These details should agree with the LOA and applicable IRR route objects. Providers may contact [mailto:noc@ardc.net noc@ardc.net], or the administrative or technical contacts published in Whois/RDAP, to confirm an authorization or resolve a discrepancy.

=== Internet Routing Registry objects ===

For approved direct announcements, ARDC can currently create route objects in RADB and/or ALTDB.

IRR records should identify the same prefix and public origin ASN that will be visible in BGP. A private ASN used only on the customer-provider session is not normally the public origin recorded in the route object.

== Current limitations ==

=== No RPKI ROA ===

ARDC's 44Net ranges are administered by ARIN, which does not offer RPKI for legacy resources. ARDC cannot currently create ARIN-issued Route Origin Authorizations (ROAs). ARDC also does not currently operate a separate RPKI trust anchor for 44Net.

The absence of a ROA means the route is RPKI ''NotFound'', not RPKI ''Invalid''. A provider whose policy requires every customer route to be RPKI ''Valid'' may be unable to accept the prefix under that policy. See [[RPKI and ROAs on 44Net]] for the current explanation and references.

=== No customer-specific ARIN Whois or RDAP record ===

ARDC does not SWIP customer subnets, because the address space is leased to the customer, not transferred. We also cannot currently add customer- or provider-specific text to the parent ARIN Whois or RDAP record.

If your process requires a customer-specific ARIN organization, netblock record, remark, or other registry text, an LOA or third-party IRR object may not be enough. It is worth checking whether you can handle the request as an exception before the customer orders or builds the service. ARDC is generally happy to discuss exceptions further.

== Frequently asked questions ==

=== Does ARDC provide peering or transit? ===

No. ARDC authorizes eligible users to use address space. Those users arrange Internet connectivity, transit, and any peering on their own behalf.

=== Will ARDC establish BGP with us? ===

No. The BGP relationship is between the customer and provider, or between networks selected by the customer. ARDC is not a party to the BGP session.

=== Will ARDC announce the customer's prefix? ===

No. The customer and provider decide which network will originate the prefix and how traffic will reach the customer.

=== Does the customer use ARDC's ASN? ===

No. The customer and provider decide which of their own ASNs will appear in the global routing table. ARDC does not operate a BGP session or originate the route.

=== Does the customer need a public ASN? ===

That depends on the provider's design. A provider may originate the route from its own ASN, establish BGP using a private ASN on the customer-facing session, or require the customer to use a public ASN. A customer normally needs its own public ASN when it originates the route independently, especially when using more than one upstream.

=== Can the provider originate the prefix from its own ASN? ===

Yes. If you will originate the route, your ASN should be recorded as the public origin in the customer's ARDC records, LOA, and applicable IRR route objects. A private ASN used only on the customer-facing session should not be recorded as the public origin if you remove or replace it before announcing the route globally.

=== Is the customer the owner of the prefix? ===

No. ARDC remains owner and steward of the address space and authorizes the customer to use the approved prefix subject to ARDC's terms. The LOA documents authority to advertise the prefix; it does not in any way transfer ownership.

=== Can we accept a route without a ROA? ===

That is a provider policy decision. There is currently no ROA for the route, so validation should return ''NotFound''. Providers that permit ''NotFound'' customer routes may use the LOA, ARDC confirmation, and accepted IRR objects as supporting evidence.

=== What prefix length should we expect? ===

Most direct BGP assignments are between <code>/22</code> and <code>/24</code>. Confirm the exact approved prefix in the customer's current LOA and ARDC's records.

=== Can the customer announce a more-specific route? ===

Check that each route is covered by the customer's current ARDC authorization and appears in the LOA. It should also have a corresponding IRR route object if your process requires one. The customer can ask ARDC to authorize a more-specific route. ARDC does not assign or authorize prefixes smaller than <code>/24</code> for direct announcement, and it does not authorize more-specifics that are not covered by the approved prefix.

=== How long does the authorization remain valid? ===

The current LOA includes the validity dates. Ask the customer for a new LOA when the authorization is renewed or when the prefix or public origin ASN changes. If your systems do not track the expiry date, contact [mailto:noc@ardc.net noc@ardc.net] so we can work out a practical notification process.

=== Who handles routing incidents or abuse? ===

The customer and its provider handle operation of the BGP session, route propagation, traffic delivery, and the customer's systems. Contact [mailto:noc@ardc.net noc@ardc.net] when an incident concerns the validity of a 44Net authorization, an ARDC-maintained routing record, or coordination with ARDC. The customer remains responsible for responding to abuse involving its assigned resources under the applicable ARDC terms.

== Contact ==

For authorization checks, routing-record questions, or coordination concerning an approved 44Net prefix, it is best to contact [mailto:noc@ardc.net noc@ardc.net]. Sending email to the administrative or technical contacts listed in the ARIN Whois record is also acceptable.

When contacting ARDC, please include:

* The exact prefix
* The proposed public origin ASN
* The customer's name or organization
* The provider's name and network operations contact
* The specific record, document, or policy question that needs to be resolved

Do not send BGP passwords or other credentials by email.

== Related pages ==

* [[Routing your allocation via BGP]]
* [[Announcing your allocation directly]]
* [[RPKI and ROAs on 44Net]]
* [[SWIP]]
* [[EULA]]

[[Category:Reference]]
[[Category:BGP]]
[[Category:Infrastructure]]
[[Category:Routing]]

Home Assistant

KN6DWI — Wed, 19 Aug 2026 22:47:42 GMT

Added image of TLS configuration

← Older revision		Revision as of 22:47, 19 August 2026
(One intermediate revision by the same user not shown)
Line 52:		Line 52:

	=== Configure SSL in Home Assistant ===		=== 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.		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 ==		== Optional: Set up TLS with a domain ==
Line 71:		Line 75:

	=== Configure SSL in Home Assistant ===		=== 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.		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 ==		== Troubleshooting ==

File:Home Assistant TLS Settings.png

KN6DWI — Wed, 19 Aug 2026 22:29:15 GMT

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

New page

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

Home Assistant

KN6DWI — Wed, 19 Aug 2026 18:45:09 GMT

Formatting fix

← Older revision		Revision as of 18:45, 19 August 2026
(3 intermediate revisions by the same user not shown)
Line 46:		Line 46:
	<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>		<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.		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 ===		=== Configure Docker bind mount ===
Line 68:		Line 68:
	<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>		<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.		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 ===		=== Configure SSL in Home Assistant ===
Line 74:		Line 74:

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

Term:Cron job

KN6DWI — Wed, 19 Aug 2026 18:39:42 GMT

Formatting fix

← Older revision		Revision as of 18:39, 19 August 2026
Line 1:		Line 1:
	{{TermDefinition		{{TermDefinition
	\| short = Recurring task executed at the specified interval by the cron daemon }}		\| 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.		\| 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}}}		\| mode = {{{mode\|view}}}
	}}		}}

Term:Cron job

KN6DWI — Wed, 19 Aug 2026 18:39:22 GMT

Created term

New page

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

KN6DWI — Wed, 19 Aug 2026 18:36:40 GMT

Create cron job term

@@ Line 18: / Line 18: @@
 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 ==
+== Optional: Set up TLS without a domain ==
-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 Let's Encrypt app]. If you're running Home Assistant in a docker container, apps are not supported, so you'll need to [https://certbot.eff.org/ set up CertBot yourself].
+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.
 == Troubleshooting ==