TOS 5.0.3: Web interface open on WAN by default exposing turris.cz self-signed cert | port forwarding not working for IPv6

Hi

I did a fresh flash of TOS 5.0.3 and encounter the following problem:
The web interface is exposed to WAN by default!
I would consider this as a bug, most people wouldn’t want their management interface open to the public right after (?) the initial setup.

Now I have a NAS in the LAN, for which in configured port forwarding for 80 and 443.
DDNS is setup for ipv4 and 6 and works.

This obviously overwrites the router web interface and worked initially.
But it seems like ipv6 is broken.
If I do a curl -vvv -4 https://mydomain.duckdns.org I get the correct page and the let’s encrypt cert from my NAS.
If I do the curl with -6 I get this:

* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: self signed certificate
* Closing connection 0
curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

This cert is issued to turris.cz.
How can I completely turn off the web interface for WAN?

Matter of perspective/philosophy perhaps, meaning tagging as bug or not. The distro developers seem to prefer the server to listen globally on TCP port(s) 80 | 443. However, in a vanilla setup the firewall has those ports not open on WAN ingress and thus the admin UI is not exposed on the WAN side.


by patching the http server’s configuration files and specifying private (ULA) IP address(es) binding(s).
Server documentation https://redmine.lighttpd.net/projects/lighttpd/wiki

Also please double check if you are really going to your public IP from outside of your network (via VPN or Broadband connection or completely other network). Because there is something called NAT Loopback and it’s on by default so you can reach your WWW interface also by your public IP.

1 Like

Thanks for your replies!

Just realized the web interface is not open when I’m connecting from the outside! So that part is solved, thanks for the hint @AreYouLoco.
I was confused because the public IP returned the web interface… Oh well.

Now the behaviour is as follows:
From inside the LAN when requesting my ddns domain:

  • curl: IPv4 works, IPv6 shows turris web interace (or cert error for https)
  • Browsers Firefox, Chromium, Brave all show the turris web interface (or cert error for https)

Originating requests from WAN work as intended, both IPv4 and 6, http and https.

@AreYouLoco
That would make sense given the problem exists only from inside the LAN.
It seems like NAT Loopback is enabled on both port forwarding rules by default!
I tried switching it off/on but neither changed that…
Any ideas?

/etc/init.d/network restart ?

Port forwarding is not a thing in IPv6.
Assuming you have set up DDNS on the router, not on the NAS, the DDNS entry points to the public IPv4 address and the IPv6 address of the router.

If you want to access the NAS from outside or using a public hostname, you need to publish NAS IPv6 address and router’s IPv4 address (with port forwarding enabled) in the DDNS. Can the NAS run a DDNS client?

Hmm true, didn’t think of that.
My NAS is debian so that should work too, might give it a try or just get rid of the IPv6 DDNS entry.

Thanks all for you suggestions.
The problems are gone now that I disabled the IPv6 entry in my DDNS provider.