Why the DNS Reply Fails at a Stateless VPN Edge Firewall

The tunnel is up, clients can reach the VPN host, and the host cannot resolve anything. Its own outbound queries leave the interface cleanly, so the failure is on the way back: at an upstream edge that filters incoming traffic with no memory of what the host just sent. Allowing the tunnel port does not describe that exchange at all. The reply to a DNS query is a separate flow, and if the edge is stateless, nothing has authorized it to return.

The two exchanges are not the same exchange

Write the tuples down and the mistake becomes obvious. The request's destination port becomes the reply's source port, which is the opposite of what most people picture when they add an inbound rule for port 53:

query:  203.0.113.10:53018 -> 198.51.100.53:53
reply:  198.51.100.53:53 -> 203.0.113.10:53018

An incoming rule that requires destination port 53 describes traffic addressed to a DNS listener running on the host, which is a different service entirely. Those addresses are documentation examples, and the source port is chosen by the client per query, so it is not a value you can copy into a rule and expect to keep working.

Stateless edge versus stateful host firewall

A stateless edge filter evaluates each incoming packet against its rule list with no connection table behind it. An outgoing query that left successfully creates no permission for its incoming reply, because the device has no record that a query ever happened. A stateful host firewall is the opposite: its connection tracking recognizes the return traffic of an allowed exchange and passes it without a rule for the reply. Both boundaries exist in a typical path, and both have to permit the intended packet.

The comparison matters because the two devices fail differently. A stateful firewall that denies the reply logs a drop; a stateless edge denies it silently, which is why the host simply times out.

Build the allowance around the protocol, not a port number

Scope the rule to the actual resolver addresses, the destination host, and the receiving-port policy the product supports. Keep DNS's TCP path in mind as well, since a large answer or a truncation fallback moves the exchange to TCP and a UDP-only rule will not cover it. If the edge supports stateful inspection for a defined flow, prefer that over a hand-written reply rule, because the stateful path follows the client's chosen ports automatically.

Then confirm which product on the path actually filters the traffic. A documented IPv4 edge scope does not establish an IPv6 policy, and provider-internal traffic may never traverse the same filter at all.

Why allowing any source port 53 is not a fix

A rule that accepts anything claiming source port 53 is a rule that accepts whatever a sender writes in a header field. The port number does not authenticate the sender and does not prove the payload is a valid answer, so the rule widens the host's exposure without making resolution more reliable. Keep source restrictions and keep the client's own response checks, including source-port randomization, rather than disabling them to simplify an access list.

If the resolver is a service you control, restricting to its addresses is enough. If it is a public resolver, restrict to the addresses you approved and note them in the rule comment.

Verify at the right boundary, in the right direction

Capture at the host and at the edge for the same query, and compare the tuples rather than the packet counts. A query visible on both sides with no reply visible on the host side points at the inbound filter; a query visible only on the host side points at routing or the resolver itself. Repeat with a TCP query if you have a UDP-only allowance, because that is the gap the first test cannot see.

Fixing this completes a DNS exchange the host genuinely needs. It does not turn the host into a public resolver, authorize forwarded VPN flows, or prove that DNS was the cause of some unrelated tunnel problem.