Juniper MAG and internal / external DNS conflict

[cjwalton_]

Hi -

I'm having some issues w/ a Juniper MAG (7.1R4) - using Mac NC clinets. The problem is DNS specific.

We have a domain that resolves on the internet-at-large - let's call it "example.com". There's also an example.com domain served internally that has significantly more entries.

The only DNS settings that I can find appear to apply to which DNS servers to hand out, and the "DNS search order" setting. If I set the search order to search the internal DNS first, then everything works as expected, but all DNS queries go through the tunnel, includng ones to google.com, etc. which just means generally slower DNS performance for resources outside the tunnel.

If I set it to search client-side DNS first, then all general queries - google.com, etc. - work using the client-side DNS, but some of the internal resources are not found, since the publicly hosted example.com domain does not contain those resource, and network connect appears to stop once it finds an authoritative domain.

Is it possible to define a domain to always resolve through the tunnel? Can I set a policy to always resolve "example.com" through the VPN?

Any other ideas on how to make this work? I could, I suppose, impose restrictions on the DNS server for requests coming from the VPN pool, but I'm not sure if that would just cause a lookup to fail or would it actually fall back to the client's DNS? In any case, this seems like an overly complicated solution to the problem.

Has anyone else run into this before? Any thoughts or tips?

Thanks...

[MattS_]

Have you tried using Split Tunneling for Network Connect, so only the traffic for the internal example.com hosts are tunneled?

"When split-tunneling is used, Network Connect modifies routes on clients so that traffic
meant for the corporate intranet networks to Network Connect and all other traffic goes
through the local physical adapter.The SA Series Appliance tries to resolve all DNS
requests through the physical adapter first and then routes those that fail to the Network
Connect adapter."

(From ch. 27, p.666 of the Admin Guide).

Another possibility is to use start and end scripts to add/remove host file entries on the client to override DNS. This could lead to problems if NC is not stopped correctly and the end script is not ran, as the modified hosts file would remain in place while the NC tunnel is not up.

[haas_]

We have the same issue with our MAC's. Windows machines listen to the search IVE DNS first. MAC's do not. Any fixes would be appreciated. Split tunneling is not a great idea for us however.

[jayLaiz_]

Hi,

Is it possible to define a domain to always resolve through the tunnel? Can I set a policy to always resolve "example.com" through the VPN?

If you set the profile to search device dns first, this should take care of resolving "example.com" through the VPN, as for why example.com is trying to answer for www.google.com, I have no idea why it would do that, should'nt it just say google.com not my domain, falling back to client DNS.

wireshark captures on NC adapter and on the physical adapter can tell us what is happening

Thanks,

Jay

[haas_]

---

If you set the profile to search device dns first, this should take care of resolving "example.com" through the VPN, 

Mine is set to search the device first but the MAC doesn't listen to that setting. It uses its local DNS first. PC's listen to that rule perfectly but not MAC's.

[RexPGP_]

My internal DNS servers ask outside if they do not have answer. For example I have internal DNS on VPN and request www.cnn.com. I has to ask outside for that. Not sure what you are asked for,

[zanyterp_]

Is it possible to define a domain to always resolve through the tunnel? Can I set a policy to always resolve "example.com" through the VPN?

>>>No; setting device DNS first is your best bet

Any other ideas on how to make this work? I could, I suppose, impose restrictions on the DNS server for requests coming from the VPN pool, but I'm not sure if that would just cause a lookup to fail or would it actually fall back to the client's DNS?

>>>As long as it is not an authoritative answer, yes, it should work just fine