xfer-in: Transfer status: timed out (selective failures)

[Michael De Roover]

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: isc at nixmagic.com
Web: michael.de.roover.eu.org