OpenVPN on 443 TCP can disturb Webconfigurator
-
If I configure OpenVPN to listen on TCP 443 WAN, reboot and PPPoE (maybe DHCP, too?) can't get an IP, OpenVPN listens on *:443. OpenVPN starts before Webconfigurator, so the latter fails to come up.
-
Manually stipulate the web config to something else like 7443 or better yet just pull a port number above 50000 out of a hat like 53561 under system > advanced and use that like https://192.168.1.1:53561
-
No, I need it on 443. No biggie, you can just let OpenVPN listen on Localhost and Port Forward 443 to there. Just wanted to report this as it could puzzle others…
-
No, I need it on 443. No biggie, you can just let OpenVPN listen on Localhost and Port Forward 443 to there. Just wanted to report this as it could puzzle others…
Huh, what? How do you assume the port-forward from WAN:443 (TCP) to localhost:443 (TCP) will work and keep the webconfigurator working at the same time on WAN:443 (TCP)? You created completely broken configuration.
-
Shhhhhhh. "No, I need it on 443" :-X
-
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: 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.
-
Well, it works.
tcp4 0 0 127.0.0.1.443 *.* LISTEN tcp4 0 0 *.443 *.* LISTENStrange, 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.
-
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 444Enjoy.
-
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.
-
OR maybe I'm wrong on that… I've never tried it as you describe.
-
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.
-
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 ;)
-
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
-
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:443will 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:443or this combo:
0.0.0.0:443 0.0.0.0:443will result in EADDRINUSE no matter whether SO_REUSEADDR is on or off.
