StrongSwan pushes a DNS address the Mac cannot reach

Everything works until somebody opens a MacBook. The tunnel establishes, internal hosts answer by address, and name resolution dies. On the iPhone the same profile behaves the same way, while the Windows and Linux clients are fine. The pushed DNS attribute is usually the culprit: the server hands out its own public interface address, and Apple's IKEv2 client does not send queries there through the tunnel. Move the resolver inside the pool and the symptom disappears without touching the client.

The symptom points at the pushed address

When only some platforms fail, the tunnel and the credentials are almost certainly fine, because those are shared. What differs is how each client applies the configuration payload it receives, including the internal DNS server. A client that accepts the address but routes queries around the tunnel ends up with a resolver it can see and cannot use.

The public address is the usual choice because it is the one the administrator already knows. It is also the one address guaranteed to be outside the tunnel's own prefix, which is exactly the property that breaks the Apple clients.

Look at the value before changing anything. If the pushed resolver is the server's WAN address, you have found the shape of the problem and can skip the rest of the guessing. Compare it with the pool prefix as well, since an address that sits inside the pool but outside the leased range is exactly what the fix will look like. Two minutes with the configuration beats an afternoon of packet captures on the client.

Carve the resolver out of the lease range

Give the tunnel an address plan where the resolver is a member of the pool's own subnet, then reserve that address so no client is ever leased it. In this example the pool is 10.180.7.0/24, the server holds 10.180.7.1, and leases start at 10.180.7.2.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

The pool prefix and the resolver share a subnet, so the route that already carries tunnel traffic also carries the queries. That single property is what makes the fix portable across clients. In a swanctl configuration the same two facts appear as a pool definition and a DNS setting on the connection rather than in ipsec.conf syntax.

The server does not need a new physical interface for this. Adding 10.180.7.1 to the loopback interface is enough for a resolver to bind and answer, since clients reach it through the pool route that exists already. Keep the address out of the lease range so no client can claim it by accident. If the pool is managed by an external DHCP or RADIUS service, reserve the address there as well, or the first client to ask will take it.

Bind the resolver and close port 53

Assigning an address is not the same as listening on it. A resolver that only listens on the LAN address will refuse or ignore queries sent to the pool address, and the client sees a timeout that looks like a routing failure.

interface: 10.180.7.1
access-control: 10.180.7.0/24 allow
access-control: 0.0.0.0/0 refuse

That unbound fragment accepts queries from the tunnel pool and refuses everything else, which is the policy most corporate resolvers want. If the same instance also answers LAN clients, add the LAN prefix explicitly instead of widening the listener to all sources.

Firewall rules then have to agree with the resolver's own access control. Accept port 53 from the pool, and drop it from everywhere else, but check the order of the chain first.

iptables -A INPUT -p udp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j DROP
iptables -A INPUT -p tcp --dport 53 -j DROP

An earlier, broader accept rule makes those last two lines decorative, and the resolver stays reachable from the internet. Read the effective rule set with the counters rather than trusting the order you intended. The alternative policy, pushing the public address and allowing queries from any source, does work for many clients, but it puts the resolver on the internet and needs its own rate limiting and monitoring.

Verify what the client actually received

Check the server's view first, then the client's, because the two disagree in informative ways. A pool listing shows which address was leased, and the security association listing shows whether the connection is up with the expected identity.

swanctl --list-sas
swanctl --list-pools
dig +short @10.180.7.1 intranet.plant.example

The direct query proves the resolver answers on the pool address from a host that can reach it. It does not prove the Mac chose that server. On macOS, scutil --dns lists resolvers per scoped service and is more informative than the summary panel; on Windows, Get-DnsClientServerAddress shows whether the tunnel adapter accepted the pushed value.

If the client shows the pool address and queries still time out, the tunnel route or the firewall chain is at fault. A client that reports no resolver means the configuration payload never landed, so look at how that platform applies pushed settings rather than at the network. Write down which of those two you observed before changing anything else. Those two failures look identical in a support ticket and lead to opposite repairs.