advanced install should open firewall ports

[zl1775]

Hi,

After setting up the outline server on my Ubuntu 17.10 machine, I tried connecting to it from my android phone or my windows desktop but encountered immediate disconnection after establish connection to the server. I was wondering if there was log files I could check for debugging purposes?

Thanks!

[zl1775]

Just for future references:

Logs: docker log [container]

D:2018-03-22T23:59:22.470Z] SB_PUBLIC_IP: XXX D:2018-03-22T23:59:22.470Z] SB_METRICS_URL: https://metrics-prod.uproxy.org D:2018-03-22T23:59:22.470Z] ============== I:2018-03-22T23:59:22.471Z] Starting... I:2018-03-22T23:59:22.511Z] Starting server on port 27771 I:2018-03-22T23:59:22.511Z] starting ss-server with args: -m XXXXX -u --fast-open -p 27771 -k 1OHulekf2gBn --manager-address 127.0.0.1:51078 I:2018-03-22T23:59:22.514Z] Starting server on port 10351 I:2018-03-22T23:59:22.514Z] starting ss-server with args: -m XXXXX -u --fast-open -p 10351 -k vBl97GprVbLc --manager-address 127.0.0.1:51078 I:2018-03-22T23:59:22.515Z] Starting server on port 33353 I:2018-03-22T23:59:22.515Z] starting ss-server with args: -m XXXXX -u --fast-open -p 33353 -k h2yBQpD5ERh7 --manager-address 127.0.0.1:51078 I:2018-03-22T23:59:22.576Z] Manager listening at https://[::]:34567/il_cKU8slW5crp8EJy_csA 2018-03-22 23:59:22 INFO: using tcp fast open 2018-03-22 23:59:22 INFO: using tcp fast open 2018-03-22 23:59:22 INFO: using tcp fast open D:2018-03-23T00:00:21.437Z] listAccessKeys request [object Object] D:2018-03-23T00:00:21.438Z] listAccessKeys response [object Object] D:2018-03-23T00:06:16.486Z] createNewAccessKey request [object Object] I:2018-03-23T00:06:16.581Z] Starting server on port 59684 I:2018-03-23T00:06:16.581Z] starting ss-server with args: -m XX -u --fast-open -p 59684 -k XX --manager-address 127.0.0.1:51078 I:2018-03-23T00:06:16.583Z] Persisting: {} 2018-03-23 00:06:16 INFO: using tcp fast open D:2018-03-23T00:06:26.606Z] removeAccessKey request [object Object] I:2018-03-23T00:06:26.607Z] Stopping server on port 59684 I:2018-03-23T00:06:26.608Z] Persisting: {} 2018-03-23 00:06:16 INFO: UDP relay enabled 2018-03-23 00:06:16 INFO: initializing ciphers... 2018-03-23 00:06:16 INFO: using nameserver: 127.0.0.53 2018-03-23 00:06:16 INFO: tcp server listening at 0.0.0.0:59684 2018-03-23 00:06:16 INFO: udp server listening at 0.0.0.0:59684 2018-03-23 00:06:16 INFO: running from root user I:2018-03-23T00:06:26.614Z] Server on port 59684 has exited. Code: 0, Signal: null D:2018-03-23T00:09:57.662Z] renameAccessKey request [object Object] I:2018-03-23T00:09:57.662Z] Persisting: {}

It seems that every key file needs a port access. So I had to manually open the ports again on my ufw. However, opening said ports ("27771", "10351", "33353") on my router was no necessary.

Suggestion: somehow automatically opening up ports needed when users add keys. This might be difficult as protocols differ greatly depending on platforms. Maybe limit the port number in a certain range (which will limit the number of keys allowed per server) and have users open up the range of ports during initial server set up?

[trevj]

@zl1775 Thanks for the report.

For others reading this issue, you can view the server logs with this command:

docker logs shadowbox

Great suggestions. We'd love to automatically configure the system's firewall when a new access key is added; alternatively, all access keys to use the same port.

[trevj]

@zl1775 You might be interested in a couple of recent/on-going improvements:

• the installer performs some basic checks on the firewall, warning if it thinks the relevant ports are not open
• we're adding instructions to the server manager on how to configure the firewall on Amazon and Google Cloud https://github.com/Jigsaw-Code/outline-server/pull/212

[orenwolf]

One data point:

On an RHEL7 install without firewalld, but a manually configured iptables, the install script found the ports to be open when they were not. Presumably, this was because the traffic passes when locally initiated, but not when the origination point is remote. Quick addition of the appropriate rules solved the issue and allowed the server to respond to requests and transport traffic.

I'm not sure what a fix would be for this case, since there's no easy way to perform a remote connectivity test. While the information of which ports / protocols need to be opened was useful in the script output, perhaps a link to instructions on how to either configure firewalld or iptables would be of use?