SOLVED - OpenVPN server at port 443 - and also LuCI (https) at port 443, together working

bassie · January 1, 2019, 10:40am

I installed OpenVPN server on 18.06 (used this guide.
This guide is excellent, and I have OpenVPN working on port 1194.

However I want OpenVPN to use port 443 (because of port restrictions on public (wifi) networks).
So I changed via Luci the OpenVPN config to use port 443, adapted the firewall to accept port 443 iso 1194, and changed the client openvpn config to also use port 443.

Restarting OpenVPN (via Luci) fails.
This doesn't work, because port 443 is already in use. How can I make OpenVPN work on port 443 (TCP)?

part of log:

Tue Jan  1 11:37:01 2019 daemon.notice openvpn(vpnserver)[32751]: OpenVPN 2.4.5 mips-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Tue Jan  1 11:37:01 2019 daemon.notice openvpn(vpnserver)[32751]: library versions: OpenSSL 1.0.2p  14 Aug 2018, LZO 2.10
Tue Jan  1 11:37:01 2019 daemon.notice openvpn(vpnserver)[32751]: Diffie-Hellman initialized with 2048 bit key
Tue Jan  1 11:37:01 2019 daemon.notice openvpn(vpnserver)[32751]: Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Tue Jan  1 11:37:01 2019 daemon.notice openvpn(vpnserver)[32751]: Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Tue Jan  1 11:37:01 2019 daemon.notice openvpn(vpnserver)[32751]: Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Tue Jan  1 11:37:01 2019 daemon.notice openvpn(vpnserver)[32751]: Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Tue Jan  1 11:37:01 2019 daemon.notice openvpn(vpnserver)[32751]: tls_crypt_adjust_frame_parameters: Adjusting frame parameters for tls-crypt by 56 bytes
Tue Jan  1 11:37:01 2019 daemon.notice openvpn(vpnserver)[32751]: TLS-Auth MTU parms [ L:1624 D:1154 EF:96 EB:0 ET:0 EL:3 ]
Tue Jan  1 11:37:01 2019 daemon.notice netifd: Interface 'vpnserver' is enabled
Tue Jan  1 11:37:01 2019 daemon.notice netifd: Network device 'tun0' link is up
Tue Jan  1 11:37:01 2019 daemon.notice netifd: Interface 'vpnserver' has link connectivity
Tue Jan  1 11:37:01 2019 daemon.notice netifd: Interface 'vpnserver' is setting up now
Tue Jan  1 11:37:01 2019 daemon.notice netifd: Interface 'vpnserver' is now up
Tue Jan  1 11:37:01 2019 daemon.notice openvpn(vpnserver)[32751]: TUN/TAP device tun0 opened
Tue Jan  1 11:37:01 2019 daemon.notice openvpn(vpnserver)[32751]: TUN/TAP TX queue length set to 100
Tue Jan  1 11:37:01 2019 daemon.notice openvpn(vpnserver)[32751]: do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Tue Jan  1 11:37:01 2019 daemon.notice openvpn(vpnserver)[32751]: /sbin/ifconfig tun0 192.168.200.1 netmask 255.255.255.0 mtu 1500 broadcast 192.168.200.255
Tue Jan  1 11:37:01 2019 daemon.notice openvpn(vpnserver)[32751]: Data Channel MTU parms [ L:1624 D:1450 EF:124 EB:406 ET:0 EL:3 ]
Tue Jan  1 11:37:01 2019 daemon.warn openvpn(vpnserver)[32751]: Could not determine IPv4/IPv6 protocol. Using AF_INET
Tue Jan  1 11:37:01 2019 daemon.notice openvpn(vpnserver)[32751]: Socket Buffers: R=[87380->87380] S=[16384->16384]
Tue Jan  1 11:37:01 2019 daemon.err openvpn(vpnserver)[32751]: TCP/UDP: Socket bind failed on local address [AF_INET][undef]:443: Address in use (errno=125)
Tue Jan  1 11:37:01 2019 daemon.notice openvpn(vpnserver)[32751]: Exiting due to fatal error
Tue Jan  1 11:37:01 2019 daemon.notice openvpn(vpnserver)[32751]: Closing TUN/TAP interface
Tue Jan  1 11:37:01 2019 daemon.notice openvpn(vpnserver)[32751]: /sbin/ifconfig tun0 0.0.0.0
Tue Jan  1 11:37:01 2019 daemon.notice netifd: Network device 'tun0' link is down
Tue Jan  1 11:37:01 2019 daemon.notice netifd: Interface 'vpnserver' has link connectivity loss
Tue Jan  1 11:37:01 2019 daemon.notice netifd: Interface 'vpnserver' is now down

lleachii · January 1, 2019, 10:54am

First, explain what you have running on 443?

bassie · January 1, 2019, 11:05am

Some standard stuff is running on 443 (I assume the https GUI of OpenWRT).

 netstat -tulpn | grep LISTEN
tcp        0      0 0.0.0.0:1194            0.0.0.0:*               LISTEN      26547/openvpn
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      1788/uhttpd
tcp        0      0 192.168.200.1:53        0.0.0.0:*               LISTEN      2339/dnsmasq
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      2339/dnsmasq
tcp        0      0 192.168.2.253:53        0.0.0.0:*               LISTEN      2339/dnsmasq
tcp        0      0 192.168.1.1:53          0.0.0.0:*               LISTEN      2339/dnsmasq
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      1822/vsftpd
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1350/dropbear
tcp        0      0 0.0.0.0:**443**             0.0.0.0:*               LISTEN      1788/uhttpd

fuller · January 1, 2019, 11:08am

openvpn has option port-share to deal with this

lleachii · January 1, 2019, 11:09am

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?

fuller · January 1, 2019, 11:11am

yea, would be less effort to disable https-luci or move it to another port.

bassie · January 1, 2019, 11:11am

Yes, I;ve LuCI on HTTPS.

fuller · January 1, 2019, 11:15am

you dont gain much by this and exposing luci to the internet is a bad idea in any case

bassie · January 1, 2019, 12:00pm

OK, thank for your responses; I will try to disable LuCI on HTTPS

bassie · January 1, 2019, 12:30pm

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)

jeff · January 1, 2019, 4:53pm

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).

bassie · January 1, 2019, 7:12pm

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

jeff · January 1, 2019, 7:32pm

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).

lleachii · January 1, 2019, 7:52pm

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.

bassie · January 1, 2019, 7:56pm

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?

jeff · January 1, 2019, 10:18pm

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.

mk24 · January 1, 2019, 10:44pm

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).

bassie · January 2, 2019, 8:31am

@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)

bassie · January 2, 2019, 9:43am

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?

jeff · January 2, 2019, 6:25pm

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.

github.com

OpenVPN/openvpn/blob/master/sample/sample-config-files/server.conf#L23


#                                               #
# This config should work on Windows            #
# or Linux/BSD systems.  Remember on            #
# Windows to quote pathnames and use            #
# double backslashes, e.g.:                     #
# "C:\\Program Files\\OpenVPN\\config\\foo.key" #
#                                               #
# Comments are preceded with '#' or ';'         #
#################################################


# Which local IP address should OpenVPN
# listen on? (optional)
;local a.b.c.d


# Which TCP/UDP port should OpenVPN listen on?
# If you want to run multiple OpenVPN instances
# on the same machine, use a different port
# number for each one.  You will need to
# open up this port on your firewall.
port 1194

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

github.com

openwrt/openwrt/blob/openwrt-18.06/package/network/services/openvpn/files/openvpn.config#L28


# multi-client server.                          #
#################################################


config openvpn sample_server


	# Set to 1 to enable this instance:
	option enabled 0


	# Which local IP address should OpenVPN
	# listen on? (optional)
#	option local 0.0.0.0


	# Which TCP/UDP port should OpenVPN listen on?
	# If you want to run multiple OpenVPN instances
	# on the same machine, use a different port
	# number for each one.  You will need to
	# open up this port on your firewall.
	option port 1194


	# TCP or UDP server?
#	option proto tcp

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).