44Net Connect/Routed Subnet/Fedora RHEL Rocky CentOS - Revision history

KN6DWI: Changed display title to align with existing routed subnet tutorials

2026-07-21T16:55:49Z

Changed display title to align with existing routed subnet tutorials

← Older revision		Revision as of 16:55, 21 July 2026
Line 1:		Line 1:
	{{DISPLAYTITLE:44Net Connect: Routed Subnet on Fedora, RHEL, Rocky, or CentOS}}		{{DISPLAYTITLE:44Net Connect Routed Subnet: Fedora, RHEL, Rocky, or CentOS}}

	This guide is for Fedora, Red Hat Enterprise Linux, Rocky, and CentOS Stream devices. For brevity, the rest of this article will just say Fedora.		This guide is for Fedora, Red Hat Enterprise Linux, Rocky, and CentOS Stream devices. For brevity, the rest of this article will just say Fedora.

KN6DWI: Updated display title

2026-07-21T16:55:18Z

Updated display title

← Older revision		Revision as of 16:55, 21 July 2026
Line 1:		Line 1:
			{{DISPLAYTITLE:44Net Connect: Routed Subnet on Fedora, RHEL, Rocky, or CentOS}}

	This guide is for Fedora, Red Hat Enterprise Linux, Rocky, and CentOS Stream devices. For brevity, the rest of this article will just say Fedora.		This guide is for Fedora, Red Hat Enterprise Linux, Rocky, and CentOS Stream devices. For brevity, the rest of this article will just say Fedora.

KN6DWI: Added link to Firewalling Basics (page does not yet exist)

2026-07-21T16:45:37Z

Added link to Firewalling Basics (page does not yet exist)

← Older revision		Revision as of 16:45, 21 July 2026
Line 138:		Line 138:
	== Firewall Configuration ==		== Firewall Configuration ==
	Fedora comes with <code>firewalld</code> installed and enabled by default. <code>firewalld</code> uses [https://firewalld.org/documentation/zone/ zones] to determine the trust level of a connection. On Fedora, all interfaces start in the <code>FedoraWorkstation</code> zone, which is has a <code>default</code> target. The <code>default</code> target drops all traffic except ICMP packets, so it's recommended to move it to another zone that permits your desired traffic or modify the FedoraWorkstation zone. Additionally, the <code>FedoraWorkstation</code> zone blocks traffic on ports below 1024, with the exception of SSH and Samba. Hosting a web server on either of the traditional ports (80 or 443) will require adding services to the <code>FedoraWorkstation</code> zone, or moving the subnet interface to a zone that permits traffic on those ports.		Fedora comes with <code>firewalld</code> installed and enabled by default. <code>firewalld</code> uses [https://firewalld.org/documentation/zone/ zones] to determine the trust level of a connection. On Fedora, all interfaces start in the <code>FedoraWorkstation</code> zone, which is has a <code>default</code> target. The <code>default</code> target drops all traffic except ICMP packets, so it's recommended to move it to another zone that permits your desired traffic or modify the FedoraWorkstation zone. Additionally, the <code>FedoraWorkstation</code> zone blocks traffic on ports below 1024, with the exception of SSH and Samba. Hosting a web server on either of the traditional ports (80 or 443) will require adding services to the <code>FedoraWorkstation</code> zone, or moving the subnet interface to a zone that permits traffic on those ports.

			See [[Firewalling Basics]] for more information.

	== Setting up Routing ==		== Setting up Routing ==

KN6DWI: Removed pi specific language

2026-07-21T16:04:50Z

Removed pi specific language

← Older revision		Revision as of 16:04, 21 July 2026
Line 113:		Line 113:

	=== Ethernet Hot Plugging Workaround ===		=== Ethernet Hot Plugging Workaround ===
	At present, <code>kea</code> does not support hot plugging interfaces. This means that ethernet devices must have at least one client at the time the DHCP server starts, otherwise it will not properly bind to the interface. If you plan on hot plugging ethernet devices ~~on your Pi~~, this can be worked around by configuring <code>service-sockets-max-retries</code> to an extremely large number such as 9223372036854775807, the upper limit of a signed 64-bit integer. You may also wish to increase <code>service-sockets-retry-wait-time</code>, which specifies the retry time in milliseconds, though the default time of 5000 ms is typically fine. These options should go in the <code>interfaces-config</code> section at the top of your <code>Dhcp4</code> section in <code>/etc/kea/kea-dhcp4.conf</code>. Here is an example:		At present, <code>kea</code> does not support hot plugging interfaces. This means that ethernet devices must have at least one client at the time the DHCP server starts, otherwise it will not properly bind to the interface. If you plan on hot plugging ethernet devices, this can be worked around by configuring <code>service-sockets-max-retries</code> to an extremely large number such as 9223372036854775807, the upper limit of a signed 64-bit integer. You may also wish to increase <code>service-sockets-retry-wait-time</code>, which specifies the retry time in milliseconds, though the default time of 5000 ms is typically fine. These options should go in the <code>interfaces-config</code> section at the top of your <code>Dhcp4</code> section in <code>/etc/kea/kea-dhcp4.conf</code>. Here is an example:

	<nowiki>		<nowiki>

KN6DWI: Clarified firewalld zone requirements

2026-07-21T00:52:32Z

Clarified firewalld zone requirements

← Older revision		Revision as of 00:52, 21 July 2026
Line 189:		Line 189:
	== Troubleshooting ==		== Troubleshooting ==
	=== Clients receive DHCP address but can't ping router interface ===		=== Clients receive DHCP address but can't ping router interface ===
	If clients plugged into the router are receiving DHCP addresses, but their traffic isn't being allowed to pass and they can't ping the router's interface, the firewall rules for the subnet interface are likely misconfigured. Even when there are routing rules, clients are typically able to ping the router's ethernet interface. Not being able to ping it may indicate that firewall rules are dropping the traffic to that interface.		If clients plugged into the router are receiving DHCP addresses, but their traffic isn't being allowed to pass and they can't ping the router's interface, the firewall rules for the subnet interface are likely misconfigured. Even when there are routing rules, clients are typically able to ping the router's ethernet interface. Not being able to ping it may indicate that firewall rules are dropping the traffic to that interface. If you're testing client connectivity by having the client create an outbound connection, ensure the subnet interface is in a <code>firewalld</code> zone that will permit outgoing connections to the relevant recipient.

	=== No route to outside hosts, but can ping router interface ===		=== No route to outside hosts, but can ping router interface ===

KN6DWI: Created two subsections in troubleshooting section

2026-07-21T00:50:29Z

Created two subsections in troubleshooting section

← Older revision		Revision as of 00:50, 21 July 2026
Line 188:		Line 188:

	== Troubleshooting ==		== Troubleshooting ==
			=== Clients receive DHCP address but can't ping router interface ===
			If clients plugged into the router are receiving DHCP addresses, but their traffic isn't being allowed to pass and they can't ping the router's interface, the firewall rules for the subnet interface are likely misconfigured. Even when there are routing rules, clients are typically able to ping the router's ethernet interface. Not being able to ping it may indicate that firewall rules are dropping the traffic to that interface.

			=== No route to outside hosts, but can ping router interface ===
			If clients can ping the router interface, but attempting to ping any other devices shows "no route to host," the routing rules are likely misconfigured. In this circumstance, it's a useful troubleshooting step to ping the WireGuard interface, since this is the next hop from the subnet interface. The route between these is the one that's manually set up using <code>ip rule</code> in the tutorial.

			If you're experiencing issues with routing, ensure all necessary rules are present, and check for duplicate rules. Duplicate rules often have the effect of dropping traffic rather than routing through one of the two copies of the rule.

KN6DWI: Pasted in Setting up Routing with minor modifications from Pi routed subnet page

2026-07-20T23:28:28Z

Pasted in Setting up Routing with minor modifications from Pi routed subnet page

@@ Line 139: / Line 139: @@
 Fedora comes with <code>firewalld</code> installed and enabled by default. <code>firewalld</code> uses [https://firewalld.org/documentation/zone/ zones] to determine the trust level of a connection. On Fedora, all interfaces start in the <code>FedoraWorkstation</code> zone, which is has a <code>default</code> target. The <code>default</code> target drops all traffic except ICMP packets, so it's recommended to move it to another zone that permits your desired traffic or modify the FedoraWorkstation zone. Additionally, the <code>FedoraWorkstation</code> zone blocks traffic on ports below 1024, with the exception of SSH and Samba. Hosting a web server on either of the traditional ports (80 or 443) will require adding services to the <code>FedoraWorkstation</code> zone, or moving the subnet interface to a zone that permits traffic on those ports.
-== Setting Up Routing ==
+== Setting up Routing ==
 == Troubleshooting ==

KN6DWI: Pasted in Setting up DHCP section from Pi routed subnet page

2026-07-20T22:03:33Z

Pasted in Setting up DHCP section from Pi routed subnet page

@@ Line 54: / Line 54: @@
 <code>sudo nmcli con up <name of new connection></code>
 == Setting up DHCP ==
-=== Configure Interface ===
+[https://www.isc.org/kea/ Kea] is the recommended DHCP server for setting up a routed subnet. <code>dhcpd</code> is deprecated as of 2022.
 == Firewall Configuration ==

KN6DWI: Pasted in Network Interface section from raspberry pi routed subnet page

2026-07-20T21:54:57Z

Pasted in Network Interface section from raspberry pi routed subnet page

← Older revision		Revision as of 21:54, 20 July 2026
Line 23:		Line 23:

	== Setting Up The Network Interface ==		== Setting Up The Network Interface ==
			The recommended way to set up a Linux device as the router for your subnet is with two ethernet interfaces. The second can be provided by a USB ethernet adapter if your router's motherboard doesn't have multiple ports on its NIC or via a PCIe card. This section has the steps that are required regardless of whether you're using ethernet or WiFi. If you're using WiFi, you'll also need the steps in the following section. Otherwise, you can skip them.

			=== Step 1: Create a new connection in nmcli ===
			<code>nmcli</code> is the CLI interface for NetworkManager, which is the high level network configuration tool included
			in Fedora and many other Linux distributions. These configuration steps can be completed using the NetworkManager GUI, but many people operate their devices in "headless" mode (without a screen or keyboard) and use SSH to remotely configure it. Thus, this tutorial uses a CLI tool to accommodate that use case.
			An <code>nmcli</code> "connection" is an abstraction representing a network configuration attached to a device. Create a new connection by running

			<code>sudo nmcli con add con-name <name> ifname <interface name> type <type></code>.

			You can name the connection whatever you like, but it's recommended to name it something descriptive. For example, if you're configuring a 44net routed subnet for <code>eth1</code>, you might name it <code>44net-eth1</code>. The interface name is the name of the interface you're using, as described by <code>ifconfig</code>. The type is either <code>wifi</code> or <code>ethernet</code>. For a WiFi interface, you must also specify the BSSID (network name) by adding the parameter <code>ssid <BSSID></code> at the end.

			=== Step 2: Configure the IP ===
			Set the IPv4 method to manual using the following command:

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

			Next, set the IP range for this interface.

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

			Your subnet should be specified in CIDR notation. At this point, if you're configuring an ethernet interface, you're ready to start it up. If you're configuring a WiFi interface, don't start your interface yet, and move on to the next section for additional configuration.

			=== Step 3: Starting the Interface ===
			First, disable the existing connection, which is likely named <code>netplan-<interface></code>. If you're using <code>eth1</code> for your 44net clients, it may look like <code>netplan-eth1</code>. If you are configuring your Fedora machine over SSH, be careful not to deactivate the connection over which your SSH is traveling.

			<code>sudo nmcli con down <name of existing connection></code>

			After deactivating the regular connection, activate your new connection. If this succeeds, you're good to go.

			<code>sudo nmcli con up <name of new connection></code>

	== Setting up DHCP ==		== Setting up DHCP ==

KN6DWI: Wrote firewall configuration section

2026-07-20T18:55:52Z

Wrote firewall configuration section

← Older revision		Revision as of 18:55, 20 July 2026
Line 28:		Line 28:

	== Firewall Configuration ==		== Firewall Configuration ==
			Fedora comes with <code>firewalld</code> installed and enabled by default. <code>firewalld</code> uses [https://firewalld.org/documentation/zone/ zones] to determine the trust level of a connection. On Fedora, all interfaces start in the <code>FedoraWorkstation</code> zone, which is has a <code>default</code> target. The <code>default</code> target drops all traffic except ICMP packets, so it's recommended to move it to another zone that permits your desired traffic or modify the FedoraWorkstation zone. Additionally, the <code>FedoraWorkstation</code> zone blocks traffic on ports below 1024, with the exception of SSH and Samba. Hosting a web server on either of the traditional ports (80 or 443) will require adding services to the <code>FedoraWorkstation</code> zone, or moving the subnet interface to a zone that permits traffic on those ports.

	== Setting Up Routing ==		== Setting Up Routing ==

	== Troubleshooting ==		== Troubleshooting ==