Hi there,

The situation: Using TUN, connecting to the VPN where the network is
192.168.1.0-255. TUN gets 10.8.0.X IP address. What happens is that if I am
connected directly to the 192.168.X.X network via wifi the routing table
consists of appropriate entries. Then I disconnect and connect for example
via mobile carrier to the internet and open VPN to the same network
Tunnelblick connects and in the log I see this:

/Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh
-m -w -d -f -atADGNWradsgnw tun0 1500 1542 10.8.0.6 10.8.0.5 init
route: writing to routing socket: File exists
add net 192.168.1.0: gateway 10.8.0.5: File exists
add net 10.8.0.0: gateway 10.8.0.5
add net 10.8.0.1: gateway 10.8.0.5
2012-11-18 16:53:38 *Tunnelblick client.up.tunnelblick.sh: No network
configuration changes need to be made.

This results in the network 192.168.X.X not accessible because the routing
entry wants to route all traffic via a different interface (the one that
was originally connected by - wifi) rather through the tun interface. At
least this is where I see the problem. In my opinion the routing entry
should be 192.168.1 via tun0 and not through en0.

Is this up to Tunnelblick to properly recreate routing entries when
(dis)connecting? Perhaps I have something badly configured in orted to do
this?

The routing table:

Internet:

Destination        Gateway            Flags        Refs      Use   Netif
Expire

default            192.168.1.1        UGSc           31        0     en0

10.8/24            10.8.0.5           UGSc            0        0    tun0

10.8.0.1/32        10.8.0.5           UGSc            0        0    tun0

10.8.0.5           10.8.0.6           UH              2        0    tun0

127                127.0.0.1          UCS             0        0     lo0

127.0.0.1          127.0.0.1          UH              3      640     lo0

169.254            link#4             UCS             0        0     en0

192.168.1          link#4             UCS             1        0     en0

192.168.1.1        0:27:19:1a:30:8e   UHLWIir        32      294     en0  
1192

192.168.1.102      127.0.0.1          UHS             0        0     lo0

*If you are having a problem with Tunnelblick, please include the following
**with your question.*

   - *the entire contents of the Tunnelblick log; and*
   - *the contents of your configuration file*

*Be sure to X out any sensitive information such as server IP addresses*.

To get the Tunnelblick log on the Clipboard so you can paste it into an
email:

   1. Click the Tunnelblick icon
   2. Click "VPN Details…"
   3. Select the "Configurations" panel if it is not already selected
   4. Select the configuration whose file you want to look at in the list
   on the left
   5. Select the "Log" tab if it is not already selected
   6. Click "Copy Log to Clipboard"

To put the contents of your configuration file on the Clipboard so you can
paste it into an email, open it in TextEdit as follows:

   1. Click the Tunnelblick icon
   2. Click "VPN Details…"
   3. Select the "Configurations" panel if it is not already selected
   4. Select the configuration whose file you want to look at in the list
   on the left
   5. Click the little "gear" icon at the bottom of the list on the left
   6. Select "Edit OpenVPN Configuration File…" (or possibly "Examine
   OpenVPN Configuration File…").

In TextEdit you can Edit : Select All and then Edit : Copy to get the
contents of the configuration file put into the clipboard.
 On Sun, Nov 18, 2012 at 11:16 AM, Magovec <mago...@gmail.com> wrote:

I think I managed to figure this out. It was strange coincidence that
happened.

The network I was connecting to is 192.168.1.X. I was by coincidence
connected to a wifi in a cafe and had an address of 193.168.1.105. So when
I connected to the VPN the tun0 interface got 10.8.0.5 and tunnelblick
tried to add a routing entry to route all traffic to 192.168.1.X network
via tun0 interface but there was already an entry because wifi interface
was connected to the internet via the same network as I have my VPN
configured to. This obviously failed.

So the problem is that my VPN and the network in the cafe was configured to
the same address range. If this happens the connections(routing) is not
working.

Jiri

In such situations, OpenVPN puts a warning in the log that says there are
conflicting subnets.

Really? There was not anything in the log except:

route: writing to routing socket: File exists
add net 192.168.1.0: gateway 10.8.0.5: File exists

IMHO the problem is that the tun interface is configured by default to
obtain addresses from 10.8.0.X network range (from the server side) so the
interface got this address without a problem but the routing entry then was

add net 192.168.1.0: gateway 10.8.0.5: File exists

which was the conflicting one. The problem was not in setting up the
address of the interface but adding a proper route rule. I would say that
this is improper configuration which happened by coincidence having the
same C class network both in VPN internal network so as in the physical
network the machine was sitting in while connecting to the VPN.

Jiri

Dne pondělí, 19. listopadu 2012 13:34:45 UTC+1 jkbull...gmail.com napsal(a):