OpenVPN via port 443

seggerman

Guys,

I'm trying to setup OpenVPN to listen on port 443, since I want to bypass very restictive firewalls that only open Port 80 and 443.

I've started with setting up OpenVPN on the standard port 1194 and everything works fine. I can tunnel into my pfsense box and everything works fine (I can access everything internal, and additionally I route all traffic through pfsense back into the WAN, to bypass this restrictive firewall). Everything OK

Nove I've changed the port to 443 and basically nothing works anymore (I do not get any nameresolution anymore, and routing through pfsense back into the WAN doesn't work either).

I changed the webgui port to something else than 443 (thinking, that this might interfere) -> no effect. I changed the OpenVPN port to something else than 443 (in this case 445) and everything is working again.

So it has something to do with Port 443. I've searched the forums and the web but I cannot find a solution for this.

Is there something that I'm missing? Something that is conflicting with me using 443?

Hope somebody can help me

Cheers

Alexander

Nachtfalke

Hi,

the default settings of OpenVPN server use UDP as protocol. HTTPS which uses port 443 uses TCP as protocol. So check your protocol settings in firewall rules.

seggerman

I've already switched everything to TCP,

here is my config:

<openvpn-server><vpnid>1</vpnid>
<mode>server_tls</mode>
<authmode>Local Database</authmode>
<protocol>TCP</protocol>
<ipaddr><interface>wan</interface>
<local_port>1194</local_port>

<custom_options>push "redirect-gateway def1"</custom_options>
<caref>4d300fec249d7</caref>
<crlref><certref>4d3010589696f</certref>
<dh_length>1024</dh_length>
<crypto>AES-128-CBC</crypto>
<engine>padlock</engine>
<tunnel_network>192.168.4.0/24</tunnel_network>
<remote_network><gwredir><local_network>192.168.3.0/24</local_network>
<maxclients><compression>yes</compression>
<passtos><client2client><dynamic_ip>yes</dynamic_ip>
<pool_enable>yes</pool_enable>
<dns_domain>home.net</dns_domain>
<dns_server1>192.168.3.1</dns_server1>
<dns_server2><dns_server3><dns_server4><netbios_enable><netbios_ntype>0</netbios_ntype></netbios_enable></dns_server4></dns_server3></dns_server2></client2client></passtos></maxclients></gwredir></remote_network></crlref></ipaddr></openvpn-server>

and if I switch from 1194 to 443 it then doesn't work anymore. Switch back and everything is OK.

I have two firewall rules in place (in the WAN tab):
TCP * * WAN address 1194 (OpenVPN) * none
TCP * * WAN address 443 (HTTPS) * none

So basically everything should be set. But to no avail :-(

Alexander

Nachtfalke

Hi,

I am using snapshot 2.0-BETA5 (i386) built on Tue Feb 1 19:36:32 EST 2011

I tried this with port 1194 and UDP, then switched to port 443 and TCP. I did these changes in mit .ovpn config, too and it worked without problems.

–-edit---

I reverted webGUI from https to http before testing.

---edit2---
changed port from https webgui to 44444 and used openvpn on port 443 with tcp and it worked without any problems.

seggerman

It seems as if the problem was sitting in front of the keyboard … I gave it a test drive and now it works. To my knowledge nothing different than before, but now everything is ok.

Thanks

Alexander

Nachtfalke

In the past, I had similar problems like this. Just deleted the OpenVPN server and reconfigured it and then it worked well.

Nevertheless, nice to hear, that it works now :-)

johnpoz

I have been running openvpn on the beta since I have been running it.. Came right up not an issue.. Curious to the root cause of the problem other than your self diagnosed PEBKAC ;)

443 should really be the default port if you ask me - it makes much more sense in a road warrior setup since you never know where your users will be and what ports will be open.. But if there is internet access it would seem logical that 443 would be open.

dszp

I run OpenVPN at 443 for my use as well, but the default will always be 1194 which is the officially-assigned-by-the-IANA OpenVPN port number (see IANA port list and Wikipedia port list). I doubt pfSense will change the default from the officially-assigned port any time soon.

Also, I've found TCP OpenVPN connections to be significantly slower than UDP-based tunnels, I assume (and have been told) due to the additional overheard of doing TCP-over-TCP through the tunnel. It works, just a lot lower bandwidth. In my experience.

cmb

@David:

Also, I've found TCP OpenVPN connections to be significantly slower than UDP-based tunnels, I assume (and have been told) due to the additional overheard of doing TCP-over-TCP through the tunnel. It works, just a lot lower bandwidth. In my experience.

Exactly, go Google on tunneling TCP over TCP, it's not ideal though it works. At least in first world countries where Internet connections are pretty solid, from some experience in the less developed parts of the world, it's likely to be near or entirely unusable because of all the double retransmitting on shoddy Internet connections common in such places.

Note if you want to run OpenVPN on 443, you must change the port of your web interface under System>Advanced to something other than 443.

dszp

Yep…for this reason I actually set up two tunnels on port 443, one using UDP and the other with TCP, and have both configured in my OpenVPN client. I suspect, though I don't use free wifi very often, that many providers are sloppy and if they do lockdown ports, may allow UDP and TCP both on port 443, so the UDP version would still be usable. However, TCP is still available to fall back on.

But, another issue might be if they are examining all port 443 TCP traffic for content filtering...on corporate network this is done by pushing a trusted root certificate from the firewall to all company-owned machines and generating spoofed certificates for every secure site so the firewall an inspect and transparently proxy the traffic. I've seen public wireless misconfigured (intentionally?) to do this as well, though you will always see a certificate warning unless you manually install their root certificate (not recommended of course). However, it may prevent access via port 443 TCP using OpenVPN (though UDP could be blocked in any of the above cases regardless).

Assuming DNS is not blocked/proxied, you could fall back on using TCP-over-DNS for remote communication, but that has nothing to do with pfSense (though it would be cool if someone wrote a pfSense package for it :-) Or, find another Internet connection to use, which may be the easiest if the network really is this locked down.