On Thu, May 29, 2025 at 5:48 AM Florian Westphal <fw@xxxxxxxxx> wrote: > > 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? No, it is not using the public address. The DNS server address 169.254.1.2 is a link-local address, not a routable public IP. > > 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. This is how we’re handling it in production right now. Without this workaround, the issue would occur intermittently. > > Assuming the dns proxy already uses the public address, no dnat reversal > is needed. -- Regards Yafang
