There’s two main ways of doing geo-based load balancing:
- IP Any-casting - In this case, an IP address is “homed” in multiple spots and through the magic of IP routing, it arrives at the nearest location. This is exactly how 1.1.1.1 and 8.8.8.8 work. It works fine for stateless packets like DNS, however it has some risks for stateful traffic like HTTP.
- DNS based load balancing. A server receives a request for “google.com”, looks at the IP of the DNS server and/or the EDNS Client IP in the DNS query packet and returns an IP that’s near. The problem is that when you’re doing Wireguard, it goes phone -> pi-hole (source IP is some internal IP) -> the next hop (e.g. 1.1.1.1 or 8.8.8.8), which sees the packet is coming from your home/pi-hole’s public IP. Thus it gets confused and thinks you’re in a different location than you really are. Neither of these hops really knows your true location of your phone/mobile device.
Of course, this doesn’t matter for companies that only have one data center.
If you are port forwarding. I recommend not exposing it on the default port of 25565 and instead expose it as a random port. Then, assuming you have a domain name, create an SRV record that points to your IP and port. This will cut down on the drive by scanners who scan by ports, but won’t totally eliminate it. If you do use the SRV record, your friends won’t even notice there’s a different port.