Unable to access syncthing from container (proxmox)

[Skyrider]

So I have no issues running syncthing from the main proxmox host, that works just fine. But I’m having issues with it from accessing it when its running in a container. The config is set to use 0.0.0.0, and I’m using this post-up script

post-up iptables -t nat -A PREROUTING -d proxmoxipaddress -p tcp --dport 8385 -j DNAT --to-destination containerip:8384

to forward 8385 host port to the port 8384 on the container. (even tried using 8385 as target/destination) but I keep getting ERR_CONNECTION_TIMED_OUT. Syncthing is running just fine on the container

Jul 22 14:14:21 nginx syncthing[694]: [BDM6Z] INFO: GUI and API listening on [::]:8384 Jul 22 14:14:21 nginx syncthing[694]: [BDM6Z] INFO: Access the GUI via the following URL: http://127.0.0.1:8384/

So I’m curious as to what’s going on and maybe someone has an idea why it’s not working? Was doubting if I should post this here or the proxmox forums. But maybe someone in here is running syncthing in a container as well.

All the other post-up scripts (eg, port xx to port 22 on the container) (for ssh) works just fine.

Help is appreciated!

Regards, Skyrider

[calmh (Jakob Borg)]

You probably need to change the GUI address to 0.0.0.0:8384 in the container.

[Skyrider]

Thing is I already tried using 8385 as both target and destination in iptables (seeing 8384 is used by the proxmox host). In this case:

post-up iptables -t nat -A PREROUTING -d proxmoxipaddress -p tcp --dport 8385 -j DNAT --to-destination containerip:8385

Which didn’t work either.

[calmh (Jakob Borg)]

Not in iptables, in Syncthing config.

[Skyrider]

I’m aware, but 8384 is already used by the proxmox host. So I tried using 0.0.0.0:8380 / 0.0.0.0:8385 (random ports close to the original) for the container. Seeing these ports aren’t used anywhere else on the system, this should work just fine.

[calmh (Jakob Borg)]

Ah, my bad, I read your log output too quickly. Then I have no idea, sorry.

[gadget]

@Skyrider

post-up iptables -t nat -A PREROUTING -d proxmoxipaddress -p tcp --dport 8385 -j DNAT --to-destination containerip:8384

Is there a reason why the container isn’t using the default network bridge in PVE and assigned an IP address from the LAN so that Syncthing can be accessed directly without port forwarding?

(I’m assuming the container is LXC, and if so, which Linux distro?)

@Skyrider

I’m aware, but 8384 is already used by the proxmox host. So I tried using 0.0.0.0:8380 / 0.0.0.0:8385 (random ports close to the original) for the container. Seeing these ports aren’t used anywhere else on the system, this should work just fine.

Did you disable PVE’s firewall option or update the list of allowed ports for the container?

[Skyrider]

@gadget

Is there a reason why the container isn’t using the default network bridge in PVE and assigned an IP address from the LAN so that Syncthing can be accessed directly without port forwarding?

(I’m assuming the container is LXC, and if so, which Linux distro?)

My system has a single IP address with vmbr0 as the main bridge and vmbr1 for the virtual bridge. vmbr1 is used by the containers and the IP address of vmbr1 is shared among all the containers. As far as I know, port forwarding is required with this method.

@gadget

Did you disable PVE’s firewall option or update the list of allowed ports for the container?

Ya, I’ve updated the firewall rules. Else syncthing on the host wouldn’t work properly. Updating the firewall rules on the container is pointless though, seeing the post-up port forward method I’m using is “bypassing” the firewall rules so to speak.

[gadget]

@Skyrider

My system has a single IP address with vmbr0 as the main bridge and vmbr1 for the virtual bridge. vmbr1 is used by the containers and the IP address of vmbr1 is shared among all the containers. As far as I know, port forwarding is required with this method.

So vmbr1 isn’t bound to a physical NIC?

Ya, I’ve updated the firewall rules. Else syncthing on the host wouldn’t work properly. Updating the firewall rules on the container is pointless though, seeing the post-up port forward method I’m using is “bypassing” the firewall rules so to speak.

It depends on where the firewall rules are… if the container is firewalled, the PVE host is subject to the same restrictions because it’s just another host device on the bridged network.