Hi, While using dnsmasq as embedded in the pi-hole project I came across an issue with how TCP DNS requests are handled over Wireguard interfaces.
A ticket was raised in the FTL project (https://github.com/pi-hole/FTL/issues/824) and the conclusion was that the issue is in dnsmasq. It seems the logic of determining the incoming interface fails and the connection is closed and reset before FTL can handle it, which seems to put the issue in the dnsmasq codebase. A key detail is that the Wireguard interface is configured with the same IP as the default interface, but with a more specific subnet mask. For example where eth0 has the default route it may be configured with 10.3.2.1/24, while the Wireguard interface would have the address 10.3.2.1/32. Having a different IP on the two interfaces does not cause any issues. See the above linked FTL ticket for how we came to the conclusion, along with PCAPs and custom logging output that was put in place to determine what is going wrong. How can I help get this resolved? Thanks, Jinn _______________________________________________ Dnsmasq-discuss mailing list [email protected] http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
