IKEv2 is a modern, resilient VPN protocol that pairs exceptionally well with enterprise deployments due to its support for MOBIKE, fast reconnection, and robust authentication methods. One critical but sometimes overlooked piece of a reliable IKEv2 deployment is DNS configuration. Proper DNS handling prevents leaks, enables split‑DNS for internal resources, and ensures clients resolve names using authoritative or privacy‑preserving resolvers. This guide walks you through practical, technical steps to configure DNS for IKEv2 on both server and client sides — with examples for common Linux IPsec stacks (strongSwan/libreswan), Windows, macOS/iOS and Android — and includes troubleshooting tips and security considerations.

Why DNS matters in IKEv2 setups

When a client connects over IKEv2 it typically establishes an encrypted tunnel for IP traffic, but DNS behavior is governed by how the OS and VPN stack are instructed to use name servers. Common pitfalls include:

  • DNS leaks: queries bypass the tunnel and go to ISP DNS servers, exposing browsing metadata.
  • Broken name resolution for internal services when split‑DNS is not configured.
  • Unintended resolver precedence or caching issues (systemd‑resolved, NetworkManager, etc.).

To avoid these issues you must both advertise the correct DNS servers from the server and configure the client OS to honor those settings and prefer the secure tunnel for DNS traffic.

Server-side: advertising DNS with strongSwan and libreswan

Most Linux IPsec implementations support pushing DNS information to the client. The two common directives are rightdns (strongSwan) or dhcp-option for IKEv2 profile-based pushes. Below are example configurations and server components to consider.

strongSwan (charon) example

In strongSwan you typically configure connection profiles in /etc/ipsec.conf or /etc/swanctl/swanctl.conf (swanctl). For ipsec.conf using left/right semantics:

/etc/ipsec.conf snippet:

conn ikev2-vpn
left=%any
leftcert=serverCert.pem
leftid=@vpn.example.com
leftsubnet=0.0.0.0/0
right=%any
rightid=%any
rightsourceip=10.10.10.0/24
rightdns=10.10.10.1,8.8.8.8
ike=aes256-sha256-modp2048!
esp=aes256-sha256!
keyexchange=ikev2
auto=add

strongSwan will push rightdns to clients supporting DNS attribute (IP configuration via IKEv2 Configuration Payload — RFC 4555). If you use swanctl (recommended for modern installs), declare right_dns under the local or remote block depending on config style.

libreswan / xl2tpd considerations

libreswan supports similar pushes; configure rightdns in ipsec.conf. For legacy setups using xl2tpd for PPP payloads, you may need to set DNS servers using the pppd options (ms-dns).

DNS backend options

Your advertised DNS server can be:

  • An internal authoritative/forwarding resolver (Unbound, BIND9) listening on the tunnel interface or virtual IP.
  • A recursive resolver with DNS over TLS (DoT) or DNS over HTTPS (DoH) on the server to protect privacy downstream.

Example Unbound forwarding config snippet (/etc/unbound/unbound.conf):

server:
interface: 10.10.10.1
access-control: 10.10.10.0/24 allow
forward-zone:
name: “.”
forward-tls-upstream: yes
forward-addr: 1.1.1.1@853 # Cloudflare DoT
forward-addr: 9.9.9.9@853

Client-side configuration: OS-specific details

Client OSes differ in how they accept DNS information from IKEv2. Many modern systems will accept DNS pushed in the IKEv2 Configuration Payload, but you must also check local resolver services (systemd‑resolved, NetworkManager) that may override or ignore the push.

Windows (10/11 and Server)

Windows VPN client built into the OS supports receiving DNS from IKEv2. To ensure the DNS is used:

  • Use PowerShell to examine the connection: Get-VpnConnection -AllUserConnection.
  • Set DNS servers manually for the VPN profile if needed: Set-VpnConnection -Name "VPN" -DnsSuffix "corp.local" -SplitTunneling $True and Set-DnsClientServerAddress -InterfaceAlias "VPN" -ServerAddresses ("10.10.10.1","8.8.8.8").
  • For Windows RRAS or IAS pushed attributes, use RADIUS attributes (e.g., MS-CHAPv2 + vendor-specific attributes) to push DNS.

Verify with ipconfig /all and nslookup. To avoid leaks, set the VPN network adapter’s DNS priority higher than physical adapters — Windows does automatic metric adjustments, but explicit metrics can be set via Set-NetIPInterface.

macOS and iOS

Apple devices accept IKEv2 DNS push in most cases. For managed environments or to enforce split‑DNS, use configuration profiles (XML .mobileconfig) with the com.apple.vpn.managed payload and DNS keys for per‑VPN settings. Example keys to include:

  • On macOS, verify DNS using: scutil --dns and networksetup -getdnsservers "VPN Name".
  • For profiles, add DNS and SearchDomains arrays inside the VPN payload.

Split DNS is supported via the OnDemand and per-domain settings in the profile.

Android (strongSwan app and platform IKEv2)

The strongSwan VPN client app supports IKEv2 and will use DNS servers pushed by the server. For Android 8+ with built‑in IKEv2 support, the OS will usually accept the pushed DNS. If using a VPN profile, check the app’s advanced settings to ensure Use remote DNS is enabled.

Verify DNS via getprop net.dns1 and getprop net.dns2, or use a terminal with nslookup or network capture tools.

Split DNS and routing internal names

Split DNS means resolving internal hostnames via internal resolvers while public names use public resolvers. Approaches:

  • Advertise internal DNS servers via IKEv2 and set search domains on clients. This is easiest for managed clients.
  • On Linux clients, use per‑domain routing in systemd‑resolved with domains and DNS= in .network files for the VPN interface.
  • On macOS/iOS use configuration profiles specifying which domains go via the VPN DNS.

On the server side, ensure the resolver listens on the VPN interface and has access to internal zones, or configure Unbound to forward specific domains to internal authoritative masters.

Firewall, NAT‑T and port considerations

For reliable IKEv2 operation and DNS reachability:

  • Allow UDP/500 and UDP/4500 for NAT traversal and ESP (protocol 50) if not using UDP encapsulation.
  • Ensure your DNS server’s port 53 (UDP/TCP) is accessible from the VPN subnet and blocked from the Internet unless intended.
  • When using NAT, ensure iptables/nftables rules do not accidentally DNAT or SNAT DNS traffic out of the tunnel.

Troubleshooting checklist

If clients report DNS leaks, no DNS, or wrong resolver:

  • Check connection payloads: capture with tcpdump on the server to see IKEv2 configuration payloads and whether DNS attributes are sent: tcpdump -i eth0 -n udp port 500 or udp port 4500 -w ikev2.pcap, then inspect in Wireshark.
  • On client, confirm DNS servers: ipconfig /all (Windows), scutil --dns (macOS), getprop net.dns1 (Android), resolvectl status (systemd‑resolved Linux).
  • Test resolution using forced queries: dig @10.10.10.1 internal.host.domain to validate internal DNS server responds.
  • Check resolver logs (Unbound/BIND) for access denied or query source issues.
  • Verify firewall and SELinux/AppArmor aren’t blocking the resolver bound to the VPN interface.

Security and privacy best practices

Make DNS both secure and private:

  • Use DNS over TLS/HTTPS on the server’s upstream resolvers to protect queries from the VPN egress point.
  • Don’t expose your internal resolver to the public Internet; restrict access to the VPN subnet.
  • Monitor for DNS leaks using online leak testers and internal logging.
  • Consider client-side DNS encryption in addition to server-side protection if clients run hostile networks (mobile hotspots).

Example commands summary

  • Reload strongSwan: ipsec reload or swanctl --load-all
  • Check IKE status: ipsec statusall or swanctl --list-sas
  • Unbound test query: unbound-control lookup example.com 10.10.10.1
  • Capture packets: tcpdump -i any port 53 or port 500 or port 4500 -w /tmp/vpn-dns.pcap

Correctly configured DNS is essential for a secure and functional IKEv2 deployment. By advertising resolvers from the server, ensuring client OSes accept and prioritize those resolvers, implementing split‑DNS where necessary, and protecting upstream queries with DoT/DoH, you can avoid leaks and deliver reliable name resolution for internal and external services.

For detailed deployment examples, scripts, and configuration templates tailored to common distros and client types, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/. (Dedicated-IP-VPN)