How to work around an issue with VPN clients and split DNS (Full Version)

All Forums >> [ISA Server 2004 Firewall] >> VPN



Message

spouseele -> How to work around an issue with VPN clients and split DNS (20.Jan.2006 11:46:18 AM)

This thread is for the article How to work around an issue with VPN clients and split DNS.

Thanks,
Stefaan



tshinder -> RE: How to work around an issue with VPN clients and split DNS (22.Jan.2006 4:38:06 PM)

Hi Stefaan,

Will this article be going on up on the ISAserver.org site soon? Aren't you able to post it yourself through the admin interface?

Thanks!
Tom



spouseele -> RE: How to work around an issue with VPN clients and split DNS (22.Jan.2006 7:52:47 PM)

Hi Tom,

I hope so! I mailed the article to the publisher shortly after the creation of this topic. [8D]

Thanks,
Stefaan



tshinder -> RE: How to work around an issue with VPN clients and split DNS (23.Jan.2006 5:12:11 AM)

Hi Stefaan,

Great!
Thanks!
Tom



tshinder -> RE: How to work around an issue with VPN clients and split DNS (27.Jan.2006 5:07:03 AM)

Hi Stefaan,

Once again, a fantastic article!

Thanks!
Tom



J.F. -> RE: How to work around an issue with VPN clients and split DNS (1.Feb.2006 10:15:57 AM)

Great article!  This could drive an admin insane!

I borrowed the article's idea and wrote a script to manage the DNS binding order with some more flexibility (with credit to Stefaan in the script).  The script works on both local and remote machines and can show the current binding order, move the WAN connection first, move the WAN connection last, or toggle the WAN connection first-or-last to be the opposite of whatever its current position is.  It's named "ISA_DNS_Binding_Order.vbs" and can be downloaded from www.ISAscripts.org.

Thanks for the tip!

   Cheers,
      JF



spouseele -> RE: How to work around an issue with VPN clients and split DNS (1.Feb.2006 8:41:04 PM)

Hi Jason,

thanks for the kind words and the excellent script!  [:)]

Stefaan



tshinder -> RE: How to work around an issue with VPN clients and split DNS (2.Feb.2006 3:11:37 PM)

quote:

ORIGINAL: J.F.

Great article!  This could drive an admin insane!

I borrowed the article's idea and wrote a script to manage the DNS binding order with some more flexibility (with credit to Stefaan in the script).  The script works on both local and remote machines and can show the current binding order, move the WAN connection first, move the WAN connection last, or toggle the WAN connection first-or-last to be the opposite of whatever its current position is.  It's named "ISA_DNS_Binding_Order.vbs" and can be downloaded from www.ISAscripts.org.

Thanks for the tip!

  Cheers,
     JF


Hi Jason,
Thanks! I'll highlight this in next month's newsletter.

Tom 



tuesdak -> RE: How to work around an issue with VPN clients and split DNS (10.Feb.2006 1:28:28 AM)

We ran across a workaround to this accidentally. We didn’t know it until we made major changes to our network and broke it.

ISA server is not alone in this DNS issue. 

Our old network was using Windows RAS with a public IP. Our domain name was “www.example.com”. DNS was an issue with the VPN users until we made an adjustment to RAS to use our exact active directory domain name. We were not running WINS. Suddenly it worked. This was with RAS and the simple VPN included with Windows.

Several months later we upgraded our network with a New WatchGuard firewall and renamed our domain to “example.com” dropping the ‘erroneous’ www in front of it. Right thing to do we thought.

DNS hasn’t worked since the rename. Not even with a RAS server exposed to the internet for VPN. The Watchguard VPN software doesn’t help as they blame Microsoft and refuse to entertain ‘fixing it’ in their client VPN. (You install software on a Windows box, why not make it do what you want?)
The “www.example.com” instead of “example.com” made this work. WatchGuard says it queries the public DNS 3 times before going through the VPN for DNS.

Newsgroups and resources like this have allowed us to figure out why it quit working due to the internal domain name resolvable to an outside DNS server and address.

Tom and others have pointed out the security problems with this split tunnel, not using the default gateway on remote network. I’d like to justify our business plan here so other people, Microsoft Included, can see what value this has in a secure manner.
First off we are connecting remote 1 to 2 computer offices to our main headquarters with the expensive servers. Some of our locations run an application that needs to see the server every so often to update data. These users need internet access along with this application. Other applications we have need to see the server to work and require internet access at the same time. Part of the application is on our server, the other information is elsewhere accessed over the internet via a secure web page. 

About the locations. These would be secured offices that have equal or better security than the main office. (Locked office doors and firewalls.) They all have high speed DSL and cable, even T1’s as this is the 21st century after all.

So if add the number of offices involved and then look at our main internet connection we have two problems with use default gateway on remote network. The number of offices is around 100. To avoid DDOS attacking yourself the internet access has to be large and then doubled to support the traffic for default gateway use. Never mind the slowdown to remote user internet access, when it stops, sessions and server connections lost, due to an overload it will get your attention. That is expensive both for the internet pipe and downtime. This money that could be spent on Windows Server, ISA Server etc. instead. 

There is one thing that may help. I’d say we need to petition Microsoft to resolve this “Administrator Nightmare”. I establish a VPN tunnel for a reason, not an afterthought because it’s trendy. Where is the place to give Microsoft this “vision” of what they think the customer wants?
So far my best solution has been using WINS and manual entry of our UNIX servers and the Hosts file. Yuck! 

Thoughts?



tshinder -> RE: How to work around an issue with VPN clients and split DNS (11.Feb.2006 10:15:32 PM)

Hi Tuesdak,

The ISA firewall allows you to give VPN clients Internet access via the ISA firewall, so you don't need to disable the gateway on remote network settings to reach the Internet. However, this does not solve the bandwidth issues you mention.

Couldn't you use the MS VPN client software instead of the third party software?

Thanks!
Tom




tuesdak -> RE: How to work around an issue with VPN clients and split DNS (14.Feb.2006 2:45:50 AM)

There are three issues involved here.
1 Default gateway
2. DNS issues.
3. Routing issues with Windows VPN.
 
We have used ISA Firewall 2000 in the past, before my time here. The only ‘bad’ thing about it was the number of times it was taken down for OS updates. I am sure there is a way to work around that though. We used it right up till the server died. We were better off with it! (The network setup after it was removed was not secure.) The number of advantages it has over an X2500 Watch Guard Firewall are immense. Like user verification to get internet access, Reporting of what sites visited and by whom, caching, and reliability. (WG software to monitor and control the box hates a constant connection.) The WG suffers from reboots as well for configuration changes and the occasional glitch. (VPN would no longer connect crash.)
 
Unrelated, I used ISA 2000 in a computer repair shop specifically to cache all of the Windows Updates every computer going through our shop had to have. There is a speed difference between single nic, proxy only, and dual nic full firewall with proxy setups.
Even with 4.5Mb/s internet speed the ISA on a Pentium Pro server would out run it by a factor of 5! Then the Virus definition updates speed up… updates to this and that program… Just a joy to watch it download them, from ISA, like a firestorm vs. a wood chipper. The Windows updates for a ‘home user’ repair shop was covered by the ‘clone a Windows Update website on your server’ for a short time. The ISA did a better job and Microsoft discontinued that ‘local website’ option anyway.  
 
Anyway both Windows and Watch Guard VPN connect to the Watch Guard firewall.
I have not punched a hole in it for VPN connections to a RAS server. I am looking at ISA beside the firewall just for VPN, yet I hear 2004 has some issues with VPN.
 
Reason #1.
I did kill our internet connection attempting to use the VPN default gateway option when we put in the Watch Guard Firewall. Not good.
 
Reason #2
We have a second office that has a couple servers at it. They are 172.17.x.x and the main office is 172.16.x.x. Windows VPN won’t route to 172.17.x.x when it has a 172.16.x.x address. I do not know how to change its’ implied subnet mask to 255.0.0.0 or get it to know it can send 172.17.x.x through the VPN. That information is not easy to find.
 
Reason #3
I would like VPN users to be on 172.18.x.x. We are using the 10 network as an optional network for something else the VPN users don’t need. The 192.168.x.x network is also being used at the remote offices and VPN users do not need it.
 
Design consideration. I have a point to point T1 line to our other office. I have a backup route via a VPN to our other office. To make this work I have a router between the firewall and the inside network making the decision between the VPN or Point to Point T1 biased on what line is up. Thus the router, not the firewall, is the default gateway. The router decides to send traffic over the point to point or to the firewall. The T1’s 99.99% uptime with 0.01% downtime, usually an all day event, is worth the backup route complexity in terms of cost to us for being down.
VPN does not need to be 100% during the ‘downtime.’
 
So with all three reasons given, is there a way to have a Windows VPN address be 172.18.0.2 and see the 17.16.x.x and 172.17.x.x networks without the default gateway checked?
This is why I am using the Watch Guard VPN software, it does this routing to the other two networks.  Again, I have not run across a way to setup Windows VPN to do this or a definite No, it can’t be done.  I could find an open spot in the 10 network if it would help for VPN IP addresses.
 
I didn’t even touch the DNS issue this time.
 
Ideas?



dstewen -> RE: How to work around an issue with VPN clients and split DNS (14.Mar.2006 11:35:19 AM)

Does anyone know if this problem is still an issue after installing QSS from http://fesnouf.online.fr ?

Thanks,

David.



spouseele -> RE: How to work around an issue with VPN clients and split DNS (14.Mar.2006 8:46:28 PM)

Hi David,

what do you have in mind?

HTH,
Stefaan



dstewen -> RE: How to work around an issue with VPN clients and split DNS (15.Mar.2006 4:29:41 AM)

I have been testing SBS 2003 Premium for the last couple of weeks. After reading Tom's articles on Split DNS and coming accross some of the issues of using a .local internal domain I have decided to change to a split DNS setup.

But, from my limited understanding Split DNS is affected by the issue with VPN connections not using the VPN assigned DNS server first. I have read Stephaan's article at http://www.isaserver.org/tutorials/work-around-VPN-clients-split-DNS.html and that mentions a workaround.

The question I had was is QSS (downloaded from http://fesnouf.online.fr/ and recommended by Tom as an alternative to RQS & RQC) affected by the same issue? I have downloaded the videos Frédéric has on his website and nothing is mentioned about the Split DNS vpn problem. My current line of thought is that QSS is using a Windows based VPN connection so is bound by the normal vpn setup (therefore still affected by the DNS server issue). I think I can still get around the issue by creating the vbscript that is in the above workaround that is run by the QSS Security Client.

Thoughts anyone?

David



spouseele -> RE: How to work around an issue with VPN clients and split DNS (15.Mar.2006 8:48:29 PM)

Hi David,

at the end of 2005, I briefly tested QSS and tried to figure out how QSS would fit in my VPN deployment. I did contact Frédéric and we had some very good technical discussions and have done some proof-of-concept tests for QSS enhancements in this area. However, due to some other priorities, I didn't follow up with Frédéric what the current status of the suggested enhancements are.

Basically, QSS only comes into play *after* the VPN is already setted up. So, this changes nothing on the issue described in my article. Moreover, the suggested script should be run as a pre-connect action and not after the VPN connection is already made. Therefore, I think the best option would be to still use the CMAK solution with the suggested script, but integrate also the starting and stopping of the QSS Security client in the CMAK as a pre-connect and disconnect action.

HTH,
Stefaan



fesnouf@hotmail.com -> RE: How to work around an issue with VPN clients and split DNS (19.Mar.2006 5:41:03 PM)

Hi guys,

It is always a pleasure to discuss about VPN-Q because this technology is very smart to protect the company.

The major difference between RQC/RQS and QSS is the fact that with MS approach, all happen on the client side : analysis, compliancy, unquarantine... which is not "perfect" in a security point of view because you could find in a few seconds the passphrase to unquarantine the machine, and so fake the system.

Also, RQC/RQS requires some script which is not so easy for all the people around the world.

QSS has in fact 2 components : a Security Client supposed to interact with the end-user, and make a 'snapshot' of the workstation's configuration when VPN connected... and then send it to the server part of QSS called the Approval Server for analysis and compliancy. This is one of the key difference with MS : only the server part has the knownledge of the current security policy and so, this is the only component authorized to unquarantine the user (a user can't fake the system).

I tried with QSS to provide a simple way to implement VPN-Q so you don't script at all.

For example with the "split tunnel risk", you just say in a GUI that ICF is mandatory, and tha ISharing must be OFF... otherwise you are not compliant, will be remotly fixed and disconnected.

You can use CMAK to package the connection if you want but it is not mandatory with my product. QSS Security Client (on the workstation) is hidden and will appear when the tunnel will be up (I don't need the CMAK post-connect event).

Back to stefaan article, you could use QSS Security Client to execute this script every time the user is connected. This is done on the client by a "Script" that I leave open for the customers, so they can grab whatever kind of parameter and put them in the security policy.

If you need more details, send me an email that will be quicker : frederic@esnouf.net.... but to keep a track on isaserver.org, this script is optional, called custom.vbs and is located in the QSS Security client directory. Just copy and paste the script of the article there and you will be ok.

For your info, the new version of QSS will probably arrive this summer. So far the product works fine and just need tiny enhancements. I will supply a new version for the arrival of ISA 2006, Vista, antispyware, ... I am working on the spects for the moment for feel free to send me good ideas of enhancements.

If you have any questions, just let me know.

Best regards.

Frederic ESNOUF
ISA MVP





spouseele -> RE: How to work around an issue with VPN clients and split DNS (19.Mar.2006 7:06:17 PM)

Hi Frederic,

quote:

Back to stefaan article, you could use QSS Security Client to execute this script every time the user is connected. This is done on the client by a "Script" that I leave open for the customers, so they can grab whatever kind of parameter and put them in the security policy.

If we use the QSS script 'custom.vbs' to implement the workaround mentioned in KB311218 then we must be sure we can do that *after* that the VPN connection is already up but still in the quarantaine state. Until now I assumed that the registry change must be done *before* setting up the VPN connection in order to correct the issue. So, I've done some more testing and it turns out that you can change that registry key on the fly and that it will instantly correct the issue, even if the VPN connection is already up.

Therefore, it sounds that the QSS script 'custom.vbs' can indeed be used to implement the workaround mentioned in KB311218.

HTH,
Stefaan



tshinder -> RE: How to work around an issue with VPN clients and split DNS (21.Mar.2006 3:06:13 PM)

quote:

ORIGINAL: fesnouf@hotmail.com

Hi guys,

It is always a pleasure to discuss about VPN-Q because this technology is very smart to protect the company.

The major difference between RQC/RQS and QSS is the fact that with MS approach, all happen on the client side : analysis, compliancy, unquarantine... which is not "perfect" in a security point of view because you could find in a few seconds the passphrase to unquarantine the machine, and so fake the system.

Also, RQC/RQS requires some script which is not so easy for all the people around the world.

QSS has in fact 2 components : a Security Client supposed to interact with the end-user, and make a 'snapshot' of the workstation's configuration when VPN connected... and then send it to the server part of QSS called the Approval Server for analysis and compliancy. This is one of the key difference with MS : only the server part has the knownledge of the current security policy and so, this is the only component authorized to unquarantine the user (a user can't fake the system).

I tried with QSS to provide a simple way to implement VPN-Q so you don't script at all.

For example with the "split tunnel risk", you just say in a GUI that ICF is mandatory, and tha ISharing must be OFF... otherwise you are not compliant, will be remotly fixed and disconnected.

You can use CMAK to package the connection if you want but it is not mandatory with my product. QSS Security Client (on the workstation) is hidden and will appear when the tunnel will be up (I don't need the CMAK post-connect event).

Back to stefaan article, you could use QSS Security Client to execute this script every time the user is connected. This is done on the client by a "Script" that I leave open for the customers, so they can grab whatever kind of parameter and put them in the security policy.

If you need more details, send me an email that will be quicker : frederic@esnouf.net.... but to keep a track on isaserver.org, this script is optional, called custom.vbs and is located in the QSS Security client directory. Just copy and paste the script of the article there and you will be ok.

For your info, the new version of QSS will probably arrive this summer. So far the product works fine and just need tiny enhancements. I will supply a new version for the arrival of ISA 2006, Vista, antispyware, ... I am working on the spects for the moment for feel free to send me good ideas of enhancements.

If you have any questions, just let me know.

Best regards.

Frederic ESNOUF
ISA MVP





Hi Fred,
Thanks!
Tom



spouseele -> RE: How to work around an issue with VPN clients and split DNS (1.Mar.2008 12:21:42 PM)

Hi Stefan,

about your comment on my blog http://blogs.isaserver.org/pouseele/2007/12/22/ras-administration-dll-useful-on-isa-server/#comments.

Why did you assign the 10.50.1.1 and 10.50.1.2 to the LAN adapter? They are only reachable through the VPN. So, get rid of them on the LAN adapter.

When you are connected to the VPN, did you manually apply http://support.microsoft.com/default.aspx?scid=kb;en-us;311218? That's the only trick I know of for a pre-Vista box and it never failed me.

HTH,
Stefaan



miguel_gonz -> RE: How to work around an issue with VPN clients and split DNS (27.Mar.2008 6:21:49 PM)

Hi,

I have the VPN configured in our ISA 2004 server for Macs and Microsoft machines.

I recently discovered that our internal NIC was a FastEthernet, I changed it to Gigabit and suddenly a Mac user reported me that He didn't have more resolving issues.

However, in the Windows realm, at least with wireless routers at home, I still get disconnected from time to time and DNS takes a while to start resolving. Why is that? This workaround would help for this issue or is a different issue?

Thanks,

Miguel



Page: [1] 2   next >   >>