| View previous topic :: View next topic |
| Author |
Message |
fuzion
n00b
Joined: 19 Feb 2003
Posts: 56
|
 Posted: Thu Jan 05, 2012 7:15 am Post subject: OpenVPN through port 443 is not working (Windows -> Gento |
 |
|
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
PID packet_id_free (once)
SIGTERM[hard,init_instance] received, process exiting |
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
xxx.xxx.xxx.xxx:51722 Connection reset, restarting [0]
xxx.xxx.xxx.xxx:51722 SIGUSR1[soft,connection-reset] received, client-instance restarting
TCP/UDP: Closing socket
|
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
remote xxx.xxx.xxx.xxx 443
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
comp-lzo
verb 7
|
Server config:
| Quote: | port 443
proto tcp
dev tun
ca privnet/ca.crt
cert privnet/server.crt
key privnet/server.key
dh privnet/dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3
client-to-client
|
I'm using this HOWTO as a guideline:
http://en.gentoo-wiki.com/wiki/OpenVPN |
|
| Back to top |
|
 |
Strupniveral
n00b
Joined: 09 Apr 2004
Posts: 42
|
| Posted: Thu Jan 05, 2012 8:46 am Post subject: |
|
|
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 |
|
| Back to top |
|
|
fuzion
n00b
Joined: 19 Feb 2003
Posts: 56
|
| Posted: Fri Jan 06, 2012 12:37 am Post subject: no luck yet |
|
|
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). |
|
| Back to top |
|
|
fuzion
n00b
Joined: 19 Feb 2003
Posts: 56
|
| Posted: Fri Jan 06, 2012 12:40 am Post subject: port questions |
|
|
| 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). |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 23091
|
| Posted: Fri Jan 06, 2012 3:25 am Post subject: Re: no luck yet |
|
|
| 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. |
|
| Back to top |
|
|
fuzion
n00b
Joined: 19 Feb 2003
Posts: 56
|
| Posted: Fri Jan 06, 2012 5:10 am Post subject: looks like just one connection |
|
|
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. |
|
| Back to top |
|
|
Strupniveral
n00b
Joined: 09 Apr 2004
Posts: 42
|
| Posted: Fri Jan 06, 2012 8:30 am Post subject: |
|
|
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
to
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. |
|
| Back to top |
|
|
|
Networking & Security
