Networking

This page covers day-to-day network administration on InterGenOS: bringing interfaces up with DHCP or static addressing, joining a VPN, and reasoning about the firewall posture. InterGenOS ships GNOME 49 on Wayland, so most desktop users will manage connections through the graphical network panel, while administrators and contributors can drop to the command line for the same operations.

Networking on InterGenOS inherits the system’s overall stance: security is not first. It is only. Defaults are conservative, nothing listens on a public interface unless you ask it to, and the network never carries telemetry off your machine. The goal is a machine you understand, can modify, and can trust.

Default Network Posture

Two defaults shape everything else on this page:

• Services bind to localhost. Any server package shipped by InterGenOS binds exclusively to 127.0.0.1 by default. Services do not listen on public interfaces unless you deliberately edit their configuration to allow it. This means a freshly installed system exposes effectively no network attack surface on its own.
• No traffic leaves on its own. InterGenOS collects zero analytics, crash reports, or usage statistics, and it does not auto-update. The only outbound connections your system makes are the ones you initiate, plus package operations you explicitly run (such as pkm sync against the signed mirror).

Because of the localhost-bind default, opening a service to the network is a deliberate, auditable act rather than something you have to discover and switch off after the fact.

Managing Connections

From the desktop

On the GNOME 49 Wayland session, use the Settings -> Network (wired) and Settings -> Wi-Fi panels, or the system status menu in the top bar, to connect to wired and wireless networks. This is the recommended path for laptops and workstations: DHCP works out of the box, and the panel handles Wi-Fi credentials, per-connection settings, and VPN profiles.

Static vs. DHCP

DHCP is the default for new connections. To assign a static address from the desktop, open the connection’s settings in the Network or Wi-Fi panel, switch the IPv4 (or IPv6) method from Automatic (DHCP) to Manual, and enter the address, prefix/netmask, gateway, and DNS servers for your network. Apply the change and reconnect the interface for it to take effect.

NetworkManager is the default network management daemon and is enabled at boot. Administrators can manage connections from the command line with nmcli or the text-based nmtui, which drive the same connections as the desktop panels. (systemd-networkd ships as well but is disabled by default; it is available for hosts that prefer a networkd-based configuration.)

For headless or server-style hosts, configure the same wired/static/DHCP choices with nmcli, which creates and edits NetworkManager connection profiles directly. Use nmcli connection to add, modify, and bring profiles up or down without the desktop panel.

VPN

InterGenOS supports standard Linux VPN clients. The desktop network panel can import and manage VPN connections, and command-line clients can be installed and configured directly.

A VPN changes which interface and DNS your traffic uses, so keep the localhost-bind default in mind: a VPN tunnel does not, by itself, expose any local service to the remote network. If you want a service reachable over a VPN, you still have to bind it beyond 127.0.0.1 and open the firewall for it deliberately.

No VPN client ships by default — there is no preinstalled WireGuard, OpenVPN, or Tailscale on a fresh install. Install the client you need with pkm (for example WireGuard or OpenVPN), then configure it through the desktop network panel or its own command-line tooling.

Firewalling

Because shipped services bind to localhost by default, the network attack surface of a default install is minimal before you add a firewall on top. For systems that expose services intentionally, or that sit on untrusted networks, configure a host firewall to make the allowed-traffic policy explicit and auditable.

InterGenOS layers several controls beneath the firewall that are relevant to network exposure:

• AppArmor in enforce mode confines system daemons, limiting what a compromised network-facing service can reach.
• Aggressive systemd sandboxing restricts each service’s address families. The baseline RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6 directive, applied across system daemons, denies access to other socket families entirely.
• No default passwords. InterGenOS does not ship services with blank or default credentials, so an exposed service is not also a free login.

The host firewall is nftables (the nft command), enabled by default with a default-deny posture: inbound traffic is denied unless a rule allows it. InterGenOS does not ship firewalld or ufw, so rules are expressed and audited directly in nftables.

For the firewall configuration itself, and for the reasoning behind the network-exposure defaults, see the security handbook page on Network Security & Firewalling.

Verifying Network State

Treat what the system reports as the source of truth rather than assuming. To confirm what is actually listening and where, inspect the live socket and routing state on your machine (for example with the standard ss and ip tooling), and compare it against your intended policy. If a service is listening on anything other than 127.0.0.1, that exposure was configured deliberately and should match a firewall rule you can point to.

Further Reading

• Network Security & Firewalling — the security-handbook treatment of firewall policy and network exposure.
• Attack-Surface Minimization — why InterGenOS ships almost nothing listening by default.
• Users, Groups & Services — managing the services that may bind to the network.
• Self-Hosting Securely — exposing your own services on purpose, safely.
• FAQ — common questions about defaults and behavior.