search

xingplus / tunnelblick

Automatically exported from code.google.com/p/tunnelblick
0 stars 0 forks source link

no buffer space available #44

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
reboot, change of location

What is the expected output? What do you see instead?
Instad of an established connection, there will be no connection established 
and until a reboot, the 
only message you get if you do a ping or try to connect is "no buffer space 
available"

What version of the product are you using? On what operating system?
3.0b9 / latest os x on a intel macbook pro

Please provide any additional information below.

Original issue reported on code.google.com by florian.wahl on 28 Oct 2008 at 7:53

GoogleCodeExporter commented 9 years ago 
These guys have the same problem (website is in german)
http://www.macuser.de/forum/showthread.php?t=171514

Original comment by florian.wahl on 28 Oct 2008 at 7:53

GoogleCodeExporter commented 9 years ago 
I'm in contact with the OpenVPN author about this. That's a problem that mostly 
seems to concern FreeBSD and 
derived operating systems. We're having trouble reliably reproducing the issue 
though. If anyone knows a 
reliable way to reproduce the issue, plz tell!

Original comment by angelol...@gmail.com on 19 Nov 2008 at 3:01

GoogleCodeExporter commented 9 years ago 
This happened here when the IT began to push a route to our perimetral servers 
(with public IPs) through the 
VPN. The problem is that OpenVPN server was among them, so they created a 
routing loop. It is a config. fault, 
not OpenVPN's.

Original comment by elvis.pf...@gmail.com on 3 Dec 2008 at 5:41

GoogleCodeExporter commented 9 years ago 
I have configured an OpenVPN server using the ldap authentication plugin
(http://code.google.com/p/openvpn-auth-ldap/) that is running on a CentOS 5.x 
host.

I am successfully able to connect from my Fedora 11 laptop, using the 
NetworkManager
OpenVPN plugin, and access resources behind the VPN server.

However, when I try connecting to the same VPN from OS X (using TunnelBlick), it
connects OK, but then a torrent of "no buffer space available" messages are 
output to
the application log.

Attempting to ping a network resource behind the VPN results in this message 
being
printed to the console.

I wondered if there's an issue with the TUN/TAP implementation here?

If you need any additional information, please just let me know what I should 
test
and what output you require.

Original comment by peter.gr...@gmail.com on 2 Sep 2009 at 1:37

GoogleCodeExporter commented 9 years ago 
What version of OS X and Tunnelblick are you using?
On an Intel or PPC Mac?
Are you using the "Set nameserver" checkbox?
Do you have DHCP or manual network settings?
Are you connecting your Mac from the same physical network as you are 
connecting your Fedora 11 laptop?
Can you post your config file and OpenVPN log (X out any sensitive IP addresses 
first)?

Original comment by jkbull...@gmail.com on 2 Sep 2009 at 10:25

GoogleCodeExporter commented 9 years ago 
In answer to your questions:

OS X Version 10.5.8
Tunnelblick Version 3.0b16 build 575 (OpenVPN 2.1_rc19)
Intel Macbook Pro
Set nameserver is _not_ checked.
Using DHCP
The Fedora laptop and MacBook are the same machine, just dual booting between 
the two operating systems. 
I am connected to the same ethernet cable when attempting to connect to the 
OpenVPN server.

Please find attached my config and logs.

Shout if you need any further info! :)

Cheers,

Pete

Original comment by peter.gr...@gmail.com on 3 Sep 2009 at 10:14

Attachments:

GoogleCodeExporter commented 9 years ago 
The only (slightly) unusual thing I see is the "auth-user-pass".

Not using "Set nameserver" means that you will continue to use whatever DNS 
your DHCP provided, even when 
the tunnel is open. That may be what you want, but it is easy to check if 
that's the problem.

If you can, try it:
1. With "Set nameserver" checked,
2. With the "auth-user-pass" removed (just for testing purposes), and
3. With both.

You might also try an older version of Tunnelblick. I suggest trying version 
3.0b10, which you can download 
from
http://code.google.com/p/tunnelblick/downloads/list

You can just put it on your Desktop and run it from there, without disturbing 
your copy of version 3.0b16, 
which I assume is in Applications. Be sure to quit from the old version of 
Tunnelblick first.

Original comment by jkbull...@gmail.com on 3 Sep 2009 at 11:00

GoogleCodeExporter commented 9 years ago 
OK,

Tried all your suggestions - still no dice.

After removing the "auth-user-pass" directive and updating the server 
configuration to reflect this, I ensured 
that my Linux OS would still connect, which it did.

I pulled the same certificate and key into OS X in order to try the above, but 
I still get the write UDPv4: No 
buffer space available (code=55)" error. :(

Let me know what else I can try for you.

Thank you,

Peter

Original comment by peter.gr...@gmail.com on 4 Sep 2009 at 3:58

GoogleCodeExporter commented 9 years ago 
I just noticed is that you aren't specifying any encryption (you commented out 
the "cipher BF-CBC" in the config 
file. I don't see how that could have anything to do with it, especially the 
error you're getting, which usually 
indicates a routing loop, but it should be easy to check.

Can you verify that the routing commands in your log make sense? (Since they're 
obfuscated, I can't judge that.) 
Perhaps OpenVPN is setting up the routing incorrectly.

Original comment by jkbull...@gmail.com on 5 Sep 2009 at 3:37

GoogleCodeExporter commented 9 years ago 
I have since specified the encryption on both ends of the tunnel, with the same 
result.

I'll have to wait until Monday to confirm the routing commands, when I'm back 
in the
office.

Thanks for all your help so far guys. :)

Original comment by peter.gr...@gmail.com on 5 Sep 2009 at 10:48

GoogleCodeExporter commented 9 years ago 
Problem is fixed!!! Finally got around to checking the routing - I think the 
problem
was caused because the OpenVPN server was pushing down a route for the subnet 
where
the server was located.

Odd that the Linux client wasn't affected in the same way, but hey - at least I 
can
push this solution out to all the Mac users here at work now! :)

Thanks for all your help guys.

Original comment by peter.gr...@gmail.com on 18 Sep 2009 at 3:27

GoogleCodeExporter commented 9 years ago 
When you say problem "fixed", you mean "worked around". I want to push a route 
for my
whole network (which obviously includes the VPN server), but if I have a route 
for
the VPN server it should take precedence. Why should I have to push lots of 
smaller
subnets just to avoid this problem?

Interestingly I can get the client (once connected) to work by hand by manually
pulling out the big subnet route and re-adding it. So I guess there's a weird
interaction between openvpn and *BSD (including MacOS). Not a Tunnelblick bug.

Original comment by berna...@gmail.com on 14 Dec 2009 at 10:16

GoogleCodeExporter commented 9 years ago

Original comment by jkbull...@gmail.com on 4 Jun 2010 at 4:35

GoogleCodeExporter commented 9 years ago 
This issue still exists. I regularly get TunnelBlick disconnects and "no buffer 
space available" when e.g. sending a ping or two to see if I have connectivity.

This normally happens after "a while"; i.e. perhaps half a day of use. 

Killing TunnelBlick (which takes a while before it responds) and restarting it 
fixes the issue.

Tor

Original comment by tor.houg...@gmail.com on 15 Mar 2011 at 2:58

GoogleCodeExporter commented 9 years ago 
The next time this happens (before killing Tunnelblick) please open 
/Applications/Utilities/Activity Monitor.app and see how much memory 
Tunnelblick is using (both "real" and "virtual" memory) and report back to this 
Issue.

When you say "takes a while before it responds", do you mean one or two 
seconds, ten, thirty?

How are you "killing" Tunnelblick? By quitting from the Tunnelblick menu, or is 
it non-responsive and you have to use some other method?

Thanks.

Original comment by jkbull...@gmail.com on 15 Mar 2011 at 3:20

GoogleCodeExporter commented 9 years ago 
I had this problem and I can confirm is indeed a configuration problem.

We create OpenVPN servers in a lab, and we create it with:
push "redirect-gateway local def1"

So we can test on the same lab.

When we moved out the server to the proper location our clients were having 
that buffer trouble... because we forgot to take off the "local" setting. Like 
this:
push "redirect-gateway def1"

I hope this helps other people that are new to OpenVPN, like me.

Original comment by gmco...@gmail.com on 29 Aug 2012 at 5:12

GoogleCodeExporter commented 9 years ago 
Resolved!! Here we were unable to connect using imac or macbook, then we 
commented out one line on /usr/local/etc/openvpn/openvpn.conf:
#push "route 123.123.123.100  255.255.255.0"

/usr/local/etc/openvpn # cat openvpn.conf
---------------------------------------
# Specify device
dev tun
port 1194
# Server and client IP and Pool
server 192.168.123.0 255.255.255.0

ifconfig-pool-persist ipp.txt

# Certificates for VPN Authentication
ca /usr/local/share/easy-rsa/keys/ca.crt

cert  /usr/local/share/easy-rsa/keys/myserver.crt
key /usr/local/share/easy-rsa/keys/myserver.key
dh /usr/local/share/easy-rsa/keys/dh1024.pem

# Routes to push to the client
## commented out because of errors on imac and macbook
##push "route 123.123.123.123  255.255.255.0"

# Use compression on the VPN link
comp-lzo

# Make the link more resistant to connection failures
keepalive 10 60
ping-timer-rem
persist-tun
persist-key

# Run OpenVPN as a daemon and drop privileges to user/group nobody user nobody
group nobody
daemon
----------------------

Original comment by fmshighc...@gmail.com on 22 Apr 2014 at 6:44