<div dir="auto">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.</div><div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Feb 24, 2025 at 4:19 PM Timothe Litt via bind-users <<a href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><u></u>

  
    
  
  <div>
    <pre cols="72" style="font-family:monospace"></pre>
    <div>On 24-Feb-25 17:54, Peter 'PMc' Much
      wrote:<br>
    </div>
    <blockquote type="cite">
      <pre style="font-family:monospace">tcpdump was friendly enough to tell me I should use -vv option,
only I didn't read that at first.
Then it clearly shows that these packets have invalid checksums. :(

And that is apparently reason enough to just drop them without
notice.

Now how they aquire broken checksums, and why they start to
do so two days ago (because I find some successful XFR in the log,
until Feb-22), that is another story.</pre>
    </blockquote>
    <p>A couple of hints:<br>
    </p>
    <p>The bad checksums may be a false lead.  If you have a network
      interface that off-loads checksum computation, the checksum (valid
      or invalid) may not appear in the user/trace buffer.  (Depends on
      the interface & driver.)  <br>
    </p>
    <p>If your NAT is changing IP addresses, it may not recompute the
      checksum (for the same reason - you can't count on it being valid
      in the buffer).<br>
    </p>
    <p>You can mark packets with IPtables to make tracking/logging
      easier.<br>
    </p>
    <p><br>
    </p>
    <pre cols="72" style="font-family:monospace">Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed. 
</pre>
    <p></p>
    <p><span style="white-space:pre-wrap">
</span></p>
    <div id="m_2411242753412648490grammalecte_menu_main_button_shadow_host" style="width:0px;height:0px"></div>
  </div>

-- <br>
Visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>
<br>
ISC funds the development of this software with paid support subscriptions. Contact us at <a href="https://www.isc.org/contact/" rel="noreferrer" target="_blank">https://www.isc.org/contact/</a> for more information.<br>
<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</blockquote></div></div>