Prerequisites

Before installing Arctic, ensure your environment meets these requirements.

What You Need

The agent verifies your license on every startup. Once the license expires the agent keeps running and routing existing traffic, but it blocks writes (creating peers, services, and routes) until you supply a valid license. See Licensing for the full expiry behaviour, and the license command reference for checking status and updating a license.

Network Requirements

All agents must be able to communicate with each other. Open these ports on each server:

Your workstation (CLI) needs to reach the first peer on port 8080. Peers need to reach each other on all three ports (8080, 51840, 61000).

As of v1.4.2 the agent serves port 8080 over TLS 1.3 by default, so the CLI, other peers, and any health checks speak HTTPS to it. See TLS and trust for how agents prove their identity.

If your hosts sit behind a mandatory egress proxy (HTTP_PROXY / HTTPS_PROXY set at the systemd level), exempt the peer networks from it with NO_PROXY before installing -- otherwise agent-to-agent traffic is sent to the proxy and peers show unreachable. See the agent reference for the drop-in to add.

Cloud Provider Settings

Arctic forwards network traffic that is not addressed to the host itself. AWS and Azure both drop such traffic at the hypervisor by default, before it ever reaches the host, so routed traffic is silently lost even though the agent's own rules are correct. Apply the relevant setting to every peer running in that cloud.

AWS: disable source/destination check

In the console: EC2 > Instances > select the instance > Actions > Networking > Change source/destination check > select Stop and save. Or with the CLI:

aws ec2 modify-instance-attribute \
    --instance-id i-0123456789abcdef0 \
    --no-source-dest-check

This setting can only be changed after the instance has been launched, not at creation time.

Azure: enable IP forwarding

In the portal: open the VM, Networking > Network settings > click the network interface > IP configurations > set Enable IP forwarding to Enabled and apply. Or with the CLI:

az network nic update \
    --name <nic-name> \
    --resource-group <resource-group> \
    --ip-forwarding true

Apply it to every NIC that carries peer or service traffic.

Prepare Linux Hosts

As of v1.4.0, the agent talks directly to the kernel over netlink to manage network interfaces, routing, packet marking, and nftables (an xtables fallback exists but is less feature complete). Because of this, you no longer need to install nftables, NetworkManager, tc, or iproute2 to run the agent.

The only required preparation is removing the host firewall.

Why remove the firewall?

Removing the host firewall keeps the initial setup simple, since the agent manages its own kernel-level rules and a host firewall can interfere with them. This is the easiest path to a working cluster.

If you would rather keep a firewall in place, you can leave it installed and instead harden it manually by opening the ports listed above. This is only recommended if you are comfortable managing firewall rules yourself. On firewalld hosts (the RHEL family), opening the ports is not sufficient on its own; see Keeping firewalld below.

AlmaLinux / Rocky Linux / RHEL

dnf remove -y firewalld

Ubuntu / Debian

ufw disable && apt remove -y ufw

Keeping firewalld (RHEL family)

If you keep firewalld instead of removing it, opening the three ports covers traffic addressed to the host itself (the API, and the tunnel and TProxy listeners), but it does not cover traffic the agent forwards on behalf of a service. On a peer that is the source of a service, client traffic enters on the LAN and leaves through the agent's tunnel interface (tpt-*) or a MACVLAN service interface (svc_*). Because the agent creates those interfaces outside of firewalld, they belong to no zone, and firewalld's default forward policy rejects the packets before the agent's own rules ever see them. The symptom is a client that reaches the peer but gets Packet filtered (an ICMP admin-prohibited reject) instead of a reply.

The fix is to place the agent's forwarding interfaces in the same zone as your LAN/uplink interface and make sure that zone allows intra-zone forwarding. Use your uplink's zone below if it is not the default public; assigning the interfaces to the trusted zone is not enough, because forwarding across two different zones is still rejected.

firewalld 1.1 and newer (AlmaLinux 9 and 10 both qualify) accepts a trailing + wildcard, so a single pair of rules covers every current and future tunnel and service interface:

# Match your uplink's zone; public is the default.
sudo firewall-cmd --permanent --zone=public --add-forward
sudo firewall-cmd --permanent --zone=public --add-interface="tpt+"
sudo firewall-cmd --permanent --zone=public --add-interface="svc+"
sudo firewall-cmd --reload

Next Steps

Once your hosts are prepared, proceed to Installation to install the Arctic agent and CLI.