05-21-2008 08:16 AM
Thought I'd post this issue to see if any of you have tried something similar or seen a similar issue. We are running clustered SA4000's at version 6.0R3.1 build 12507.
We've configured the browsers on our laptops and our DNS in such a way that when a user opens up a web page and they are on our network they are taken to our corporate intranet sharepoint portal. When off of our network that same url takes them to our default sign in page on the SA. When the user logs in Host Checker runs and if credentials are met Network Connect automatically launches itself, connects, and drops them on the landing page which is the corporate intranet sharepoint portal. Everything works great up to this point. The user now has an IP on our network with all the access they would have if they were sitting at there desk. However, if the user closes his browser and opens a new one he is taken back to the SA sign in page and not the sharepoint site he should go to.
05-21-2008 08:33 AM
05-22-2008 06:33 AM
Here is another idea -
When NC starts, it modifies the proxy settings and routing table so that the SA is accessed directly - that is, the SSL traffic to the SA does not get routed across the tunnel, since it is the SSL traffic which implements the tunnel in the first place. So there is a route to the address of the SA.
When the next browser opens, I think it uses the cached DNS setting for the name of the portal - after all, it resolved it just seconds ago - and sends the traffic to the address of the SA. I'm guessing the SA does not recognize that it is already in session with this machine, since the address of the machine is now an internal address on your network and not the original Internet address. So it shows the user the sign-in page.
I think you could correct this by running a script on the PC at NC start time which flushed the DNS cache.
05-22-2008 06:35 AM
05-22-2008 09:22 AM
Did you do a ping to the portal name after the "ipconfig /flushdns" to see what the name resolved to? If it resolved to the external (SA) address instead of the internal (portal) address, you know the issue is in DNS resolution.
If so, and you use split tunneling, you may need to change the NC connection profile for DNS search order. I think you want it to search the server's DNS first, then the client's.