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

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?

EDIT (2024-01-25T08:37Z):

I’m not 100% sure what the previous problem was, but I think that it had to do with the bridge that I was using – not necessarily that it was broken, but perhaps it was jsut incompatible with the setup in some way. What I ended up doing was buying a different router that supported WDS, and then I created a WDS bridge between the two routers. The network seems to be working reliably, and as expected now.

  • Max-P@lemmy.max-p.me
    1·
    10 months ago

    I think you also need to enable full forwarding to and from wan on Router B. I forgot it defaults to not doing that. Set input, output and forward to ACCEPT on Router B on the wan zone, and make sure you also allow forwarding to and from the lan zone. Router A should be fine, I assume A’s WiFi and LAN is the same?

    Basically now, Router A sends the traffic to B but B doesn’t forward it to its LAN. But since we don’t have NAT, A’s devices addresses B’s devices directly, not B itself, and there isn’t any connection tracking happening, so it doesn’t “remember” to allow the ping response back in. If you WireShark this, I bet B is successfully sending packets to A and A’s devices, and A’s packets make it all the way to B but B doesn’t forward it to its own LAN, and it stops there.

    Can you post the output of ip ro and ip a on both routers? (Feel free to redact your public IP/ISP stuff if it shows up)

    • Kalcifer@sh.itjust.worksOP
      1·
      10 months ago

      If you WireShark this, I bet B is successfully sending packets to A and A’s devices, and A’s packets make it all the way to B but B doesn’t forward it to its own LAN, and it stops there.

      Yep that’s exactly what I see.

      Can you post the output of ip ro and ip a on both routers? (Feel free to redact your public IP/ISP stuff if it shows up)

      I would only be able to for one router. Router A is a tp-link AX73 which doesn’t support OpenWRT. Router B, however, is a tp-link Archer C7 and is flashed with OpenWRT.

    • Kalcifer@sh.itjust.worksOP
      1·
      10 months ago

      Hrm, I still have the same issue. Here’s the firewall settings:

      lan zone:

      • Input: accept
      • Output: accept
      • Forward: accept
      • Masquerading: false (unchecked)
      • MSS clamping: false (unchecked)
      • Covered Networks: lan
      • Allow forward to destination zones: wan, wan6, wwan
      • Allow forward from source zones: unspecified

      wan zone:

      • Input: accept
      • Output: accept
      • Forward: accept
      • Masquerading: false (unchecked)
      • MSS clamping: true (checked)
      • Covered Networks: wan, wan6, wwan
      • Allow forward to destination zones: unspecified
      • Allow forward from source zones: lan

      EDIT: I didn’t see your edit, as I hadn’t refreshed the page.

      • Max-P@lemmy.max-p.me
        1·
        10 months ago

        Interesting, lan zone doesn’t allow forward from wan but wan does allow both ways, maybe that’s the one missing. I expect OpenWRT to wire it up both ways automatically… OpenWRT is a mystery sometimes.

        Actually no, both show unspecified. You need both zones to allow both ways from the other zone.

        • Kalcifer@sh.itjust.worksOP
          1·
          10 months ago

          Alright, I now am able to ping a device on Router B from a device on Router A, but I’m still not able to ping a device on Router A from a device on Router B.

          Here’s the firewall settings for Router B:

          lan zone:

          • Input: accept
          • Output: accept
          • Forward: accept
          • Masquerading: false (unchecked)
          • MSS clamping: false (unchecked)
          • Covered Networks: lan
          • Allow forward to destination zones: wan, wan6, wwan
          • Allow forward from source zones: wan, wan6, wwan

          wan zone:

          • Input: accept
          • Output: accept
          • Forward: accept
          • Masquerading: false (unchecked)
          • MSS clamping: true (checked)
          • Covered Networks: wan, wan6, wwan
          • Allow forward to destination zones: lan
          • Allow forward from source zones: lan

          EDIT:

          Scratch that! apparently it is working. I could’ve sworn that I checked the ping. Maybe I subconciously applied something else.

        • Kalcifer@sh.itjust.worksOP
          1·
          10 months ago

          I’m now encountering another issue where I can’t ping any external IP’s. I don’t mean that DNS isn’t resolving (I set that on Router B to use Router A as the DNS resolver), but the I can’t ping, say, google.com, for example, from a device on Router B. I can see the ICMP requests in Wireshark, but they just say “no response”.

          • Max-P@lemmy.max-p.me
            1·
            10 months ago

            Erm, okay that’s not looking promising. It’s starting to look like Router A doesn’t like this setup at all. It’s not routing B’s traffic, possibly because it’s not the subnet it expects to serve. Ugh. Check all the options you can in Router A if you can find something that will allow it to work.

            You can fairly easily test that by enabling masquerading on B. It’ll break most of what we just set up but it’ll confirm that.

            We still have some options on the OpenWRT side to make it masquerade only public traffic but now I’m wondering if A will even let you port forward to something on B. I would try that now and see if it works.

            Is A able to ping B and devices on B, or only on A? A itself has a route for B’s subnet right?

            • Kalcifer@sh.itjust.worksOP
              1·
              10 months ago

              I really appreciate all the help that you provided in this thread! To simplify the setup, I bought a different primary router, flashed OpenWRT to it, then set up a WDS bridge between it and the other router. So far, I’ve had no issues, and the setup has been greatly simplified. I’m, of course, still curious as to why the previous setup wasn’t working, but at least everything is working now.