cross-posted to: https://sh.itjust.works/post/12856689

I have the following topology:

The device running Nextcloud (snap) used to be connected to Router A, but I have recently added a bridge (Router B) and I moved Nextcloud’s device to that bridged network; however, as soon as Nextcloud was moved to Router B, the portforward on Router A seemed to stop working – as in I cannot connect to nexcloud from the public IP anymore. Bridges operate at layer 2, so this should make no difference whatsoever (this is reflected in the fact that other services (like SSH) still work perfectly fine portforwarded – it’s only Nextcloud that doesn’t work), which leads me to think that it is a Layer 7 (i.e. Nextcloud) issue. What’s going on here? How can Nextcloud even tell that it’s been placed on a bridged network?

EDIT (2024-01-16T00:19Z):

I performed a network capture on the device running Nextcloud, and it appears that it’s receiving the incoming request (SYN), and responds appropriately (SYN, ACK), but then Router B responds with Destination unreachable (Network unreachable), which is then, of course, followed by many requests for retransmission as the packets are being dropped. But what’s causing the packets to be dropped? Why aren’t they making it through the network?

  • Kalcifer@sh.itjust.worksOPEnglish
    1·
    6 months ago

    Indeed it is not. Do you, by chance, have any suggestions – troubleshooting, alternatives, etc.?

    • vegetaaaaaaa@lemmy.worldEnglish
      2·
      6 months ago

      run ip route and ip route get $CLIENT_PUBLIC_IP on router B and see if it has a route to the client, and/or if the default route is correct. Its default gateway might not be set correctly (it should be router A)

      and responds appropriately (SYN, ACK),

      Does it respond to the client address (public IP?)