Tunneblick listening Port needs issues

[thebi...@gmail.com]

Gentlemen,

thanks for tunnelblick, a great program for open vpn. 

I have finally managed to set it up. My organisation has a restrictive firewall policy, which is why I need tunnelblick to listen on certain ports only. If I am not mistaken, 

2014-07-21 14:23:09 OpenVPN 2.2.1 i386-apple-darwin [SSL] [LZO2] [PKCS11] [eurephia] built on Jul 17 2014
2014-07-21 14:23:09 MANAGEMENT: TCP Socket listening on 127.0.0.1:1337
2014-07-21 14:23:09 Need hold release from management interface, waiting...
2014-07-21 14:23:09 MANAGEMENT: Client connected from 127.0.0.1:1337

means that Tunnelblick opens a port on localhost (1337) to talk to the openvpn server. I need this port to be a different port, because pretty much any port, that one included, is blocked. 

Is there a way to do this?

PS: The VPN connection works, I connected it with 4G and it worked great. So I am assuming this is the problem I am having. 

Any Suggestions? 

Regards, 

[jkbull...gmail.com]

I don't think the problem is what you think it is. I remember being confused about this when I first started using Tunnelblick myself. I'll try to explain:

First, make sure you understand that Tunnelblick itself doesn't implement the VPN. What Tunnelblick does is create and manage an OpenVPN process which implements the VPN. If multiple VPNs are connected, Tunnelblick will manage an OpenVPN process for each one.

It is the OpenVPN process that manages a VPN, sending all traffic for that VPN to the OpenVPN server using a particular protocol to a particular IP address and port on that OpenVPN server.

The confusing part is that Tunnelblick communicates with each OpenVPN processes through a port on localhost.

So there are:

• Ports on localhost (that is, the computer running Tunnelblick) that Tunnelblick uses to communicate with OpenVPN processes that it manages; and
  
• Ports on the OpenVPN server that are used to send data on the VPN.
  

It is this second type of port that is being blocked by your organization's firewall.

(Localhost ports are used dynamically for several purposes on OS X, so to communicate with a new OpenVPN process Tunnelblick uses the lowest-numbered available port at that moment. You can't change that behavior very easily but that's OK because I don't think that is the port you are having problems with.)

Changing the port number that OpenVPN uses is easy, too, if you control both the OpenVPN client (Tunnelblick) and the OpenVPN server. You set the port on them by modifying the OpenVPN configuration file for each one. By default, OpenVPN uses the UDP protocol on port #1194. So if your client's OpenVPN configuration has

remote my-server

or

remote my-server 1194

then your client will try to communicate with port 1194 of the OpenVPN server "my-server" using the UDP protocol.

If you change that line to (for example)

remote my-server 443 tcp

then your client will try to communicate with port 443 of the OpenVPN server "my-server" using the TCP protocol.

I chose 443 and tcp as an example because TCP port 443 is the port used on webservers for https:, so it is rarely blocked by firewalls. Another port number that isn't usually blocked by firewalls is port 80, which is the http: port. If that was blocked you couldn't surf the Internet at all.

Of course, you must set up your OpenVPN server to listen to the same port with same protocol as your client.

Typically, VPN service providers run OpenVPN servers listening to several ports, some UDP and some TCP, and offer several client configuration files, each file connecting using a different port/protocol setup. (Or sometimes a single OpenVPN configuration file will specify several server/port/protocol combinations and OpenVPN tries each one until it finds one that works.)

For more information, see the OpenVPN 2.3 man page.

[thebi...@gmail.com]

Hi, 

thank you for your answer. However, that I have done already. 

your example fits very well as I am in fact using port 80. I am going to copy/paste the extracts that I believe are relevant to your answer: 

/etc/openvpn/server.conf

# Which TCP/UDP port should OpenVPN listen on?
# If you want to run multiple OpenVPN instances
# on the same machine, use a different port
# number for each one.  You will need to
# open up this port on your firewall.
port 81
# TCP or UDP server?
;proto tcp
proto udp

So the openvpn server listens on part 81 - however, the firewall (@home) portforwards 80 (outgoing) to 81 (going into home network). 

Tunnelblicks "client.conf"

# Are we connecting to a TCP or

# UDP server?  Use the same setting as

# on the server.

;proto tcp

proto udp

# The hostname/IP and port of the server.

# You can have multiple remote entries

# to load balance between the servers.

remote home  80

;remote my-server-2 1194

As I said, in an "unfiltered" Internet using my mobile hotspot, the connection works as wanted. Just behind that firewall, it run into problems. So I am assuming the client has a port that it chooses to negotiate the connection establishment!?

This is the complete log, the public IP address was omitted.

2014-07-21 14:23:09 *Tunnelblick: Established communication with OpenVPN

2014-07-21 14:23:09 OpenVPN 2.2.1 i386-apple-darwin [SSL] [LZO2] [PKCS11] [eurephia] built on Jul 17 2014

2014-07-21 14:23:09 MANAGEMENT: TCP Socket listening on 127.0.0.1:1337

2014-07-21 14:23:09 Need hold release from management interface, waiting...

2014-07-21 14:23:09 MANAGEMENT: Client connected from 127.0.0.1:1337

2014-07-21 14:23:09 MANAGEMENT: CMD 'pid'

2014-07-21 14:23:09 MANAGEMENT: CMD 'state on'

2014-07-21 14:23:09 MANAGEMENT: CMD 'state'

2014-07-21 14:23:09 MANAGEMENT: CMD 'bytecount 1'

2014-07-21 14:23:09 MANAGEMENT: CMD 'hold release'

2014-07-21 14:23:09 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2014-07-21 14:23:09 LZO compression initialized

2014-07-21 14:23:09 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]

2014-07-21 14:23:09 Socket Buffers: R=[196724->65536] S=[9216->65536]

2014-07-21 14:23:09 MANAGEMENT: >STATE:1405945389,RESOLVE,,,

2014-07-21 14:23:09 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]

2014-07-21 14:23:09 Local Options hash (VER=V4): '41690919'

2014-07-21 14:23:09 Expected Remote Options hash (VER=V4): '530fdded'

2014-07-21 14:23:09 UDPv4 link local: [undef]

2014-07-21 14:23:09 UDPv4 link remote: PUBLIC_IP_ADDRESS:80

2014-07-21 14:23:09 MANAGEMENT: >STATE:1405945389,WAIT,,,

2014-07-21 14:23:09 *Tunnelblick: openvpnstart starting OpenVPN

2014-07-21 14:24:09 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

2014-07-21 14:24:09 TLS Error: TLS handshake failed

2014-07-21 14:24:09 TCP/UDP: Closing socket

2014-07-21 14:24:09 SIGUSR1[soft,tls-error] received, process restarting

2014-07-21 14:24:09 MANAGEMENT: >STATE:1405945449,RECONNECTING,tls-error,,

2014-07-21 14:24:10 *Tunnelblick: No 'reconnecting.sh' script to execute

2014-07-21 14:24:10 MANAGEMENT: CMD 'hold release'

2014-07-21 14:24:10 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2014-07-21 14:24:10 Re-using SSL/TLS context

2014-07-21 14:24:10 LZO compression initialized

2014-07-21 14:24:10 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]

2014-07-21 14:24:10 Socket Buffers: R=[196724->65536] S=[9216->65536]

2014-07-21 14:24:10 MANAGEMENT: >STATE:1405945450,RESOLVE,,,

2014-07-21 14:24:10 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]

2014-07-21 14:24:10 Local Options hash (VER=V4): '41690919'

2014-07-21 14:24:10 Expected Remote Options hash (VER=V4): '530fdded'

2014-07-21 14:24:10 UDPv4 link local: [undef]

2014-07-21 14:24:10 UDPv4 link remote: PUBLIC_IP_ADDRESS:80

2014-07-21 14:24:10 MANAGEMENT: >STATE:1405945450,WAIT,,,

2014-07-21 14:24:15 *Tunnelblick: Disconnecting; notification window disconnect button pressed

2014-07-21 14:24:15 *Tunnelblick: Disconnecting using 'kill'

2014-07-21 14:24:15 event_wait : Interrupted system call (code=4)

2014-07-21 14:24:15 TCP/UDP: Closing socket

2014-07-21 14:24:15 SIGTERM[hard,] received, process exiting

2014-07-21 14:24:15 MANAGEMENT: >STATE:1405945455,EXITING,SIGTERM,,

2014-07-21 14:24:15 *Tunnelblick: No 'post-disconnect.sh' script to execute

2014-07-21 14:24:15 *Tunnelblick: Expected disconnection occurred.

Any other ideas? 

[jkbull...gmail.com]

On Monday, July 21, 2014 10:15:18 AM UTC-4, thebi...@gmail.com wrote:

As I said, in an "unfiltered" Internet using my mobile hotspot, the connection works as wanted. Just behind that firewall, it run into problems. So I am assuming the client has a port that it chooses to negotiate the connection establishment!?

The port that the client uses to talk to the server is specified in the client's OpenVPN configuration file.

This:

2014-07-21 14:23:09 MANAGEMENT: TCP Socket listening on 127.0.0.1:1337

2014-07-21 14:23:09 Need hold release from management interface, waiting...

2014-07-21 14:23:09 MANAGEMENT: Client connected from 127.0.0.1:1337

shows that the port used by Tunnelblick to communicate with the OpenVPN process is working normally. It never leaves your computer and thus is not subject to your organization's firewall.

 This:

2014-07-21 14:23:09 UDPv4 link remote: PUBLIC_IP_ADDRESS:80

2014-07-21 14:23:09 MANAGEMENT: >STATE:1405945389,WAIT,,,

2014-07-21 14:24:09 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

shows that your client tried to connect to the OpenVPN server's port 80 (using UDP as indicated by your configuration files) but did not receive a response from the server.

Any other ideas?

You could try TCP and port 443.

This is really and OpenVPN question; it doesn't really have anything to do with Tunnelblick itself. You might be better off consulting OpenVPN documentation and asking OpenVPN experts:

• OpenVPN FAQ
• OpenVPN HOWTO
• OpenVPN 2.3 Man Page
• OpenVPN Documentation
• OpenVPN Users Forum
• OpenVPN Users Mailing List