# OpenVPN through port 443 is not working (Windows -> Gentoo)

## fuzion

I have a Gentoo PC at home running OpenVPN and acting as a VPN server. The OpenVPN is configured to listen on port 443 which I have forwarded to the Gentoo PC.

VPN works when I test it using Linux at home but it does not work when testing it using Windows at work.

This is seen in the client log (verb 7):

 *Quote:*   

> Attempting to establish TCP connection with xxx.xxx.xxx.xxx:443
> 
> PID packet_id_free (a few times)
> 
> TCP/UDP: Closing socket
> ...

 

This is seen in the server log (verb 3):

 *Quote:*   

> TCP connection established with xxx.xxx.xxx.xxx:51722 (port number appears to be differnt every time)
> 
> TCPv4_SERVER link local: [undef]
> 
> TCPv4_SERVER link remote: xxx.xxx.xxx.xxx:51722
> ...

 

Is the server attempting to make a TCP connection back to the client using a port other than 443? Is it possible that this port is blocked by the company firewall and that's why it is failing? I thought that OpenVPN supports listening on port 443 is because the traffic is similar to HTTPS traffic (encrypted with SSL) so that firewalls cannot block it if the HTTPS port 443 is open (or it would be possible to block OpenVPN and not HTTPS but very difficult).

Any suggestions? Am I missing something obvious or has my IT department found a clever way to block OpenVPN on port 443 (my IT department isn't very clever but I could see them buying expensive hardware to take care of this for them).

Client config:

 *Quote:*   

> client
> 
> dev tun
> 
> proto tcp
> ...

 

Server config:

 *Quote:*   

> port 443
> 
> proto tcp
> 
> dev tun
> ...

 

I'm using this HOWTO as a guideline:

http://en.gentoo-wiki.com/wiki/OpenVPN

----------

## Strupniveral

Since the server logs the incoming connections, I'd say the firewall doesn't block the outgoing connections; on the other way your client makes connections starting from ports different than 443 (51722), but this is the way it should work, so I don't see particular issues on this side.

On the other hand, I had a quite similar issue from my mac (client) to linux (server), due to the fact the vpn client, by default, had a different version of openvpn server set on its end, and this lead to some connection issue, even if the other configuration parameters were fine.

Long story made short: can you try to use a Window machine at home too? Possibly same OS version and vpn client? (other way is possible too: bring your linux client to office)

If you encounter any issue in this way, the problem is in your window client configuration and you can easily fixing it at home.

Once working, you'll be 100% sure that your configuration and all is fine and if the issue still persist from office is something in between..

HTH,

Luca

----------

## fuzion

It ends up that the server is running 2.1.4 while I was trying version 2.2.2 on the Windows computer.

I tried the same version (2.2.2) on a Windows computer at home. It worked fine with the exact same config. Well it connected fine but the virtual network didn't work. I reran OpenVPN GUI as Administrator (Windows 7) and then it connected fine and the virtual network worked fine.

I guess this implies that my IT department spent a lot of money on some HW to block this...

If the server needs to make a connection back to the client on a port other than 443 (I'm assuming that is what is happening) then I could see that being easy to block. Although I thought it was supposed to work similar to accessing an HTTPS web site (correct me if I'm wrong). Although I didn't think an HTTPS web site would have to make a TCP connection back to the client on some port other than 443.

Wouldn't OpenVPN be able to work with only one TCP socket connection? I.e. only one connection could be used for traffic in both directions. What good is a tunnel if I have to be able to open some random port on the client in order for this to work?

Any other suggestions?

I might have to try a Linux client at work next, running the same version of OpenVPN as the server but I doubt that will help. I suspect that I would have to get a port opened (or forwarded) to my client in order for this to work...

Can anyone confirm or disprove whether the OpenVPN server needs to make a TCP connection back to the client? If I know this is happening then likely all bets are off.

If this is the case then you would think this also should be a configurable option on the OpenVPN server (i.e. to instruct it which port on the client to connect back to).

----------

## fuzion

Is it possible that the client opens some random port to use to connect to port 443 on the OpenVPN server? So in fact only one TCP socket connection is being used. If this is the case, then maybe the IT firewall is blocking incoming traffic to the client's port... although I don't see how this would be different from browings an HTTP web site on port 443... (and as such how the firewall could block OpenVPN traffic but not the HTTPS web site traffic).

----------

## Hu

 *fuzion wrote:*   

> Can anyone confirm or disprove whether the OpenVPN server needs to make a TCP connection back to the client? If I know this is happening then likely all bets are off.

 You can confirm this yourself.  Before you initiate the client handshake, have the Linux machine start tcpdump monitoring traffic to and from the public IP of the work system.

----------

## fuzion

I tried this from home and it looks like there is only one TCP socket connection. i.e. the server does not reconnect to another port on the client.

I only see port "https" which presumably is 443 being used on the server and in this case, port 39095 being used on the client.

For example:

 *Quote:*   

> xxx.xxx.xxx.xxx.https > yyy.yyy.yyy.yyy.39095 (many times)
> 
> yyy.yyy.yyy.yyy.39095 > xxx.xxx.xxx.xxx.https (many times)
> 
> 

 

I don't see any network activity between the two IP addresses on any other ports.

I'll have to try this at work as well and see if anything obvious sticks out. What surprises me is that HTTPS web sites work fine but OpenVPN connecting to port 443 does not. I also like the idea of trying a Linux client at work as well in case there is something strange happening with the Windows PC there.

----------

## Strupniveral

Yesterday I went trough your configuration and I noticed a major difference w.r.t. mine: the defined protocol. While you're using TCP, I'm running mine on UDP.

While I can't remember all the technical details, it turned out UDP would be the first choice for two reasons: a) better network performance and b) better coexistence with firewalls/NATs.

The suggestion I followed at that time was to configure OpenVPN to use an UDP channel and in case of connection/performance issue switch to TCP. you can give it a try changing the line

```
proto tcp
```

to

```
proto udp
```

on both client & server configuration and restart the server. (you can check the change was taken at server level running "netstat -a ¦ grep 433" and check UDP is listed in the first column).

Re. the socket: regardless the protocol (UDP/TCP), you will always see one socket starting from client directed to server on VPN port.

Also, try to increase log verbosity on the server, maybe you can get extra info on why connection is being dropped, even if the fact the connection seems to be dropped on both end most likely means there's a firewall dropping it...

Another thing you can try is to set up an HTTP/SOCKS proxy and tunnel the VPN traffic trough it.

----------

