And Juniper again - Split Tunnel not working properly

Question

And Juniper again - Split Tunnel not working properly

Hello, I've read everything on this site and what I've managed to find - but it seems that this exact problem is not touched anywhere, so this place is kind of my last resort (besides returning the book and switching back to windows of course =)))) and hope for help.

The issue looks very simple - when I connect to my work VPN using the Juniper Network Connect (versions below) I'm choosing the following settings:

Access mode: VPN Client
Tunnel mode: Split tunnel

and everything works fine besides the DNS names resolving. I can't open any "external" sites by their names (even www.google.com or www.apple.com) however, if I type them by IP address (e.g. 74.125.224.55 for google) - everything works fine. As well as already established connections (those were already working when the Network Connect established a VPN connection).

I've tried scutil --dns but it seems that the DNS table is Ok (I still do have my DNS on the first place and no other "surprising" findings).

So, if you could help me with this issue that would be really great!

The software versions are as following:

Mac OS X 10.6.5
Java(TM) SE Runtime Environment (build 1.6.0_22-b04-307-10M3261)
Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03-307, mixed mode)
Juniper Network Connect 6.5.0 (16207)

Apple MacBook Air, Mac OS X (10.6.5), DNS names resolving is not working in the SplitTunnel mode

Posted on Dec 14, 2010 4:21 AM

Reply

Answer 1

Dec 14, 2010 8:03 AM in response to Andrey Stukalenko

Some connection details if that will help:

Security: AES128/SHA1
Compression: LZO
Transport mode: ESP over AirPort

Reply

Answer 2

satcomer

Level 4

1,593 points

Dec 14, 2010 3:35 PM in response to Andrey Stukalenko

In the VPN settings (System Preferences->Network pane)if you highlight the VPN and then in the right hand pane click on the 'Advanced' button. In the drop-down click on the DNS tab and see if the VPN server is dishing out an IP. If it isn't in there you can add DNS servers manually.

Reply

Answer 3

Dec 14, 2010 8:31 PM in response to satcomer

Hello,

The problem is that I don't have a VPN entry in the connections list. Only the AirPort connection.

I'm using the java-based Juniper Connect Client, that is launched automatically by visiting connect.<domain>.com and entering my username / password. On the connection page I'm choosing Access mode: VPN Client and Tunnel mode: "Split Tunnel".

Reply

Answer 4

Dec 15, 2010 2:53 AM in response to Andrey Stukalenko

Andrey, Interesting Post.

It would appear that your Juniper VPN client uses the SSL over TCP/UDP connection, where connectivity to your company is routed via the SSL tunnel. - Whether the Tunnel is pushing all your traffic via the tunnel or not, i"m not 100% - although the 'split tunnel' infers that it is not.

I have very similar setup but using another SSL based VPN termination product, but I get to manage the DNS configuration locally so my DNS still resolves.. i did a quick google and found this

http://kb.juniper.net/InfoCenter/index?page=content&id=KB16461&actp=RSS

IF Your Internet provider does DNS forwarding, then you may fall victim of this issue. (i'm not familiar with the exact configuration of the Juniper VPN SSL boxes myself but knowing what I do know, is that either your DNS requests are being blocked by your VPN or something funky is going on.

What I would do is this.

1. Confirm your internet is working via your mac without issues (I presume it is since you've probably posted here 🙂 )

run a terminal session on your mac and make a note of /etc/resolv.conf.. it is the DNS resolver file. I just want you to make a note of it - the same setting is obtained via System Preferences - Network - Advanced - DNS - The current DNS server being used BEFORE your VPN will be present in the left hand box.

2. take a note of your current network routing via default gw and your local lan. (Im presuming your setup is common using a router and private 192.168.x.x addressing and your router is doing NAT *Network address translation* to your ADSL/Cable connection.

you can do this via TCP/IP Tab.

*using the CMD-SHIFT-4 button you can take a selection screenshot which saves it on your desktop as a png/jpg.

also netstat -nr - in Terminal should show something like this

starbase:~ admin$ netstat -nr|grep 192.168
default 192.168.72.2 UGSc 6 2 en0
192.168.72 link#4 UCS 6 0 en0

3. Connect to your VPN server.

Then retrace steps 1 and 2 and make a note of what settings have changed. . I suspect the DNS servers which the vpn server has changed in OSX, will have been via the Java VPN tunnel app.

Make a note of what's changed and report back 🙂

Dan

Reply

Answer 5

Dec 15, 2010 4:03 PM in response to MisterHugh

Hello. Appreciate your help.

Contents of the /etc/resolv.conf are:
domain hsd1.wa.comcast.net.
nameserver 192.168.0.1

Network preferences pane reflects the very same information.

The results of netstat -nf are as following:

Routing tables

Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.0.1 UGSc 2 0 en0
127 127.0.0.1 UCS 0 0 lo0
127.0.0.1 127.0.0.1 UH 0 0 lo0
169.254 link#4 UCS 0 0 en0
192.168.0 link#4 UCS 2 0 en0
192.168.0.1 0:18:e7:c6:6e:c2 UHLWI 14 42 en0 1175
192.168.0.150 127.0.0.1 UHS 0 0 lo0
192.168.0.255 ff:ff:ff:ff:ff:ff UHLWbI 0 6 en0

plus some Internet6 records, but I don't think that it counts =)

That's all before the VPN connection is established.

After I establish the VPN connection (btw, I do not have the VPN item in my Network settings - only the AirPort one) I'm observing the following results:

/ecd/resolv.conf:

search <my.company.4leveldomain.com>
nameserver 192.42.234.200
nameserver 192.65.102.200

In the Network settings I have the very same information as before the VPN was established:

DNS Servers: 192.168.0.1 (grayed)
Search Domains: hsd1.wa.comcast.net. (grayed)

netstat -nf:

Routing tables

Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.0.1 UGSc 1 0 en0
127 127.0.0.1 UCS 0 0 lo0
127.0.0.1 127.0.0.1 UH 1 0 lo0
128.166 144.114.44.136 UGSc 0 0 jnc0
128.207 144.114.44.136 UGSc 0 0 jnc0
128.225 144.114.44.136 UGSc 0 0 jnc0
129.172 144.114.44.136 UGSc 0 0 jnc0
129.200 144.114.44.136 UGSc 0 0 jnc0
130.38 144.114.44.136 UGSc 0 0 jnc0
130.42 144.114.44.136 UGSc 0 0 jnc0
130.76.32.188 192.168.0.1 UGHS 6 51 en0
130.121 144.114.44.136 UGSc 0 0 jnc0
130.122 144.114.44.136 UGSc 0 0 jnc0
130.247 144.114.44.136 UGSc 0 0 jnc0
132.173 144.114.44.136 UGSc 0 0 jnc0
132.224 144.114.44.136 UGSc 0 0 jnc0
134.51 144.114.44.136 UGSc 0 0 jnc0
134.52 144.114.44.136 UGSc 0 0 jnc0
134.57 144.114.44.136 UGSc 0 0 jnc0
134.57.240.160 144.114.44.136 UGHS 0 0 jnc0
134.72 144.114.44.136 UGSc 0 0 jnc0
136.202 144.114.44.136 UGSc 0 0 jnc0
136.203 144.114.44.136 UGSc 0 0 jnc0
136.240 144.114.44.136 UGSc 0 0 jnc0
136.241 144.114.44.136 UGSc 0 0 jnc0
137.136 144.114.44.136 UGSc 0 0 jnc0
137.137 144.114.44.136 UGSc 0 0 jnc0
141.102 144.114.44.136 UGSc 0 0 jnc0
144.112 144.114.44.136 UGSc 0 0 jnc0
144.113 144.114.44.136 UGSc 0 0 jnc0
144.114 144.114.44.136 UGSc 0 0 jnc0
144.114.44.136 127.0.0.1 UGHS 0 0 lo0
144.114.44.136/32 144.114.44.136 Uc 61 0 jnc0
144.115 144.114.44.136 UGSc 0 0 jnc0
144.117 144.114.44.136 UGSc 0 0 jnc0
169.254 link#4 UCS 0 0 en0
192.33.44/23 144.114.44.136 UGSc 0 0 jnc0
192.33.48 144.114.44.136 UGSc 0 0 jnc0
192.33.49 144.114.44.136 UGSc 0 0 jnc0
192.33.50 144.114.44.136 UGSc 0 0 jnc0
192.33.52/22 144.114.44.136 UGSc 0 0 jnc0
192.33.56/21 144.114.44.136 UGSc 0 0 jnc0
192.33.61 144.114.44.136 UGSc 0 0 jnc0
192.33.62 144.114.44.136 UGSc 0 0 jnc0
192.33.64/19 144.114.44.136 UGSc 0 0 jnc0
192.42.0/16 144.114.44.136 UGSc 0 0 jnc0
192.42.234.200 144.114.44.136 UGHS 24 25 jnc0
192.48.4 144.114.44.136 UGSc 0 0 jnc0
192.48.5 144.114.44.136 UGSc 0 0 jnc0
192.48.11 144.114.44.136 UGSc 0 0 jnc0
192.48.21 144.114.44.136 UGSc 0 0 jnc0
192.48.30 144.114.44.136 UGSc 0 0 jnc0
192.54.0/20 144.114.44.136 UGSc 0 0 jnc0
192.54.16/21 144.114.44.136 UGSc 0 0 jnc0
192.54.24/22 144.114.44.136 UGSc 0 0 jnc0
192.54.28/23 144.114.44.136 UGSc 0 0 jnc0
192.54.31 144.114.44.136 UGSc 0 0 jnc0
192.54.32/19 144.114.44.136 UGSc 0 0 jnc0
192.54.64/18 144.114.44.136 UGSc 0 0 jnc0
192.54.128/17 144.114.44.136 UGSc 0 0 jnc0
192.65.0/16 144.114.44.136 UGSc 0 0 jnc0
192.65.102.200 144.114.44.136 UGHS 0 0 jnc0
192.65.113 192.168.0.1 UGSc 0 0 en0
192.76.0/16 144.114.44.136 UGSc 0 0 jnc0
192.79.0/16 144.114.44.136 UGSc 0 0 jnc0
192.124.0/16 144.114.44.136 UGSc 0 0 jnc0
192.124.73.96/30 192.168.0.1 UGSc 0 0 en0
192.161.0/16 144.114.44.136 UGSc 0 0 jnc0
192.168.0 link#4 UCS 1 0 en0
192.168.0.1 0:18:e7:c6:6e:c2 UHLS 11 6 en0
192.168.0.150 127.0.0.1 UHS 0 0 lo0
192.168.0.255 ff:ff:ff:ff:ff:ff UHLWbI 0 6 en0
199.33.16/21 144.114.44.136 UGSc 0 0 jnc0
205.175.255 144.114.44.136 UGSc 0 0 jnc0

And (as it always happens) I can access my company internal resources and can NOT access external resources by the names, but with no problems any resource is accessed by IP.

Any thoughts on how to fix that?

Thank you!

Reply

Answer 6

Dec 16, 2010 3:28 AM in response to Andrey Stukalenko

Hi Andrey,

It seems like your VPN client pushes changes so that your companies DNS's are not resolving Internet addresses, so it doesnt use yours config

You either need to get your company to change your vpn profile so that it uses their dns servers first, then adds your DNS ip's (which you'll have to tell them the IP) =which they either may not do, or wont out of policy, or you can manually change them yourself in /etc/resolv.conf ( you used to be able to add both dns servers manually in 10.5 but since those updates, i think that got overridden )

you can write a shell script to copy the entries in DNS after your vpn has connected, or use

sudo echo "nameserver 192.168.0.1" >> /etc/resolv.conf to do this for you in terminal, it'll ask you for your user password, which you'll have to run each time you connect.

My VPN server I've an option to used 1 of three profiles, keep clients DNS, use vpn server's dns settings, or specify alternative dns servers... The VPN admin at your company should have that option, otherwise the Juniper VPN app is rubbish - lol .

I could google it, but I've no idea what device is being used...

Sorry that I can't fix this for you, but i think this one's up for config/interpretation

Reply

Answer 7

Dec 16, 2010 4:17 AM in response to MisterHugh

Well, tried that, but no luck. Tried with the 192.168.0.1 and with search5.conmcast.com and with hsd1.wa.comcast.net ... nothing helps.

Btw, from Windows the same client works perfectly. All requests are correctly processed, Split Tunneling works ideally. Only the MacOS causes all the problems.

Also, I'd like to mention that the first request after the VPN is connected fails with the following error:

-----
Safari can’t find the server.
Safari can’t open the page “ http://search5.comcast.com/?cat=dnsr&con=ds&url=www.gmail.com” because Safari can’t find the server “search5.comcast.com”.
-----

Do you have any idea what may be causing that? It's not my provider as it would fail with Windows as well in that case, so, it really seems that's the problem of either Juniper Network Connect or the MacOS working with java-based VPNs clients.

Reply

Answer 8

mickyw

Level 1

0 points

Dec 16, 2010 11:34 AM in response to Andrey Stukalenko

Andrey,
I have exactly the same issue that you are having. It doesn't matter whether I use my airport, or eithernet, the network connect to juniper networks in split tunnel mode does not support DNS'ing to outside networks. If you find an answer, please let me know. I was curious if Network Connect 7.0 might fix the issue.

Reply