I still cannot see how the suggested measures solve the root problem. I, too, think of FritzBox or Speedport or EasyBox when I think of a home LAN. These DSL routers are also often used in small offices. So for this part, small offices and private home networks use the same technology. Larger companies surely have more money to spend. The mentioned router models probably make up half of all internet users in Germany. Other models (like TP-Link) don't include a DNS server for DHCP'd local hosts and are almost unusable for home LANs. If you use a router of that kind you have problems before thinking of VPN.
None of these networks offer a DNS suffix. And if they do (FritzBox), it's fixed to ".local". Everywhere. I tried to change it but it's not possible, confirmed by AVM support. Now you may want to call LANs managed by a FritzBox unprofessional. And to a certain point I can follow you. But unprofessional or not, it's the reality that a whole lot of people live in. Now and for the foreseeable future. I wouldn't want to spend extra work to set up a different custom-made router in all of my networks just so that the limited WireGuard capabilities solve my problems. Using OpenVPN is a lot easier then. This reality includes host names like "pc1" and "pc2" in one LAN and "pc3" and "pc4" in the other LAN. If I'm in one of these LANs and want to connect to the other, I need name resolution with both routers to be able to use names in the LAN I'm currently in and at the same time names in the LAN I'm connected to. No single existing DNS server could ever do that because the two routers don't know each other. I haven't mentioned public names yet. In this simple scenario, both routers could resolve internet names, but the local router is preferred because it's faster. As far as I understand things, I need this specific solution, and it's almost impossible to built that without tight integration with a WireGuard client: * A local DNS proxy on the tunnel client end * that registers itself as the new default DNS server for as long as a tunnel is active * and forwards all DNS queries to *all* of the connected tunnels' DNS (if specified) and also the previous system's DNS server * and responds with the first positive answer that comes in. * This proxy adapts to all active tunnels and * stops and unregisters when the last tunnel is closed. None of the suggested solutions provide these features. All of them assume that I have host names with a distinguishable name suffix (not the case, not changeable) and that I can reconfigure DNS proxy configuration upon activating and deactivating a tunnel (not practical). While I understand that WireGuard (the tunnel tech) is intended to be simple, I consider this feature necessary on a higher level for normal network operation. Make things as simple as possible, but no simpler! And in this case, it's just a client GUI that already provides several comfort features outside of the core tunnel scope. A DNS proxy would well fit in this. And yes, this causes more network traffic than necessary in an ideal world. But I'm looking for a solution in the existing world, and it's only DNS packets, no OS image downloads. Make it correct, and fast; in that order. -Yves
