In the future, please use the </> button to place output and code.
It seems you have set up a web server on port 443. That isn't setup by default.
Are you running LuCI on HTTPS?
yea, would be less effort to disable https-luci or move it to another port.
1 Like
Yes, I;ve LuCI on HTTPS.
you dont gain much by this and exposing luci to the internet is a bad idea in any case
1 Like
OK, thank for your responses; I will try to disable LuCI on HTTPS
1 Like
I disabled LuCI on HTTPS, and now it works! Thanks for your responses.
Just for completeness, I made following changes:
in /etc/config/uhttpd to enable using http login again:
option redirect_https 0
and comment out these lines
# HTTPS listen addresses, multiple allowed
# list listen_https 0.0.0.0:443
# list listen_https [::]:443
reboot openWRT (and remove cookies from browser, otherwise you can't login into LuCI anymore)
1 Like
I think you've misinterpreted thing here! Running LuCI over TLS really should be manadatory as, among other things, it exposes the root password in plain text.
Two options both of which allow you to run LuCI over TLS, as best-practice demands
The first is probably the best, as there's no reason to be exposing uhttpd to the open Internet, doubly so when you've got VPN access
- Only bind your web server to your LAN address -- 192.168.1.1:443 for example
The second is a "make-do" approach, in my option, which would be to bind HTTP-S to a port other than 443.
In either case, you really should only be running HTTP-S, and disable listening on HTTP entirely (or, if running a sophisticated enough server, force all HTTP requests to redirect to HTTP-S).
Jeff, thanks for the info; I am not a network expert, so some questions:
- LuCI is at this moment not exposed to the internet (just tried to access http://"mypublicipaddress"); The only way to access LuCI from remote location for me, is to first connect to the OpenVPN server running on OpenWRT, and then point a browser to the internal IP-address of OpenWRT.
Is this safe?
How can I check that the web server is only bound to 192.168.1.1:80?
And what commands are necessary to correct this (if not already correct)?
Below the (IPv4) part of netstat:
netstat -tulpn|grep LIST
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1787/uhttpd
tcp 0 0 192.168.200.1:53 0.0.0.0:* LISTEN 2380/dnsmasq
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 2380/dnsmasq
tcp 0 0 192.168.2.253:53 0.0.0.0:* LISTEN 2380/dnsmasq
tcp 0 0 192.168.1.1:53 0.0.0.0:* LISTEN 2380/dnsmasq
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 1805/vsftpd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1349/dropbear
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 3268/openvpn
tcp 0 0 :::80 :::* LISTEN 1787/uhttpd
That shows you've you've got it bound to every interface and IP address. :::80 is the similar entry for IPv6.
I'd suggest only enabling HTTP-S on the standard port 443 and binding it explicitly to the IPv4 and possibly IPv6 address of your LAN (preferably a management VLAN, but I'll take specific LAN address over wildcard).
0.0.0.0 and [::] are wildcards
Again, running LuCI without HTTP-S is a significant security risk. It is a security "disaster" on your publicly accessible interfaces (which, unless you live in the middle of nowhere, you should consider your wireless as "publicly accessible" as well).
1 Like
I agree no web interface should run a credential on HTTP; but I do not believe that merely using HTTPS will secure the router.
If the OP is running LuCI on WAN, they need to think of another security paradigm.
OK, I will follow your advise 
(as I wrote before, I am not a network expert).
Just to be sure that I will make the right modifications:
/etc/config/uhttpd
Comment out port 80, uncomment port 443
NB: I changed port 443 to 1443, because my goal was to be able to run OpenVPN on 443.
So uhttpd looks now like this: (192.168.1.1 is the IP attached to the LAN of OpenWRT, the WAN has IP address 192.168.2..253)
# HTTP listen addresses, multiple allowed
# list listen_http 0.0.0.0:80
# list listen_http [::]:80
# HTTPS listen addresses, multiple allowed
list listen_https 192.168.1.1:1443
# list listen_https [::]:1443
# Redirect HTTP requests to HTTPS if possible
option redirect_https 1
Netstat command now looks like this:
netstat -tulpn |grep LIST
tcp 0 0 192.168.1.1:1443 0.0.0.0:* LISTEN 2171/uhttpd
tcp 0 0 192.168.200.1:53 0.0.0.0:* LISTEN 2345/dnsmasq
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 2345/dnsmasq
tcp 0 0 192.168.2.253:53 0.0.0.0:* LISTEN 2345/dnsmasq
tcp 0 0 192.168.1.1:53 0.0.0.0:* LISTEN 2345/dnsmasq
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 1835/vsftpd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1349/dropbear
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 3304/openvpn
BTW is
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 3304/openvpn
secure enought, or should I bind OpenVPN also to a specific IP address? If so to then IP address attached to the WAN interface, or the LAN interface?
Using the known address(es) to bind to is almost always preferred to using a wildcard (0.0.0.0, [::], *, are typical notations) when you know the addresses in advance.
So, for your LAN interface, yes, assuming that is the correct address, 192.168.1.1:1443 says "listen on port 1443 of 192.168.1.1 (only), in contrast to "listen on port 1443 of any interface that is up at the moment".
DHCP makes a mess of this if you're not in control of your outside IP address. You can either be secure and "hard code" your outside IP address, but have things not work if your ISP changes them, or deal with the fact that OpenVPN will be listening on all addresses if you use a wildcard. Some applications will let you specify which interface by name (or number) and then adjust if that interface changes its IP address. If that were possible, you'd be able to have OpenVPN listening on 443 on your "WAN" interface (only) and LuCI being served on 443 on your "LAN" interface only.
What you've got is a reasonable compromise -- you have LuCI being served over HTTP-S, LuCI is only available on your LAN interface, and you can reasonably configure OpenSSL to listen on 443 and adapt to DHCP changes in your WAN IP.
Note if an application lets you bind to an interface by name, you'd almost always use the kernel name (e.g. eth0.2) and not the OpenWrt uci name (wan).
1 Like
@jeff @mk24 thanks for your replies.
I think I am learning more and more about networking!
In my case the situation is rather simple.
- The OpenWRT router is behind my ISP-router.
- I assigned a fixed IP (192.168.2.253) to the WAN interface of my OpenWRT router
- So OpenVPN needs only to listen to 192.168.2.253:443
So I am going to (try) to find out how to configure OpenVPN to listen to this specific IP-address (or alternatively to the specific WAN interface)
I can't find how to make OpenVPN only listen to a specific interface (WAN) or IP-address (see previous post; the WAN interface has in my situation a fixed IP-address of 192.168.2.253).
How can I make this configuration form LuCI, or do I need to modify some config file?
https://openwrt.org/docs/guide-user/services/vpn/openvpn/basic is a good starting point for OpenVPN configuration on OpenWrt. I didn't see mention of which parameter to set there, so let's look at OpenVPN documentation to figure out what to set.
suggests that you're looking to set the local parameter.
Sometimes the wiki content isn't complete for more advanced options and looking at the scripts that convert the UCI files in /etc/config/ to the format that the executable uses can be helpful. One way to find them is to search the package table for OpenVPN and then click on the sources link.
Looking in the files directory there, I see openvpn.config (and got lucky that it's in the first one I looked at) which contains
suggesting that you can set option local 192.168.2.253 or the like in /etc/config/openvpn (as well as the port with option port 443).
Thanks for your extensive reply, and your explanation about how to be able to find the solution to problems myself!!
I followed your instructions, and everything is working fine (and secure).
OpenVPN only listening to WAN-IP:443
LuCI only listening to LAN-IP:443
Awsome!
2 Likes
what about to use sslh (ssl multiplexer) on tcp/443 and redirect protocols based on signature?
1 Like
possible, but in my experience sslh works worse than port-share
1 Like
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.