On Wed, May 28, 2025 at 9:20 PM Florian Westphal <fw@xxxxxxxxx> wrote: > > Yafang Shao <laoar.shao@xxxxxxxxx> wrote: > > After applying commit d8f84a9bc7c4, only one entry remains: > > $ cat /proc/net/nf_conntrack| grep 10.242.249.78 > > ipv4 2 udp 17 106 src=10.242.249.78 dst=169.254.1.2 > > sport=34616 dport=53 src=127.0.0.1 dst=10.242.249.78 sport=53 > > dport=34616 [ASSURED] mark=0 zone=0 use=2 > > Makes sense to me, thats what would be expected, at least from ct state, no? > (I inderstand that things are not working as expected from DNS pov). > > > After the additional custom hack, the entries now show two records: > > $ cat /proc/net/nf_conntrack| grep 10.242.249.78 > > ipv4 2 udp 17 27 src=169.254.1.2 dst=10.242.249.78 sport=53 > > dport=46858 [UNREPLIED] src=10.242.249.78 dst=169.254.1.2 sport=46858 > > dport=53 mark=0 zone=0 use=2 > > ipv4 2 udp 17 27 src=10.242.249.78 dst=169.254.1.2 > > sport=46858 dport=53 src=127.0.0.1 dst=10.242.249.78 sport=53 > > dport=46858 mark=0 zone=0 use=2 > > That makes no sense to me whatsoever. > > The second entry looks correct/as expected: > 10.242.249.78 -> 169.254.1.2 46858 -> 53 DNATed to 127.0.0.1:53 10.242.249.78:46858 > > ... so we would expect replies coming from 127.0.0.1:53. > > But the other entry makes no sense to me. > > src=169.254.1.2 dst=10.242.249.78 sport=53 dport=46858 [UNREPLIED] src=10.242.249.78 dst=169.254.1.2 sport=46858 dport=53 mark=0 zone=0 use=2 > > This means conntrack saw a packet, not matching any existing entry for this: > 169.254.1.2:53 -> 10.242.249.78:46858 > > ... 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. > > Do you have any load balancing, bridging etc. going on that would result in cloned > packets leaving the system, where one is going out unmodified? No, we don't have cloned packets. > > Is route_localnet sysctl enabled? I have never tried such lo stunts myself. The config is as follows, net.ipv4.conf.all.route_localnet = 1 net.ipv4.conf.bond0.route_localnet = 0 net.ipv4.conf.bridge0.route_localnet = 0 net.ipv4.conf.default.route_localnet = 0 net.ipv4.conf.docker0.route_localnet = 0 net.ipv4.conf.eth0.route_localnet = 0 net.ipv4.conf.eth1.route_localnet = 0 net.ipv4.conf.lo.route_localnet = 0 -- Regards Yafang
