Dropped DNS replies from non-intercepted nameservers due to conntrack zone mismatch

[mwennrich]

Description

Problem:

When a CWNP with a toFQDN-match exists, the firewall-controller fires up its internal DNS-proxy and intercepts DNS-requests to a given set of pre-defined configured nameservers (e.g. 8.8.8.8) and forwards them to itself.

ip daddr @proxy_dns_servers iifname "vlan63" tcp dport 53 dnat ip to 212.34.83.15 comment "dnat to dns proxy"
ip daddr @proxy_dns_servers iifname "vlan63" udp dport 53 dnat ip to 212.34.83.15 comment "dnat to dns proxy"

Currently this breaks DNS requests to any other external DNS server.

Reason:

To ensure the return traffic is reverse-NATed correctly, the firewall-controller utilizes a specific connection tracking zone 3.
In the output table all DNS requests from the firewall(-controller) itself are placed into ct zone 3:

chain output_ct {
        type filter hook output priority raw; policy accept;
        oifname "vlan63" tcp sport 53 ct zone set 3
        oifname "vlan63" udp sport 53 ct zone set 3
}

As well as in the nat table:

chain prerouting_ct {
    type filter hook prerouting priority raw; policy accept;
    iifname "vlan63" tcp dport 53 ct zone set 3
    iifname "vlan63" udp dport 53 ct zone set 3
}

All normal forwarded connections (including DNS requests to external nameservers) are placed in the default ct zone 0.

The problem is that the prerouting_ct rule in the nat table is too broad and places all DNS requests into ct zone 3, even those that are not meant to be intercepted.

Because of this, regular (non-intercepted) DNS requests were tracked in zone 3 when leaving the network.

However, when the reply from the external server arrived at the external interface, there was no rule to place it into zone 3. netfilter evaluated the incoming reply in the default zone 0.

Since the connection state did not exist in zone 0, the firewall did not reverse the SNAT. It assumed the packet was destined for itself (on the dynamically assigned high-port) and subsequently dropped it in the INPUT chain because of an invalid state / missing socket.

Solution:

In the nat table, only place outgoing DNS requests into zone 3, that are to servers that are meant to be intercepted:

chain prerouting_ct {
    type filter hook prerouting priority raw; policy accept;
    ip daddr @proxy_dns_servers iifname "vlan63" tcp dport 53 ct zone set 3
    ip daddr @proxy_dns_servers iifname "vlan63" udp dport 53 ct zone set 3
}

All other outgoing connections (including non-intercepted dns requests) stay in zone 0. NAT of these other dns-requests works, even if the dns-proxy feature is active.