Welcome to ISAserver.org
Forums |
Register |
Login |
My Profile |
Inbox |
RSS 
|
My Subscription |
My Forums |
Address Book |
Member List |
Search |
FAQ |
Ticket List |
Log Out
VPN clients' DNS binding order. fixed???
|
Users viewing this topic:
none
|
Logged in as: Guest
|
Login  | |
|
VPN clients' DNS binding order. fixed??? - 19.Sep.2008 11:13:16 AM
|
|
|
sketchy00
Posts: 20
Joined: 8.Aug.2008
From: Bellevue, WA
Status: offline
|
A lot has been written about binding orders of connected VPN clients, and how the client can fail to use the correct DNS servers for name resolution once connected. The articles (http://www.isaserver.org/tutorials/work-around-VPN-clients-split-DNS.html) and threads (http://forums.isaserver.org/m_2002004268/tm.htm) have provided great insight into the issue, suggestions to use CMAK and a few good scripts along the way to attempt to resolve the problem (http://www.isascripts.org > ISA_DNS_Binding_Order.vbs ) that deals specifically with the issue described in Microsoft’s KB 311218.
However, based on what I’ve observed, this doesn’t necessarily address the problem. I’m about to cut over from a Watchguard Firebox to a ISA2006SP1 unit. The old Watchguard’s PPTP VPN tunnel works flawlessly. The ISA’s PPTP VPN tunnel doesn’t. Per the suggestions, I’ve created a CMAK bundle, and included the script for adjusting the binding order. The result is that sometimes the connection is good, (verified by doing an nslookup, etc.) and sometimes it is not, whether I connect using the bundle created by CMAK and scripting, or a manual VPN connection.
In comparison, if I connect via the Watchguard, execute the ISA_DNS_Binding_Order.vbs script with the “/show” switch, it show’s exactly the same binding order that is shown when attempting to connect via the ISA box, but it ALWAYS returns the correct results when doing an nslookup, or attempt to contact nodes on the internal network.
So all of you ISA experts out there, correct me if I’m wrong, but it seems as if it was truly a problem exclusive with the client, that this would occur no matter the source of the VPN server. My tests seem to show otherwise. And yes, I’d be willing to overlook all of this if supposed workaround guaranteed a good name resolution, but it just doesn’t seem to. And yes, I see the same behavior whether it be on XP, or Vista (no UAC running on vista, just to simplify matters).
_____________________________
- sketchy
|
|
|
|
|
RE: VPN clients' DNS binding order. fixed??? - 19.Sep.2008 2:17:11 PM
|
|
|
sketchy00
Posts: 20
Joined: 8.Aug.2008
From: Bellevue, WA
Status: offline
|
Thanks for the reply Jason. Most of my testing has been from home, and I've built up test CMAK configurations with the script as a pre-connect and post connect action types to see if that made a difference. The only other custom actions I have in the cmak configuration is a post-connect configuration of the IE proxy. I also made up seperate configurations for XP and Vista so that the location of the files would be in the appropriate area (%appdata%/... in XP and %programdata%/... in Vista). Yesterday for instance, I went home and tried them in both environments, and they worked right away. Then later on in the evening I tried, and they didn't work. This scenario has occured off and on for quite a while - exhibiting the same behavior. If I manually run the script, it still doesn't change the situation.
Ironically, if I attempt to connect via our old Watchguard unit, and do an nslookup, it returns the results perfectly, every time.
Much agreed on the suggestion to use L2TP/IPSec. Since this was a rollout to a new setup, I figured that phasing in different features would allow me to stick to a timeline better. I will definately look into it when I have the opportunity.
Any insight anyone can provide on this would be greatly appreciated.
_____________________________
- sketchy
|
|
|
|
|
RE: VPN clients' DNS binding order. fixed??? - 20.Sep.2008 3:11:29 PM
|
|
|
justmee
Posts: 505
Joined: 14.May2007
Status: offline
|
I have not touched for quite a while a PPTP connection, but...
You can run all day long on Vista that script. It does not apply to Vista.
Vista does not have the problem described in the KB article. In fact, as far as I have seen there is no \Device\NdisWanIp value in the specified registry location on Vista. If there is one, that script added it.
The script is needed on XP machines to automate the fixing process. For static tests, you can manually make the required changes. No need for CMAK either.
How and what DNS server is queried, the VPN client decides, ISA just pushes to the VPN clients the internal DNS servers' IP addresses, (assuming you have a simple scenario, not sure what you have configured on ISA and on the VPN clients, are you using DHCP or static for address assignment, is the use DG on the remote net checked on the VPN client...).
Have you checked that the correct DNS server is assigned to the VPN client by ISA on the PPP adapter ?
If you are not sure about how this happens, please read this:
http://forums.isaserver.org/m_2002047348/mpage_1/key_/tm.htm#2002047532
|
|
|
|
|
RE: VPN clients' DNS binding order. fixed??? - 23.Sep.2008 12:07:05 AM
|
|
|
sketchy00
Posts: 20
Joined: 8.Aug.2008
From: Bellevue, WA
Status: offline
|
Well, and interesting revelation has come up.
I noticed that in DNS, there were some orphaned entries (forward and reverse) that didn't correspond to anything active that I had on the network. Since setting up ISA, and setting aside a modest 10 addresses for VPN users, those "RAS" entries showed up in DHCP, but of course, would sometimes conflict with those orphaned DNS entries. I cleaned up the garbage, and it's working great so far.
At this point, I'm only theorizing that this was the problem. I've done many tests this evening on both XP and Vista, and now it works perfectly, but it is a bit early to start celebrating. But it does seem consistant in the my Watchguard distributed VPN addresses differently than ISA, thus it never had this problem. My bad for not noticing the junk in DNS.
I'd be interested ot hear from others if this was a realistic possibility, and if so, if there is a best practice for preventing this from occuring? I'm just on a simple /24 net with a single scope DHCP range covering the majority of those addresses, and ISA configured to use DHCP on the internal interface.
_____________________________
- sketchy
|
|
|
|
|
RE: VPN clients' DNS binding order. fixed??? - 24.Sep.2008 10:21:22 AM
|
|
|
sketchy00
Posts: 20
Joined: 8.Aug.2008
From: Bellevue, WA
Status: offline
|
Just a quick updated on the information provided on my last post. It does appear that conflicts (orphaned/old records) in DNS that were conflicting with the IP addresses that DHCP was giving out for ISA's VPN connections were messing things up. After cleaning up the garbage, I've continued to have 100% success with being able to resolve names after connecting. The problem was never with connecting, but with it being able to resolve names correctly after connected. Again, this seems to be fixed now.
This might help those of you who experience similar things. And it might be good for one of the contributors here on the site to include this in some one of their upcoming related articles.
_____________________________
- sketchy
|
|
|
|
 New Messages |
 No New Messages |
 Hot Topic w/ New Messages |
 Hot Topic w/o New Messages |
 Locked w/ New Messages |
 Locked w/o New Messages |
|
 Post New Thread
Reply to Message
Post New Poll
Submit Vote
Delete My Own Post
Delete My Own Thread
Rate Posts |
|
Printable Version
. However, the last customer I worked with did have the problem and we used the scripts in Stefaan's article, deployed via CMAK, to solve the problem. The VPN has now been in pilot for about a month and the original name resolution issues that were caused by incorrect bind order have been completely cured. 
