This one is from my lab record. Package updates in the Twingate connector container (LXC 208) failed: first on an unreachable IPv6 address, then because the Ubuntu archive did not resolve at all. Every address, profile identifier and hostname below is redacted, and each command output is a sample laid out to match what I recorded.
How DNS is supposed to flow
Containers on the LAN bridge use Sophos as their resolver. Sophos forwards to the NextDNS container (LXC 209), which sends queries to a NextDNS profile over DNS-over-HTTPS. The forwarder itself uses a separate plain resolver to bootstrap, so Sophos and the forwarder can never loop into each other.
- WAN
- Laptop uplink
WAN bridge- Sophos Firewall
- LAN bridge
Every query from a LAN container leaves through the LAN bridge to Sophos, and Sophos’s forwarded query comes back onto the same bridge to reach LXC 209. Traffic between two hosts on the same bridge does not cross Sophos, which matters for where you capture.
Open the full lab consoleWhat I checked, in order
Purpose: ask the default resolver
I started where the failure was, with the resolver the container actually uses, before touching anything upstream.
dig +short archive.ubuntu.com; dig archive.ubuntu.com | grep statusShow output
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAINNXDOMAINthe resolver says the name does not exist, which is false for a public archive
The outcome, NXDOMAIN through Sophos, is from my lab record. The output line is a redacted sample.
Purpose: ask the forwarder and a public resolver directly
If the forwarder answered and Sophos did not, the problem was between them, not upstream.
dig +short archive.ubuntu.com @<nextdns-forwarder>; dig +short archive.ubuntu.com @<public-resolver>Show output
<ubuntu-archive-address-1>
<ubuntu-archive-address-2>
<ubuntu-archive-address-1>
<ubuntu-archive-address-2><ubuntu-archive-address-1>both answer with real A records, so the profile and the internet are fine
Placeholders replace the addresses. Both direct answers being valid is from my record.
Purpose: see whether Sophos forwarded the query
I wanted to know whether the bad answer came from upstream or whether Sophos never asked.
tcpdump -ni vmbr1 'udp port 53 and host <nextdns-forwarder>' -c 200 | grep -i ubuntuShow output
(no matching lines while ordinary queries were captured)no matching linesSophos was forwarding other queries but not this one, so it likely answered by itself
From my record: the capture showed normal queries and responses, but no Ubuntu query. That points at Sophos without proving which layer answered.
The likely cause was one of the third-party threat feeds on Sophos matching the domain. I disabled one blocklist, and the archive resolved again. I did not record which list, so that is still an open item in the ticket, not a solved one.
Decision tree · a name will not resolve on the LAN
- 1
Does the default resolver answer?
dig +short <name>
Yes Not DNS: test the TCP path with curl or Test-NetConnection
- 2
Does the forwarder answer when asked directly?
dig +short <name> @<forwarder>
- 3
Did the gateway forward the query?
tcpdump -ni vmbr1 udp port 53 and host <forwarder>
Yes Compare answers and TTLs; flush caches and retest
- 4
Does a gateway DNS rule or threat feed match the name?
Sophos log viewer filtered by the domain
Yes Disable or allowlist only that list; record which one; retest
No Escalate with the captures attached
- 5
Does the DNS profile block the name?
NextDNS log for the client (kept private)
Yes Allowlist the domain in the profile; retest
No Upstream issue: check the forwarder's DoH status and escalate
The order matters: each check removes one layer, and the capture is what separates “upstream said no” from “the gateway never asked”.
The VLAN boundary I tested the same week
The VLAN trunk carries seven VLANs, and DROP_LAB20_OUTBOUND sits near the top of the rule order for VLAN 20 (LAB_TEST). On 6 November I tested it from the SafeLine container on VLAN 20:
- DHCP leasepassLease received from Sophos
- Ping the VLAN 20 gatewayfailNo reply
- Ping a public addressfailNo reply
- Ping an internal addressfailNo reply
- TCP to Proxmox managementfailConnection did not open
- Sophos logdropDrops recorded on UDP/53 and TCP/853 under DROP_LAB20_OUTBOUND
- IPv6noteA link-local address was present on the interface
What this establishes: VLAN 20 gets an address, and DROP_LAB20_OUTBOUND matched its DNS and DNS-over-TLS attempts. It covers these checks over IPv4. With a link-local IPv6 address present, it does not prove the VLAN is isolated in every direction or that IPv6 is off.
Each result answers a narrower question than “is VLAN 20 isolated?”. The lease shows DHCP works on that VLAN. The failed pings and the failed TCP check to Proxmox management show those specific flows did not get through. The firewall log is the strongest piece: it names the rule that dropped DNS on UDP/53 and DNS-over-TLS on TCP/853, so I know which rule acted, not just that something did. The interface also had an IPv6 link-local address, so I describe this as an IPv4 design and do not claim IPv6 is off or that the VLAN is closed in every direction.
Similar symptom, different layer
Two other DNS problems in my record looked the same from a browser and had nothing to do with Sophos:
- A Windows NRPT rule. With Twingate connected, public names stopped resolving even though Twingate’s own resolver answered. An effective root rule in the Name Resolution Policy Table was sending every query to resolvers left over from a VPN client. Removing that one rule fixed resolution.
- A route from NetBird. NetBird on Windows installed a host route for the firewall on its tunnel interface, which made the Sophos web UI unreachable from inside the LAN until NetBird was taken down.
Purpose: list name resolution policy rules
When names failed only with a VPN client connected, I checked whether a policy rule was overriding the normal resolver.
Get-DnsClientNrptPolicy | Select-Object Namespace, NameServersShow output
Namespace NameServers
--------- -----------
. {<leftover-resolver-1>, <leftover-resolver-2>}.a root rule matches every name, so it silently replaces the resolver for all queries
Read-only. A root namespace rule is the line to look for. The removal itself was a change, so it belongs in the ticket with a rollback note.
What goes in the ticket
Summary: Package updates failing in LXC 208; the gateway returns NXDOMAIN for the Ubuntu archive.
Impact: One container cannot patch. Other names resolve. No user-facing service affected.
Scope: Names checked through Sophos, the NextDNS forwarder and a public resolver. Only the gateway answer is wrong.
Evidence: Three dig results, one capture between Sophos and the forwarder showing no Ubuntu query.
Change: One Sophos threat-feed list disabled. Rollback: re-enable it.
Open: Identify which list matched, and whether to allowlist the domain instead of disabling the list.
Escalate if: Resolution fails again with all lists enabled, or other domains start returning NXDOMAIN.
The ticket is short on purpose. Someone picking it up should see what was tested, what changed, how to undo it, and what is still unknown, without rereading this article.
What I learned
The resolver that answers is not always the one you think. In all three cases the symptom was the same, a name that would not resolve, and each time a different layer was answering: the firewall’s threat feed, a Windows policy table, a VPN route. Asking each resolver directly, one at a time, is what separates them.
Takeaway: when a name fails, query the gateway, the forwarder and a public resolver separately before changing anything. The one that disagrees is the layer to fix.
Further reading: Proxmox VE network configuration · NextDNS CLI · Get-DnsClientNrptPolicy
Skills used
- Hop-by-hop troubleshooting
- Packet capture with tcpdump
- Writing the ticket a NOC would expect
Tools in this entry
- Proxmox VE In my lab
Official documentation for Proxmox VE - Sophos Firewall In my lab
Official documentation for Sophos Firewall 
NextDNS In my lab
Official documentation for NextDNS- tcpdump In my lab
Official documentation for tcpdump - PowerShell I use it
Official documentation for PowerShell