Yafang Shao <laoar.shao@xxxxxxxxx> wrote: > On Wed, May 28, 2025 at 9:20 PM Florian Westphal <fw@xxxxxxxxx> wrote: > > ... and that makes no sense to me. > > The reply should be coming from 127.0.0.1:53. > > > > I suspect stack refuses to send a packet from 127.0.0.1 to foreign/nonlocal address? > > > > As far as conntrack is concerned, the origin 169.254.1.2:53 is a new flow. > > > > We do expect this: > > 127.0.0.1:53 -> 10.242.249.78:46858, which would be classified as matching response to the > > existing entry. > > Could this issue be caused by misconfigured SNAT/DNAT rules? However, > I haven't been able to identify any problematic rules in my > investigation. No, because even if there was an SNAT rule it would not be used for a reply packet. Can you check the dns proxy and confirm that it is using the "wrong", i.e. the public address as source for the udp packets? Alternatively you could also try adding a NOTRACK rule in -t raw OUTPUT, for udp packets coming from sport 53. It should prevent this problem and make your setup work. Assuming the dns proxy already uses the public address, no dnat reversal is needed.