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

beardedfool · June 9, 2021, 5:52pm

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 · June 9, 2021, 6:51pm

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 · June 9, 2021, 7:37pm

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 · June 9, 2021, 7:56pm

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

sudo netstat -tulpn

beardedfool · June 9, 2021, 8:05pm

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 · June 9, 2021, 8:41pm

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

beardedfool · June 9, 2021, 9:22pm

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 · June 9, 2021, 11:02pm

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 · June 9, 2021, 11:46pm

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 · June 10, 2021, 5:12am

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

AudriusButkevicius · June 10, 2021, 6:50am

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

beardedfool · June 10, 2021, 7:45am

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…

It’s created with 127.0.0.1:8384 despite the service file asking for 0.0.0.0:8384
The change in gui IP you asked for also changes that config
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
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 · June 10, 2021, 7:51am

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 · June 10, 2021, 10:17am

Just to clear up some potential confusion about this:

beardedfool · June 10, 2021, 7:24pm

Ahh, thank Nummer, that’s helpful info.

beardedfool · June 11, 2021, 2:08pm

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.

system · July 11, 2021, 2:09pm

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.