Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I am trying to get my VPN connection to only route network traffic related to my workplace through the VPN connection and any other traffic through my Wi-Fi connection.

If I have my Wi-Fi at the top of the service order list I can not access my work network with VPN connected and when my VPN connection is at the top I can not access anything other than my work network.

Could the problem be because my works DNS server resolves internet addresses but does not allow connections through their router to internet bound addresses?

My local router/name server is : 10.10.10.3 Remote VPN name-server is : 10.1.1.88

The output from scutil --dns is as follows, I find it odd that the VPN nameserver is showing up in resolver #1

DNS configuration

resolver #1
  search domain[0] : home-domain.com
  nameserver[0] : 10.1.1.88
  order    : 100000

resolver #2
  nameserver[0] : 10.10.10.3
  order    : 200000

resolver #3
  domain   : local
  options  : mdns
  timeout  : 5
  order    : 300000

resolver #4
  domain   : 254.169.in-addr.arpa
  options  : mdns
  timeout  : 5
  order    : 300200

resolver #5
  domain   : 8.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  order    : 300400

resolver #6
  domain   : 9.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  order    : 300600

resolver #7
  domain   : a.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  order    : 300800

resolver #8
  domain   : b.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  order    : 301000

DNS configuration (for scoped queries)

resolver #1
  search domain[0] : home-domain.com
  nameserver[0] : 10.10.10.3
  if_index : 5 (en1)
  flags    : Scoped

resolver #2
  search domain[0] : vpn-domain.com
  nameserver[0] : 10.1.1.88
  if_index : 8 (ppp0)
  flags    : Scoped

Looking at my netstat -r reveals the following, I might note here that there is no route for 10.1.. which is where most of my destinations are (10.1.7.* is just the VPN connections).

Destination        Gateway            Flags        Refs      Use   Netif Expire
default            home.gateway       UGSc           17        0     en1
default            119.225.149.174    UGScI           2        0    ppp0
10.1.7/24          ppp0               USc             0        0    ppp0
10.10.10/24        link#5             UCS             8        0     en1
home.gateway       0:4:ed:d:ed:b9     UHLWIi         40    58916     en1   1192
brettsmac.localdom localhost          UHS             0     1704     lo0
10.10.10.255       ff:ff:ff:ff:ff:ff  UHLWbI          0        2     en1
119.225.149.174    home.gateway       UGHS            3    34401     en1
127                localhost          UCS             0        0     lo0
localhost          localhost          UH              8  1672518     lo0
169.254            link#5             UCS             0        0     en1

UPDATE: Talking to our infrastructure team have told me how to solve this for windows 7; Under the "Advanced TCP/IP Settings" tab of the VPN connection we are to un-tick the option "Use default gateway on remote network", is there a similar setting in OSX?

share|improve this question

1 Answer 1

Move the VPN network to the top of your service order list. That will ensure you're using the work VPN's nameserver, which you'll need to resolve work network addresses. Now, presuming that your work VPN does not break name resolving for the wider Internet (i.e., it does filtering by blocking routing instead of DNS resolution), then all that remains is to fix routing to the internet.

Let's look at the first four entries of your routing table:

  1. first line sends all traffic to your home router.
  2. second line sends all traffic to your VPN tunnel.
  3. third line sends work address traffic (10.1.7/24) to the VPN.
  4. fourth line sends local traffic (10.10.10/24) to your router.

Assuming the network addresses in (3) & (4) do describe your work network and your local network, as I am guessing, then those lines handle all the of the thru-the-work-vpn routing that you want done. So what remains is just to be sure that default traffic goes to your router not the VPN.

It looks like (1) should do this, and I'd guess this line is present even before your start the VPN. So it seems that (2) is overriding it. (They are obviously in conflict, and who knows what the override logic is?) So the solution is, remove (2) or alter it so that it's the same as (1).

I would try:

sudo route change -net default home.gateway

or

sudo route change -net default 0:4:ed:d:ed:b9

or

sudo route change -net -interface default 0:4:ed:d:ed:b9

or

sudo route delete default
sudo route add -net default home.gatway

etc..

share|improve this answer
    
This does not work and I think I've finally discovered why. When sending a request through the VPN connection, rather than it rejecting the rout and sending something back to let me know, it just drops the request so my connection has no way to know that it failed. What can my infrastructure guys do to stop this behaviour and send some sort of noroute packet back? –  Brett Ryan Oct 24 '13 at 1:34

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.