OpenVPN on 443 TCP can disturb Webconfigurator

athurdent

Shhhhhhh. "No, I need it on 443" :-X

Sorry, didn't mean to offend you! It's actually a pal of mine that needs it, like that. :)

@doktornotor: I never said the webconfigurator was listening on 443 WAN, it's on default settings listening on LAN 443

doktornotor

@doktornotor: I never said the webconfigurator was listening on 443 WAN, it's on default settings listening on LAN 443

Erm… it listens on *****:443 (or whatever other port you configure it to listen on, however, it listens on the configured port on all interfaces)…


## bind to port (default: 80)
server.bind  = "0.0.0.0"
server.port  = 443
$SERVER["socket"]  == "0.0.0.0:443" { }
$SERVER["socket"]  == "[::]:443" {

I cannot see how you can have it listen on 443 on LAN and not listen on 443 on WAN. Once again, what you are creating is completely broken.

athurdent

Well, it works.

tcp4       0      0 127.0.0.1.443          *.*                    LISTEN
tcp4       0      0 *.443                  *.*                    LISTEN

Strange, I have always run OpenVPN on 443 TCP WAN and never had a problem for the last year using it. In fact I never checked where the Webconfigurator listened, I assumed it was listening on LAN only.

jimp

move GUI to 444.

http://doc.pfsense.org/index.php/Sharing_a_Port_with_OpenVPN_and_a_Web_Server

Stick this in your OpenVPN config:

port-share 127.0.0.1 444

Enjoy.

kejianshi

I bet your web configurator is listening to TCP on 443 and openvpn is listening on UDP 443 (-;

Which you can do no problems.

I would recommend that if more reliable access to his vpn is what he is trying to accomplish by placing it on 443 (I assume he is trying to avoid block) that he run VPN threads that listen to 80 UDP and TCP and 443 UDP and TCP. Because the same yahoos that will block common vpn ports and protocols will block 443 udp or basically all udp leaving just 80/443 TCP on their nets.

kejianshi

OR maybe I'm wrong on that… I've never tried it as you describe.

jimp

In his netstat output it showed tcp4 for both. There is still potential for a race condition though, so using different ports is best, and compromise using port-share as I showed above.

FYI- @athurdent - use "sockstat" instead of "netstat" to view those. Then you'll get the process name and pid and such of who has which port open.

athurdent

Thanks everyone for looking into this! In fact I wouldn't have tried to run OpenVPN on 443 TCP without assigning the Webconfigurator to an other port if I had been aware where it was listening. I just assumed it ran on LAN only, because the setup was working just out of the box. And now I don't know why something like that would work at all.

sockstat | grep 443
root     openvpn    23126 11 tcp4   127.0.0.1:443         *:*
root     lighttpd   94927 10 tcp4   *:443                 *:*
root     lighttpd   94927 11 tcp6   *:443                 *:*

Thanks @jimp for the config advice and also for the Linux netstat -anp equivalent I have been missing on NetBSD for some time now ;)

kejianshi

Yep I learned I'm the only one using wild port number on all his non-public IP facing web interfaces to avoid 443/80 ;D

doktornotor

@athurdent:

And now I don't know why something like that would work at all.

Well, technically it can work with SO_REUSEADDR however it still is not something I'd do in this case… :-) Say, you have this:


0.0.0.0:443   127.0.0.1:443

will be OK and working with SO_REUSEADDR enabled on a socket before binding it

However, this:

127.0.0.1:443   127.0.0.1:443

or this combo:


0.0.0.0:443   0.0.0.0:443

will result in EADDRINUSE no matter whether SO_REUSEADDR is on or off.