Static IP Addressing

Static IP Addressing

By default every ARROW VM uses DHCP and picks up an address automatically. When a site needs a fixed address, there are two ways to set one, and you should reach for them in this order:

• In the device request (recommended). The request form has optional static IP fields per VM. ARROW bakes the address into the image so the VM boots straight onto it, with no console work. This works for any VM type: VMware, VirtualBox, QEMU/KVM, and the rest.
• By hand on the VM. For a VM that was already built on DHCP, a network that changed after delivery, or a VM with no working network yet, set the address from the hypervisor’s local console.

If you deploy through ARROW Manager, you have a third path: set the address in the deployment form or under Network Settings; see ARROW Manager VM Deployment.

---

First: LAN address vs VPN address

ARROW VMs have two different addresses, and they are configured in two different places. Setting the wrong one is the most common reason a “static IP” appears not to work.

Address	Example	Where it comes from	Can you set it here?
Wired LAN address	192.168.1.50	DHCP, the device request, or manual config	Yes
VPN overlay address	100.64.196.14	Assigned automatically by the ARROW VPN (NetBird) when the device enrolls	No

The 100.64.x.x overlay address is handed out by the ARROW VPN. It is not something the operating system’s network settings control, and it is not the address you pin. A static IP only ever sets the wired LAN address the VM uses to reach the local network and the internet. Once the LAN side has a working route out, the VPN address comes up on its own.

The cleanest option of all is a DHCP reservation

Before pinning a static address anywhere, consider asking the site to reserve one for the VM’s MAC address in their DHCP server. The VM stays on DHCP, always gets the same address, and there is nothing to maintain on the guest. Reach for a static IP only when the network has no DHCP at all, or a firewall rule requires a pre-registered address.

---

Option 1: Set it in the device request

When you create a device request for a VM, each VM slot has an optional Static IP block. Fill in the three fields to pin that VM’s address; leave the address blank to keep it on DHCP.

Field	Example	Notes
Static IP / CIDR	192.168.1.50/24	The address with its prefix. The /24 is required. Blank means DHCP.
Gateway	192.168.1.1	The default gateway on that subnet.
DNS	1.1.1.1, 8.8.8.8	One or more DNS servers, comma-separated.

Each VM in a multi-VM request has its own block, so you can mix static and DHCP VMs in a single submission. ARROW writes the address into the image during the build, and it takes effect on the VM’s first boot, so the machine comes up already on its fixed address with no console work. The rest of the form is covered in Device Requests.

This applies to Linux VM images. Windows VMs set their address through Windows’ own network settings, and cloud targets (Azure, AWS, GCP) get addressing from the platform.

The address still has to match the network

A static address baked at request time only works once the VM is attached to the matching subnet and VLAN on the hypervisor. If a VM with a baked address comes up unreachable, that is almost always a bridge, port group, or VLAN mismatch rather than the address itself. See Troubleshooting.

---

Option 2: Set it manually on the VM

Reach for this when a VM was built on DHCP and now needs a fixed address, when the network changed after delivery, or when the VM has no working network yet and so cannot reach the Portal. Every step is done from the hypervisor’s local console (the Proxmox “Console” button, the virt-manager graphical console, or a serial console), because without a working address you cannot reach the VM over SSH.

VM credentials

Log in at the console with the credentials generated at build time. Retrieve them from the ARROW Portal on your device’s details page.

Kali and Parrot based ARROW images (the large majority of client images) manage the wired interface with NetworkManager. The build ships exactly one connection profile:

• Connection name: Wired-eth0
• Interface: eth0 (images boot with net.ifnames=0, so the NIC is always eth0, never ens18 or enp0s3)
• File: /etc/NetworkManager/system-connections/Wired-eth0.nmconnection

Because there is exactly one profile and it always wins on boot, edit Wired-eth0 in place rather than creating a new connection. A second connection you add by hand loses to Wired-eth0 on the next boot and your change appears to revert. Ubuntu Server images are the exception; see Ubuntu Server images.

Method A: nmtui (recommended)

nmtui is a text menu that needs no network and no exact command syntax, which makes it the safest choice at a console.

sudo nmtui

1. Choose Edit a connection.
2. Select Wired-eth0 and press Edit.
3. Set IPv4 CONFIGURATION from Automatic to Manual, then Show.
4. Under Addresses, add the address in CIDR form, for example 192.168.1.50/24. The /24 (the prefix) is required; without it the address will not work.
5. Set Gateway, for example 192.168.1.1.
6. Add DNS servers, for example 1.1.1.1 and 8.8.8.8.
7. Leave Require IPv4 addressing for this connection checked.
8. Select OK, then Back.
9. Choose Activate a connection, deactivate Wired-eth0, then activate it again so the new settings take effect.

Quit nmtui and jump to Verify.

---

Method B: nmcli (one-shot commands)

If you would rather type commands, nmcli does the same thing in one pass. Adjust the address, gateway, and DNS to the target network:

sudo nmcli connection modify "Wired-eth0" \
  ipv4.method manual \
  ipv4.addresses 192.168.1.50/24 \
  ipv4.gateway 192.168.1.1 \
  ipv4.dns "1.1.1.1,8.8.8.8" \
  ipv4.may-fail no

# Re-activate the connection so the change applies now (nmcli modify alone does nothing until you do this)
sudo nmcli connection down "Wired-eth0" && sudo nmcli connection up "Wired-eth0"

Two details that trip people up:

• The address needs its prefix. Use 192.168.1.50/24, not 192.168.1.50. DNS in nmcli is comma-separated ("1.1.1.1,8.8.8.8").
• modify does not apply anything by itself. You must bring the connection down and up (or reboot) for the new address to take effect.

If you are not sure of the connection name on a given image, list them first:

nmcli device status
nmcli -f NAME,DEVICE,TYPE connection show

Modify whichever connection is bound to eth0 (it is Wired-eth0 on every standard ARROW image).

---

Method C: edit the profile file directly

This matches exactly what the image builder writes, and is useful when you want to script it or paste a known-good block. Edit the profile:

sudo nano /etc/NetworkManager/system-connections/Wired-eth0.nmconnection

Set the [ipv4] section to:

[ipv4]
method=manual
address1=192.168.1.50/24,192.168.1.1
dns=1.1.1.1;8.8.8.8;
may-fail=false

Note the keyfile format: address1 combines the address (with prefix) and the gateway, separated by a comma. DNS servers are separated by semicolons with a trailing semicolon. Then fix the permissions (NetworkManager ignores world-readable keyfiles), reload, and bring the profile up:

sudo chmod 600 /etc/NetworkManager/system-connections/Wired-eth0.nmconnection
sudo nmcli connection reload
sudo nmcli connection up "Wired-eth0"

---

Verify

Check the settings applied, then test the gateway first and the internet second. Testing the gateway is the step that actually tells you whether the address is usable, because most static-IP problems are not in the guest at all (see Troubleshooting).

ip addr show eth0        # the address you set should be listed
ip route                 # a default route via your gateway should be present
ping -c3 10.30.30.1      # ping YOUR GATEWAY first — this must succeed before anything else can
ping -c3 1.1.1.1         # then test the route out to the internet
ping -c3 example.com     # then test DNS as well

If the gateway ping fails but the address is set, do not touch the IPv4 settings again; the address is fine and the problem is on the network side. Go straight to Troubleshooting.

Once the LAN side reaches the internet, the ARROW VPN comes up on its own and the device reappears in the Portal with its 100.64.x.x overlay address. If it does not re-enroll within a minute or two, restart networking:

sudo systemctl restart NetworkManager

---

Revert to DHCP

To put the interface back on automatic addressing:

sudo nmcli connection modify "Wired-eth0" \
  ipv4.method auto ipv4.addresses "" ipv4.gateway "" ipv4.dns ""
sudo nmcli connection down "Wired-eth0" && sudo nmcli connection up "Wired-eth0"

---

Ubuntu Server images

Ubuntu Server images use netplan rather than a NetworkManager profile. Edit the netplan file (the exact name varies, commonly /etc/netplan/50-cloud-init.yaml) and set the interface to static:

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: false
      addresses: [192.168.1.50/24]
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses: [1.1.1.1, 8.8.8.8]

Apply it:

sudo netplan apply

Then verify exactly as above with ip addr, ip route, and ping.

---

Troubleshooting

The static IP “did not work” and the VM is still on DHCP or unreachable. Work through these in order; one of them is almost always the cause.

The address is set correctly but ping returns “Destination Host Unreachable” from the VM’s own address. For example, the connection shows Manual, 10.30.30.205 / 24, gateway 10.30.30.1, and yet:

$ ping 8.8.8.8
From 10.30.30.205 icmp_seq=1 Destination Host Unreachable
From 10.30.30.205 icmp_seq=2 Destination Host Unreachable

This is not a static-IP problem, and re-editing the IPv4 settings will not fix it. The address applied fine (the replies come from it). “Destination Host Unreachable” originating from the VM’s own address means the VM cannot even reach its gateway at the link layer: it sends an ARP request for the gateway and nothing answers. In other words, the virtual NIC is not actually attached to the subnet you configured. Diagnose it from the guest:

ping -c3 10.30.30.1                 # ping the gateway directly. If this also says
                                    # "Destination Host Unreachable", the gateway is not reachable at layer 2.
ip neigh                            # the gateway will show FAILED or INCOMPLETE (no MAC learned)
sudo arping -I eth0 10.30.30.1      # does anything on the wire answer for the gateway?

If the gateway does not answer, the fix is on the hypervisor and the network, not in the guest:

• Wrong bridge or VLAN. The VM’s virtual NIC is on a bridge (or an untagged VLAN) that does not carry the configured subnet. In Proxmox, attach net0 to the correct vmbrX and set the VLAN tag for that subnet; in VMware/ESXi, confirm the adapter is Connected and on a port group whose VLAN ID matches the subnet (see VMware / ESXi, which also covers hardware version and the VMXNET3/E1000e adapter on ESXi 6.7); in VirtualBox, use a bridged adapter on the right interface.
• Wrong subnet or gateway. Confirm the address, mask, and gateway match the segment the NIC is really on. In the example above the DNS server is 10.30.20.11 (a 10.30.20.x address) while the host is on 10.30.30.x; if the real LAN is 10.30.20.0/24, then 10.30.30.205 with gateway 10.30.30.1 is on the wrong subnet entirely and the gateway can never answer. Check with the site’s network administrator.
• Address already in use. Confirm nothing else holds 10.30.30.205.

Only once ping <gateway> succeeds will the internet, DNS, and the ARROW VPN come up.

You set the VPN address, not the LAN address. 100.64.x.x is the ARROW VPN overlay address, assigned automatically by NetBird. It is not set through the OS network settings and it is not the address you pin here. Configure the wired LAN address instead, and the overlay address will follow once the VM can reach the internet.

You edited a different connection than Wired-eth0. ARROW images ship one profile, Wired-eth0, and it takes priority on every boot. If you created a new connection, or edited an auto-created “Wired connection 1,” it loses to Wired-eth0 and your change appears to revert. Always edit Wired-eth0 in place.

You forgot the prefix. nmcli/nmtui need the address in CIDR form, for example 192.168.1.50/24. Without the /24 the address is invalid or lands on a /32 with no local subnet.

You changed the config but never re-activated it. nmcli connection modify and editing the file do nothing until you reload and bring the connection up (nmcli connection down "Wired-eth0" && nmcli connection up "Wired-eth0", or reboot).

The permissions on the edited file are wrong. NetworkManager silently ignores a keyfile that is not chmod 600 owned by root. Fix with sudo chmod 600 /etc/NetworkManager/system-connections/Wired-eth0.nmconnection and sudo nmcli connection reload.

The interface is not eth0. Standard ARROW images force eth0, so this is rare. If a custom build disabled the serial console (which also carries the net.ifnames=0 flag), the NIC may come up as ens18 or similar. Run nmcli device status to find the real interface name and bind the profile to it with nmcli connection modify "Wired-eth0" connection.interface-name <name>.