Can't access gui externaly, can through ssh tunnel. Port open

[beardedfool]

Hi,

Manual/ ansible install of syncthing that’s defintely running as I can acess the gui from an ssh tunnel, but not externally on a headless server.

Interestingly the GUI Actions>Settings>GUI shows the IP as 127.0.0.1:8384 Not sure if this should be 0.0.0.0:8384 as per the service.

Also:

The GUI address is overridden by startup options. Changes here will not take effect while the override is in place.

I’ve disabled ufw but no dice. nmap is showing the port as open, netstat from the server is showing 8384 as listening

Side question: I’m tying ufw to IPs but please shout if there’s any other hardening suggestions other than https if it’s to be publically exposed without that.

Any suggestions on next steps in troubleshooting please?

systemctl status syncthing@name ● syncthing@name.service - Syncthing - Open Source Continuous File Synchronization for andy Loaded: loaded (/etc/systemd/system/syncthing@.service; indirect; vendor preset: enabled) Active: active (running) since Wed 2021-06-09 17:44:11 BST; 59min ago Docs: man:syncthing(1) Main PID: 46219 (syncthing) Tasks: 21 (limit: 9830) CGroup: /system.slice/system-syncthing.slice/syncthing@name.service ├─46219 /usr/bin/syncthing -no-browser -gui-address=0.0.0.0:8384 -no-restart -logflags=0 └─46228 /usr/bin/syncthing -no-browser -gui-address=0.0.0.0:8384 -no-restart -logflags=0

cat /etc/systemd/system/multi-user.target.wants/syncthing@name.service # BEGIN ANSIBLE MANAGED BLOCK [Unit] Description=Syncthing - Open Source Continuous File Synchronization for %I Documentation=man:syncthing(1) After=network.target

[Service]
User=%i
ExecStart=/usr/bin/syncthing -no-browser -gui-address="0.0.0.0:8384" -no-restart -logflags=0
Restart=on-failure
SuccessExitStatus=3 4
RestartForceExitStatus=3 4

[Install]
WantedBy=multi-user.target
# END ANSIBLE MANAGED BLOCK

[bt90]

You don’t need to whitelist IPs if you enable HTTPS and pick a strong password.

0.0.0.0:8384 is the correct value if you want it publicly accessible. 127.0.01 would only allow access from the device itself e.g via a local browser or ssh port forwarding.

As your service starts syncthing with --gui-address="0.0.0.0:8384" this should work.

Did you follow the docs for ufw setup?

https://docs.syncthing.net/users/firewall.html#uncomplicated-firewall-ufw

Could you post the active firewall rules using:

sudo iptables -S

[beardedfool]

@bt90

Did you follow the docs for ufw setup?

Firewall Setup — Syncthing documentation

Could you post the active firewall rules using:

sudo iptables -S

Thanks for coming back to me, hugely appreciated

Is there any significance of the gui showing 127.0.0.1, rather than 0.0.0.0, or does it always show that?

I did follow those ufw steps but, possible more importantly (?) I’ve disabled it entirely for testing and here’s it then

$ sudo iptables -S

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N ufw-after-forward
-N ufw-after-input
-N ufw-after-logging-forward
-N ufw-after-logging-input
-N ufw-after-logging-output
-N ufw-after-output
-N ufw-before-forward
-N ufw-before-input
-N ufw-before-logging-forward
-N ufw-before-logging-input
-N ufw-before-logging-output
-N ufw-before-output
-N ufw-reject-forward
-N ufw-reject-input
-N ufw-reject-output
-N ufw-track-forward
-N ufw-track-input
-N ufw-track-output
-A INPUT -j ufw-before-logging-input
-A INPUT -j ufw-before-input
-A INPUT -j ufw-after-input
-A INPUT -j ufw-after-logging-input
-A INPUT -j ufw-reject-input
-A INPUT -j ufw-track-input
-A FORWARD -j ufw-before-logging-forward
-A FORWARD -j ufw-before-forward
-A FORWARD -j ufw-after-forward
-A FORWARD -j ufw-after-logging-forward
-A FORWARD -j ufw-reject-forward
-A FORWARD -j ufw-track-forward
-A OUTPUT -j ufw-before-logging-output
-A OUTPUT -j ufw-before-output
-A OUTPUT -j ufw-after-output
-A OUTPUT -j ufw-after-logging-output
-A OUTPUT -j ufw-reject-output
-A OUTPUT -j ufw-track-output

with it enabled again - I’m not posting the full tables here if that’s ok but shout if something is obviously missing and I’ll check but think this is what you’re looking for

-A ufw-user-input -s X.X.X.X/32 -p tcp -m tcp --dport 8384 -j ACCEPT
-A ufw-user-input -s X.X.X.X/32 -p udp -m udp --dport 8384 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 80 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 80 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 443 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 443 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 22000 -m comment --comment "\'dapp_syncthing\'" -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 22000 -m comment --comment "\'dapp_syncthing\'" -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 21027 -m comment --comment "\'dapp_syncthing\'" -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 8384 -m comment --comment "\'dapp_syncthing-gui\'" -j ACCEPT
-A ufw-user-limit -m limit --limit 3/min -j LOG --log-prefix "[UFW LIMIT BLOCK] "
-A ufw-user-limit -j REJECT --reject-with icmp-port-unreachable

[bt90]

You can check if syncthing is actually listening on 0.0.0.0:8384

sudo netstat -tulpn

[beardedfool]

@beardedfool

I’ve disabled ufw but no dice. nmap is showing the port as open, netstat from the server is showing 8384 as listening

Thanks, you may have missed this line in my original post?

I’ve disabled ufw but no dice. nmap is showing the port as open, netstat from the server is showing 8384 as listening

EDIT Ah, sorry, I see what you’re saying now. Whether it’s on 0.0.0.0 Seems it’s not working on IPV4?? I think the ssh tunnels are confusing the below but maybe you’ll see something I can’t. Just about to head home and I’ll reboot it and see what it’s saying without those.

tcp        0      0 localhost:43482         localhost:8384          ESTABLISHED
tcp        0      0 localhost:43470         localhost:8384          TIME_WAIT
tcp        0      0 localhost:43480         localhost:8384          ESTABLISHED
tcp        0      0 localhost:43476         localhost:8384          ESTABLISHED
tcp        0      0 localhost:42474         localhost:8384          ESTABLISHED
tcp        0      0 localhost:43468         localhost:8384          TIME_WAIT
tcp        0      0 localhost:43474         localhost:8384          TIME_WAIT
tcp        0      0 localhost:43472         localhost:8384          TIME_WAIT
tcp        0      0 localhost:43478         localhost:8384          ESTABLISHED
tcp6       0      0 [::]:8384               [::]:*                  LISTEN
tcp6       0      0 localhost:8384          localhost:43466         TIME_WAIT
tcp6       0      0 localhost:8384          localhost:43460         TIME_WAIT
tcp6       0      0 localhost:8384          localhost:43464         TIME_WAIT
tcp6       0      0 localhost:8384          localhost:43476         ESTABLISHED
tcp6       0      0 localhost:8384          localhost:43480         ESTABLISHED
tcp6       0      0 localhost:8384          localhost:43472         TIME_WAIT
tcp6       0      0 localhost:8384          localhost:42474         ESTABLISHED
tcp6       0      0 localhost:8384          localhost:43482         ESTABLISHED
tcp6       0      0 localhost:8384          localhost:43478         ESTABLISHED
tcp6       0      0 localhost:8384          localhost:43462         TIME_WAIT

[bt90]

Your netstat output looks fine. Don’t get confused by [::]:8384 as it’s listening for both IPv4 and IPv6.

[beardedfool]

Thanks, I really need to get my head round IPv6 soon!

So, we know it’s listening, nmap shows the port open, ufw disabled. We know it’s working internall through ssh tunnel

Any more thoughts as I’m a bit stumped there.

I’m still mentally stuck on the gui showing 127.0.0.1 rather than 0.0.0.0 but maybe that’s just a quirk, rather than a serious problem.

Guess I can comb through logs later

[beardedfool]

From journalctl on starting the service, is it significant that it’s not saying 0.0.0.0. - dunno!

INFO: GUI and API listening on [::]:8384
INFO: Access the GUI via the following URL: https://127.0.0.1:8384/

[beardedfool]

I have now also tried:

*Changing port *Changing 0.0.0.0 to external IP *running as root *runnning manually from commmand line, rather than through systemd *accessing by IP, rather than dns and variations of all

No change, same behaviour

[bt90]

Could you also change the listening address in the GUI to 0.0.0.0:8384 ?

[AudriusButkevicius]

[::] is equivalent tho, so I am certain this will be a firewall issue.

[beardedfool]

@bt90

Could you also change the listening address in the GUI to 0.0.0.0:8384 ?

Interesting, I hadn’t tried that because of the

The GUI address is overridden by startup options. Changes here will not take effect while the override is in place.

but it does seem to stay in the settings once I change it!

I feel I’m getting at least closer to that “Sorry, I’ve been an idiot message”, but I’m not quite there yet

I’ve found something else interesting, that in ~/.config/syncthing/config.xml…

1. It’s created with 127.0.0.1:8384 despite the service file asking for 0.0.0.0:8384
2. The change in gui IP you asked for also changes that config
3. That if I change the config.xml to 0.0.0.0:8384 before I start the service it starts on 0.0.0.0:8384. i.e. the config fiie is overriding the service file
4. That noone of those changes make it work

I’m 99% sure I am NOT templating that config out in my install ansible script but I’ll double check that

[beardedfool]

@AudriusButkevicius

[::] is equivalent tho, so I am certain this will be a firewall issue.

Ok, that’s good to hear in a way. I’m sending a ticket to the hosting company to check they’re not doing anything weird

I think I may need to start again as I’m now getting nmap -p 8384 PORT STATE SERVICE 8384/tcp filtered marathontp

Whereas I’m pretty sure it said open before. Presume it should be open (?)

[Nummer378 (Max)]

Just to clear up some potential confusion about this:

@beardedfool

INFO: Access the GUI via the following URL: https://127.0.0.1:8384/

@nummer378

The “Access the GUI via the following URL:” line is meant to give the user something clickable, something that can (probably) be copy-pasted into a browser. The wildcard address (0.0.0.0) isn’t routable, you can’t type that as a destination adress. So syncthing will replace that address with something more local (localhost) when creating a printable HTTP URL. It doesn’t neccessarily check whether that assumption is true in your network setup.

Directly above this line, you will see something like this in the log:

GUI and API listening on 0.0.0.0:8384

That’s the actual listen address.

[beardedfool]

Ahh, thank Nummer, that’s helpful info.

[beardedfool]

@beardedfool

I feel I’m getting at least closer to that “Sorry, I’ve been an idiot message”

Sorry, I’ve been an idiot…

All those that voted “Firewall” please redeem your prize at the checkout.

I’m my defence I was told all ports were open by the hosting company but apparantly an upsteam firewall was blocking this. Annoying but ce la vie

Thank you for all your help on this one and for all you do, hugely appreciated.