Deleting the routing table entries when connecting

482 views
Skip to first unread message

Magovec

unread,
Nov 18, 2012, 11:16:05 AM11/18/12
to tunnelbli...@googlegroups.com
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

Jonathan K. Bullard

unread,
Nov 18, 2012, 3:10:00 PM11/18/12
to tunnelbli...@googlegroups.com, mag...@gmail.com
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.

--
You received this message because you are subscribed to the Google Groups "tunnelblick-discuss" group.
To view this discussion on the web visit https://groups.google.com/d/msg/tunnelblick-discuss/-/U7G2G6ReOxkJ.
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.


Magovec

unread,
Nov 19, 2012, 6:23:39 AM11/19/12
to tunnelbli...@googlegroups.com, mag...@gmail.com
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

Jonathan K. Bullard

unread,
Nov 19, 2012, 7:34:04 AM11/19/12
to tunnelbli...@googlegroups.com, mag...@gmail.com
In such situations, OpenVPN puts a warning in the log that says there are conflicting subnets.

--
You received this message because you are subscribed to the Google Groups "tunnelblick-discuss" group.

Magovec

unread,
Nov 19, 2012, 8:38:03 AM11/19/12
to tunnelbli...@googlegroups.com, mag...@gmail.com
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):
Reply all
Reply to author
Forward
0 new messages