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

[Peter 'PMc' Much]

On Mon, Feb 24, 2025 at 10:01:49PM +0100, Peter 'PMc' Much wrote:

! Packets do arrive, but are ignored.
! The local firewall is switched to pass-thru.
! 
! I don't know what else could selectively swallow packets without
! notice.

Okay, I figured it out.

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.

Basically I have a little bit different understanding of zero-trust,
and I am doing it a little bit longer already than since it became
a buzzword - but it basically boils down on the respective node doing
it's own decisions about which network is how safe. Therefore the node
needs to have access to the respective networks - and the cheap
variant is to simply build tunnels, like so:

tun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
        options=80000<LINKSTATE>
        inet 10.1.0.126 --> 10.1.0.120 netmask 0xffffffff
        groups: tun
        nd6 options=9<PERFORMNUD,IFDISABLED>
        Opened by PID 11541
tun3: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
        options=80000<LINKSTATE>
        inet 10.1.0.136 --> 10.1.0.130 netmask 0xffffffff
        inet6 fe80::1%tun3 prefixlen 124 scopeid 0x4
        groups: tun
        nd6 options=1<PERFORMNUD>
        Opened by PID 54021
tun5: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
        options=80000<LINKSTATE>
        inet 10.1.0.146 --> 10.1.0.140 netmask 0xffffffff
        inet6 fe80::1%tun5 prefixlen 124 scopeid 0x5
        groups: tun
        nd6 options=1<PERFORMNUD>
        Opened by PID 11487
tun6: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
        options=80000<LINKSTATE>
        inet 10.1.0.166 --> 10.1.0.160 netmask 0xffffffff
        inet6 fe80::1%tun6 prefixlen 124 scopeid 0x6
        groups: tun
        nd6 options=1<PERFORMNUD>
        Opened by PID 11514

(Yes, these tunnels run with mtu 1500 - but that's again a different
story ;) )

The ugly thing with such tunnels is, when one connects thru them,
the local node will choose the nearside tunnel pier as the source
ip address, so it will appear as all kinds of 10.1.0.1X6 instead it's
genuine IP. And that is a real nuisance if you need to recognize the
traffic later, and it must be fixed individually per application (if
possible at all).
So I thought, lets solve that once and for all - we have libraries
for NAT, and these libraries do exactly fix such situations, by
replacing unwanted local IPs with a single well-known IP.

Works fine - only two days ago that NAT library has apparently
decided to start mangling the packet checksums, for whatever reason.

cheerio,
PMc