Problem pushing multiple routes

1,523 views
Skip to first unread message

Stephen Cristol

unread,
Dec 26, 2010, 4:40:26 PM12/26/10
to tunnelblick-discuss
I added a second route to my openvpn server configuration changing it
from:

push "route 192.168.4.0 255.255.255.0"

to:

push "route 192.168.3.0 255.255.255.0"
push "route 192.168.4.0 255.255.255.0"

This caused Tunnelblick to appear to hang while filling its log with
more than 1500 lines/sec of:

write UDPv4: No buffer space available (code=55)

Concurrently, /var/log/system.log filled with messages like:

Dec 26 15:34:27 turing kernel[0]: dlil_output: output error retval
= 37
Dec 26 15:34:29: --- last message repeated 105 times ---

I observed this behavior with Tunnelblick 3.1, 3.1.1, and 3.1.2.
Removing the second static route from the server configuration
restored Tunnelblick to its usual state of happiness.

Sorry I couldn't capture more from the log, but the Tunnelblick GUI
became unresponsive (beachball) when this happened. I had to kill it
from the command line. It looks as though it was still functioning
throughout as it wrote this in system.log:

Dec 26 15:34:31 turing [0x0-0x41041].com.openvpn.tunnelblick[520]: 1
openvpn processes killed
Dec 26 15:34:31 turing [0x0-0x41041].com.openvpn.tunnelblick[520]:
signal 15 caught!
Dec 26 15:34:31 turing [0x0-0x41041].com.openvpn.tunnelblick[520]:
Received fatal signal. Cleaning up

Jonathan K. Bullard

unread,
Dec 26, 2010, 4:50:47 PM12/26/10
to tunnelbli...@googlegroups.com
I don't mean to just "pass the buck", but Tunnelblick itself has little to do with the routing -- OpenVPN does that sort of stuff. So I suggest trying this with Tunnelblick version 3.0 and version 3.0b10; they each use different versions of OpenPVN.

Also, you might be able to get more of the log and prevent the beachballing if you specify "mute 5" in the client configuration file. That should cause OpenVPN to log at most 5 consecutive messages in the same category.

--
You received this message because you are subscribed to the Google Groups "tunnelblick-discuss" group.
To post to this group, send email to tunnelbli...@googlegroups.com.
To unsubscribe from this group, send email to tunnelblick-dis...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/tunnelblick-discuss?hl=en.


Stephen Cristol

unread,
Dec 26, 2010, 5:53:21 PM12/26/10
to tunnelblick-discuss
Jonathan,

Thanks for those suggestions. It looks like this is an openvpn issue.
I tried adding the route manually from the command line after I
established a VPN connection:

$ sudo route add -net 192.168.3.0/24 10.8.0.5
add net 192.168.3.0: gateway 10.8.0.5
$

This sent Tunnelblick into the same log filling mode.

S

Stephen Cristol

unread,
Jan 29, 2011, 11:09:34 AM1/29/11
to tunnelblick-discuss
Update:

I'm now using tunnelblick 3.1.4. I used a suggestion by JKB in a
thread titled "Add static routes after connecting to a vpn" on
2011-01-21. Rather than pushing a second route from the server, I
added it from the client configuration as:

route 192.168.3.0 255.255.255.0

This is working for me. Not sure if this avoids the issue I described
above or works because 3.1.4 uses openvpn 2.1.4 (sorry, I don't recall
the version of openvpn used with tunnelblick 3.1 - 3.1.2).

jkbull...gmail.com

unread,
Jan 29, 2011, 12:01:47 PM1/29/11
to tunnelbli...@googlegroups.com
Tunnelblick 3.1, 3.1.1, 3.1.2, 3.1.3, and 3.1.4 all use OpenVPN 2.1.4, so that isn't it.

I have another idea, though. The OpenVPN man page says to enclose the argument to the --push option in double-quotes. That makes sense when it is being used as a command line option when starting OpenVPN.

However, perhaps the double-quotes aren't necessary (and cause this problem) when "push" is in a configuration file, and instead of
push "route 192.168.3.0 255.255.255.0" 
push "route 192.168.4.0 255.255.255.0"
you should try
push route 192.168.3.0 255.255.255.0 
push route 192.168.4.0 255.255.255.0
in the server configuration file.

Worth a try if you have a chance. If it works without the double-quotes, the OpenVPN documentation should be clarified.
Reply all
Reply to author
Forward
0 new messages