On Tuesday, February 25, 2025 2:20:45 AM CET Crist Clark wrote: > Another thing to consider, especially if you are playing wild games routing > through tunnels and such, is to verify the server has a route back to the > client. If something in the LAN can reach it, like the first dump, but > off-net gets no response, like the second, that’s a classic cause.
Reminds me of an issue I once had with WireGuard. It would route such that the remote (what I like to call my "satellite network") had one route inbound to the main network, while the main network had another route outbound. So packets would go one way but could not be replied to from the other. Another issue that I still have with XFR to this day, is that when routing over WireGuard, the XFR appears to come from that network's gateway. So e.g. an XFR from ns1.lan to ns1.sat would instead appear to come from gateway.sat. Eventually I just caved in and allowed the gateways to perform the XFR, while noting the (pretty serious) security implications of that. Cryptographically signing the transfers and requiring that may be better in the long run. Not sure if either of those things are relevant here, but it's about as much head-scratching as I can partake in right now. Pretty much just shooting in the dark I suppose. -- Met vriendelijke groet, Michael De Roover Mail: i...@nixmagic.com Web: michael.de.roover.eu.org -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
