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
odd.. can you share the results of a
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.
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.
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.
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)
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!
check the DNS sufix on the network connect profile
you must have the DNS Domain added in your profile