Virtual IPs (VIPs)

Virtual IPs (VIPs) are additional IP addresses bound to a server’s network interface. We use them to provide stable listener IPs for:

This is an operations runbook. Canonical inventories live in Reference:

Network inventories live in Reference: Networks. This runbook is also linked from Networks & addressing.

Preconditions

You are on VPN/LAN (see VPN access (support)).
You have SSH access to the relevant server (see Servers and Servers & logins).
You have a clear change request: what VIP, what it’s for, and what should listen on it.

Server: web.core.lef
Used for: public HTTP(S) listeners (forwarded from public IPs by EVEO firewall)
Source of truth for public IP → VIP mapping: Firewall & public ingress (reference)

Server: web.core.lef
Used for: public DNS hostnames that should be reachable only when the client is on VPN (enforced by EVEO firewall policy).
Source of truth for public IP → VIP mapping: Firewall & public ingress (reference)

Server: proxy.core.lef
Used for: per-endpoint *.db.lef listeners (same port, different VIP per endpoint)
Source of truth for hostname → VIP → backend mapping: TCP proxy (facts)

On the target server:

ip -br addr show
ip -4 addr show dev ens18
grep -n \"^auto ens18:\" /etc/network/interfaces

Use this when you need a new internal VIP for HTTP(S) ingress on web.core.lef (either public or VPN-only).

Pick/confirm the VIP and public IP mapping
- Confirm which internal VIP you’re adding and why (avoid collisions; check Core LAN).
- Ensure EVEO will forward the required public IP to this VIP (provider-managed change).
- If this is a VPN-only ingress IP, confirm the firewall policy is “allow only from SSL-VPN, block from WAN/internet”.
- Update the inventory table in Firewall & public ingress (reference) as part of the same PR.
Add the VIP to web.core.lef
- Current config shape is documented in web.core.lef (Debian /etc/network/interfaces).
- Add a new alias stanza (example uses /32 netmask like existing ingress VIPs):

auto ens18:9
iface ens18:9 inet static
    address <vip-ip>
    netmask 255.255.255.255

sudo ifup ens18:9
ip -4 addr show dev ens18

Ensure NGINX listens on the VIP
- Update the NGINX vhost layout (see NGINX ingress (public vs internal)).
  - public VIPs: sites-enabled/public/
  - VPN-only VIPs: sites-enabled/vpn/
- Validate + reload:

sudo nginx -t
sudo systemctl reload nginx
sudo ss -lntp | grep nginx

curl -I http://<vip-ip>/ -H 'Host: <public-hostname>'

Update docs & derived maps
- Confirm web.core.lef reflects the VIP range/config.
- Regenerate derived Core LAN map (repo): npm run generate:core-lan-address-map

Use this when adding a new *.db.lef endpoint that should listen on the standard DB port but on a dedicated VIP.

Pick/confirm the VIP
- Choose a VIP from the DB VIP pool on proxy.core.lef.
- Check TCP proxy (facts) to avoid selecting a VIP already assigned to an endpoint.
Add the VIP to proxy.core.lef (if it isn’t already in the pool)
- Current config shape is documented in proxy.core.lef (Debian /etc/network/interfaces).
- Add a new alias stanza (example matches the current pool’s netmask style):

auto ens18:13
iface ens18:13 inet static
    address <vip-ip>
    netmask 255.255.255.0

sudo ifup ens18:13
ip -4 addr show dev ens18

At minimum, HAProxy must listen on <vip-ip>:<port> and forward to the correct backend.

Update DNS + docs
- Update DNS for <name>.db.lef to point at the VIP (done in DNS tooling; see Domains and dns.core.lef).
- Add the new row to TCP proxy (facts) (this is the canonical mapping).
- Regenerate derived Core LAN map (repo): npm run generate:core-lan-address-map

If a VIP is part of a documented pool (e.g., DB VIP pool on proxy.core.lef) but not assigned to a specific endpoint in TCP proxy (facts), treat it as “reserved/unallocated” until you intentionally allocate it.
Prefer consuming existing reserved pool IPs before extending the pool.