route generates "No buffer space available (code=55)"

[viktorf768]

The goal is, routing requests for the networkadress 188.118.0.0 (255.255.0.0) over the VPN Net, to the VPN Gateway.
All other traffic should be routed like before Client started.

Routing entries befor Tunnelblick client starts:

Code: Select all

Destination        Gateway            Flags        Refs      Use   Netif Expire
default            mehvi-fw-tel001.lo UGSc            5        3     en0
127                localhost          UCS             0        0     lo0
localhost          localhost          UH              2      741     lo0
169.254            link#4             UCS             0        0     en0
192.168.104        link#4             UCS             2        0     en0
mehvi-fw-tel001.lo 0:d:b9:21:d2:8     UHLWIir         6      605     en0    332
192.168.104.197    localhost          UHS             0        0     lo0
192.168.104.255    ff:ff:ff:ff:ff:ff  UHLWbI          0      111     en0

After client starts with parameter "redirect-gateway def1" without any "route" parameter (everything works, but everything is routed through VPN net, cause of the entry with Destination 0/1:

Code: Select all

Destination        Gateway            Flags        Refs      Use   Netif Expire
0/1                192.176.0.5        UGSc            9        0    tun0
default            mehvi-fw-tel001.lo UGSc            1        3     en0
127                localhost          UCS             0        0     lo0
localhost          localhost          UH              3      696     lo0
128.0/1            192.176.0.5        UGSc            2        0    tun0
169.254            link#4             UCS             0        0     en0
188.118.228.2/32   mehvi-fw-tel001.lo UGSc            1        0     en0
192.168.104        link#4             UCS             2        0     en0
mehvi-fw-tel001.lo 0:d:b9:21:d2:8     UHLWIir         3      571     en0    369
192.168.104.197    localhost          UHS             1        0     lo0
192.168.104.255    ff:ff:ff:ff:ff:ff  UHLWbI          0       96     en0
192.176.0.1/32     192.176.0.5        UGSc            0        0    tun0
192.176.0.5        192.176.0.6        UHr            14        0    tun0

After client starts without parameter "redirect-gateway def1" and instead "route 188.118.0.0 255.255.0.0", the routing table looks like the following and the error "No buffer space available" is raised. There is a routing loop, but i do not understand how to solve the problem. When routing everything to the Gateway 192.176.0.5 (which caused the "redirect-gateway def1" parameter), why is a loop created if the entry is changed to route just network 188.118. to the Gateway 192.176.0.5 ??? This is less address space than before and therefor should not create a loop:

Code: Select all

Destination        Gateway            Flags        Refs      Use   Netif Expire
default            mehvi-fw-tel001.lo UGSc            7        3     en0
127                localhost          UCS             0        0     lo0
localhost          localhost          UH              3      779     lo0
169.254            link#4             UCS             0        0     en0
188.118            192.176.0.5        UGSc            0        0    tun0
192.168.104        link#4             UCS             1        0     en0
mehvi-fw-tel001.lo 0:d:b9:21:d2:8     UHLWIir         7      641     en0   1189
192.168.104.197    localhost          UHS             1        0     lo0
192.176.0.1/32     192.176.0.5        UGSc            0        0    tun0
192.176.0.5        192.176.0.6        UH              2        0    tun0

1) Why does the Entriy with Target 188.118 (instead of 0/1) now rase the exception?
2) What has to be changed to reach the goal.
3) Shouldn´t Tunnelblick create the correct routing entry for the given goal "route 118.118.0.255.255.0.0" without creating a loop?. Isn´t this an error in Tunnelblick?
Isn´t it wherefore the parameter entry stands, or what do i misunderstand?

Thanks.

[viktorf768]

I found the following answer and solution.
I suppose (please verify !) a bug, when client and server use the UDP Protocol.
As UDP is given as DEFAULT in the .CONF configuration file, i tried every configuration with UDP, as it is given as DEFAULT is supposed that the given DEFAULT should work.
At first i supposed that the described problem was caused by my own configuration failure, that i caused a routing loop.

Finally it seems, that i did everything correct, but a bug is in the UDP routing (?)inside(?) OpenVPN.

The goal was to route VPN client requests for a given extern network (f.i. 188.118.0.0 (255.255.0.0) )over the Gateway of the LAN of the VPN Server (f.i. to get the extern static IP of the Gateway of the LAN where the VPN Server is running). Important in this case is, that all the other traffic to other network addresses should be routed to the origin LAN Gateway where the VPN Client is connected to.
This is functional, when the VPN Server is configured as a router (enabled forwarding and NAT). It will then forward to the next Gateway on the LAN where the Server is connected to.
The effect is: VPN Client requests to the network 188.118.0.0 get the return address of the gateway in the LAN of the server.
VPN Client requests to all other networks get the return address of the originally configured gateway of the LAN of the client.

My correct configuration of either client.conf or server.conf is:
1.) removing the paremter "redirect-gateway def1" (either in client.conf or as "push" in server.conf depending on wherever it has been set)
2.) adding "route 188.118.0.0 255.255.0.0" (either in client.conf or as "push" in server.conf)

If using the network protocol UDP (defined by the .conf parameter "proto udp") the Exception "No buffer space available (code=55)" is raised, an network connection does not work. It took me a very long time and hard work, cause i tried to understand where and if a network loop exists. This was one possible hint. Annoying is, that UDP is given by default configuration.

If using the network protocol TCP (defined by the .conf parameter "proto tcp") no Exception will be rased, and everything will work as expected !!!

Can anyone verify and confirm that this is a bug which has to be corrected?

It will help to avoid a lot of senseless work !!!
I hope this information can be released in many places, cause until now i could not find this relation and solution to this problem.
In this case the OS of either VPN Client and VPN Server is OS X 10.8.2

Thanks.