Skip to content

DNS settings break in WireGuard configs when hostname changes after deployment #14784

@dguido

Description

@dguido

Problem Description

When running ./algo update-users after the server's hostname has changed, WireGuard client configurations are generated with incorrect DNS server IPs. This causes DNS resolution to fail for all WireGuard clients.

Root Cause

The DNS server IPs (local_service_ip and local_service_ipv6) are calculated based on the server's hostname during each run:

# From config.cfg
local_service_ip: "{{ '172.16.0.1' | ipmath(1048573 | random(seed=algo_server_name + ansible_fqdn)) }}"
local_service_ipv6: "{{ 'fd00::1' | ipmath(1048573 | random(seed=algo_server_name + ansible_fqdn)) }}"

Since these values use ansible_fqdn (the current hostname) as part of the random seed, they produce different IPs if the hostname changes. This means:

  1. Initial deployment with hostname "server1" → DNS IP: 172.16.X.Y
  2. Hostname changes to "server2"
  3. Running update-users → DNS IP: 172.16.A.B (different!)
  4. All WireGuard clients now have the wrong DNS server IP

Impact

  • All WireGuard clients lose DNS resolution capability after update-users
  • Users must manually update DNS settings in all client configs
  • IPsec clients are not affected (they use different DNS configuration)

Steps to Reproduce

  1. Deploy Algo server
  2. Note the DNS IP in generated WireGuard configs
  3. Change the server's hostname
  4. Run ./algo update-users
  5. Check new WireGuard configs - DNS IP will be different
  6. Existing clients can no longer resolve DNS

Proposed Solution

Save the calculated local_service_ip and local_service_ipv6 values to the .config.yml file during initial deployment, then read these saved values during update-users instead of recalculating them.

Implementation Details

  1. During initial deployment:

    • Calculate local_service_ip and local_service_ipv6 as currently done
    • Save these values to .config.yml
  2. During update-users:

    • Check if local_service_ip and local_service_ipv6 exist in .config.yml
    • If yes: use the saved values
    • If no: calculate and save them (for backwards compatibility)
  3. This ensures DNS IPs remain stable across hostname changes

Related Issues

Workaround

Until fixed, users experiencing this issue can:

  1. Avoid changing hostname after deployment
  2. Manually update DNS settings in all client configs after running update-users
  3. Redeploy the server with the new hostname

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions