DNS name resolution issue with Network Connect

[ZDW_]

I'm having some users that are unable to resolve internal machine names without using the FQDN (using network connect). For example, ping mymachine does not resolve to mymachine.mycompany.com, but if you ping mymachine.mycompany.com, it resolves fine. With most users the name resolves fine. I can log in on a machine that isn't resolving correctly, and it will then resolve correctly. Has anyone seen this?

- I do have the domain name listed in the DNS Domain's field

- It does work for MOST users, there are only a few that don't (working and non-working users have the same roles/permissions)

- This has happened on R6.0 and 6.2, and network connect 6.0 and 6.2

Any thoughts?

[imtravis_]

Are they the same OS that's failing and working? Are the ones failing just home user pcs or are they locked down in any way? Does the user have rights to modify the "hosts" file?

[Jickfoo_]

odd.. can you share the results of a

ipconfig /all

for one of these people during the situation ?

DNS issues are also very traceable.. I'd suggest running a TCP dump and looking at the results in Wireshark.

[cperez_]

I am having the same problem with my SSL vpn cluster. When searching the client DNS first, the IVE will append the domain from the IVE on top of the domain for the client. ie - IVE domain is ive.com while the client is network.com, the search order is ive.com, then network.com.

There are 2 problems with this configuation.

1. There are many users who have DNS caching service (opendns) who provide results for non-publicly published resources. (NC will look for a "domain not found" result from the DNS query, caching services will return a search page, or something simular)

2. When searching client DNS, the client domain should be first, but it is not.

I have a case open with JTAC, and it has been escalated to advanced JTAC. So far it looks like it will be related to the 6.X train of code, as were not having this issue when running 5.5.

[ancheta.m_]

Read this KB. I am not sure why they need us to request an ER from a SE. Why cannot just fix it. Some of us need split-tunneling enabled for crying out loud.

http://kb.pulsesecure.net/InfoCenter/index?page=content&id=KB16461

[zanyterp_]

@ancheta.m: The enhancement request is needed as any fix to workaround the behavior of the ISP and Windows will require a rewrite of Network Connect. What users see with this behavior is how Windows & their ISP works. Some other options for users: type in the FQDN for access, work with their ISP to disable DNS hijacking/DNS helper for their account/access, or, as recommended in the KB article, use an open DNS server that does not take over the DNS response.

[RasKal_]

Hello,

A bit late to jump into this one but it's now hot for us as we switch to NC split-tunneling with access to local subnet for our employees (68K).

http://en.wikipedia.org/wiki/DNS_hijacking#Manipulation_by_ISPs is an interesting one. The concern about WIndows machines sending traffic to non corporate DNS servers is genuine, and a risk for us.

So, if it is a risk then why not switching back to no tunneling at all? Good question...

And some answers (side note: we have a forest made of several domains, thus the DNS search list is not made of a single entry)

1. Although using NC for the time being, we are looking for Junos Pulse in the future. The "Location awarness" feature which may trigger the tunnel establishment is attractive. DNS hijacking will break it as our users often enter non FQDN hostnames in whatever program they are using.
2. Regarding Web browsing, we are going to switch from a proxy PAC file settings model to no proxy settings at all: WCCP, thus routing will do the job. Sending browsing traffic to the corporate forward-proxy's via the tunnel is non-sense (assessing the risk of split-tunneling is not for this particular DNS topic).

Ideally, I'd be happy to see NC or Pulse tricking the hijacking made by these ISP (which are somehow breaking the RFC by the way. Read this if interested http://www.icann.org/en/committees/security/sac032.pdf ). I meant: ideally, Juniper is providing a workaround.

Another quick(?) fix would be to create a list of these hijacker DNS Server IPs, a kind of ongoing community work. The file could be fetched by simple http get (of course, some security mechanisms should be put in place to avoid wrong IP to be there, but it's not the point at this stage). This file could be then used to feed the NC allow Tunneling policies so that traffic for these IP are routed into the tunnel.... Not sure it would do, but it could be worth the try :-).

Who is connected via an ISP which is doing such nasty resdirections and want to test the above? Feedback would be more than welcome!

Cheers,

//P

[tjardim_]

check the DNS sufix on the network connect profile

you must have the DNS Domain added in your profile

[stine_]

If you configure the tunnel to search the client's dns entries second, and have the appropriate list of dns suffixes configured, would this solve your problem? This, of course, assumes that both your internal dns domain and that of your customers are different. If you both use .corp.local, I don't think there's a solution. Also, beware that poorly configured Cisco VPN clients can break even this configuration because they sometimes don't remove the dns suffixes when the Cisco VPN exits.