this post was submitted on 15 Jan 2024
20 points (91.7% liked)

Selfhosted

40347 readers
328 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago
MODERATORS
 

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?

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.

top 4 comments
sorted by: hot top controversial new old
[–] deadbeef@lemmy.nz 4 points 10 months ago (1 children)

Your bridge isn't bridging properly. If Router B is sending a destination unreachable then the packets are being handled on it further up the stack at layer 3 by some sort of routing component rather than by a layer 2 bridging one.

[–] Kalcifer@sh.itjust.works 2 points 10 months ago* (last edited 10 months ago) (1 children)

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

[–] vegetaaaaaaa@lemmy.world 3 points 10 months ago* (last edited 10 months ago) (1 children)

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?)

[–] Kalcifer@sh.itjust.works 2 points 10 months ago

I'm not exactly sure what the previous issue was, but it appears that, possibly, the previous bridge that was in use was broken in some way. I have since switched the primary router to one that supports WDS, and created a WDS bridge between the two, and now everything is working as expected.