Bingo! You understand my issue perfectly. Internal clients have no business resolving external names via the FWC unless I explicitly allow them to. I was not aware of the default behavior of the FWC in regard to DNS resolution, but now that I am, I need to change it. This is ISA2004, and I have set the parameters exactly as specified and it does not work. I'll try restarting both the ISA server and the client just for S&G to see what happens. Thanks! t On 7/6/06 7:13 PM, "Thomas W Shinder" <tshinder@xxxxxxxxxxx> spoketh to all: > OK, so it's not name resolution in general that's hurting your feelings, > its that you don't want all applications to be able to have the ISA > firewall resolve names on the client's behalf. Is that correct? > > IOWs, it's OK for the ISA firewall to resolve names on behalf of the Web > proxy client, but its NOT OK to have the ISA firewall resolve names on > behalf of the Firewall client, because the Web proxy client is the > browser (and other applications that use the WinInet or WinHTTP > interfaces, I think), but its NOT OK for all Winsock applications to > have names resolved on their behalf. > > All I can say is that it *should* work, at least for ISA Server 2000 and > ISA 2004. Haven't tested it yet on ISA Server 2006 and I notice that in > the RC, they've removed all documentation of FWC settings, which doesn't > forbode well. But here's what it says in the ISA 2004 HF: > > NameResolution Possible values: L or R. By default, dotted decimal > notation or Internet domain names are redirected to the ISA Server > computer for name resolution and all other names are resolved on the > local computer. When the value is set to R, all names are redirected to > the ISA Server computer for resolution. When the value is set to L, all > names are resolved on the local computer. > > Thomas W Shinder, M.D. > Site: www.isaserver.org > Blog: http://blogs.isaserver.org/shinder/ > Book: http://tinyurl.com/3xqb7 > MVP -- ISA Firewalls > > > >> -----Original Message----- >> From: isapros-bounce@xxxxxxxxxxxxx >> [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Thor >> (Hammer of God) >> Sent: Thursday, July 06, 2006 9:05 PM >> To: isapros@xxxxxxxxxxxxx >> Subject: [isapros] Re: [ISAServer] Firewall client DNS >> resolution over control channel >> >> >> Whatchu talkin 'bout Willis? >> >> All the clients have internal DNS set. Internal DNS has root >> zones. From a >> command prompt (or some exploit) they cannot resolve external >> addresses. >> But when you set them as Web Proxy clients, they can, of >> course, use IE as >> the ISA server *does* have DNS configured, and has rules that >> allow it to >> query my external name server and my ISP's server cache (and >> *only* that >> server cache). That works just fine, and always has. >> >> There are a few special cases where I've needed the firewall >> client (those >> are not important to the subject.) >> >> As I have seen in the linked article (and others) a FWC >> machine will use the >> control channel (1745) to query DNS, and the ISA server will >> proxy that >> request even in a shell. I added the "L" parameter to the >> NameResolution >> tag, applied settings, refreshed the client, and it can still resolve >> external host names via the ISA server. There is no reason >> for the client >> to be able to do that, and I want to disable that. >> >> t >> >> On 7/6/06 6:46 PM, "Thomas W Shinder" <tshinder@xxxxxxxxxxx> >> spoketh to all: >> >>> Wait a minute. How do the Firewall clients reach external >> resources if >>> the ISA firewall cannot perform name resolution on their >> behalf and the >>> clients don't have a DNS server configured on them to resolve names? >>> >>> For that matter, how do the Web proxy clients resolve >> external names? >>> The mechanism is the same. >>> >>> Tom >>> >>> Thomas W Shinder, M.D. >>> Site: www.isaserver.org >>> Blog: http://blogs.isaserver.org/shinder/ >>> Book: http://tinyurl.com/3xqb7 >>> MVP -- ISA Firewalls >>> >>> >>> >>>> -----Original Message----- >>>> From: isapros-bounce@xxxxxxxxxxxxx >>>> [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Thor >>>> (Hammer of God) >>>> Sent: Thursday, July 06, 2006 8:43 PM >>>> To: isapros@xxxxxxxxxxxxx >>>> Subject: [isapros] Re: [ISAServer] Firewall client DNS >>>> resolution over control channel >>>> >>>> Yep. >>>> >>>> >>>> On 7/6/06 6:08 PM, "Thomas W Shinder" <tshinder@xxxxxxxxxxx> >>>> spoketh to all: >>>> >>>>> Did you refresh the Firewall client configuration? >>>>> >>>>> Thomas W Shinder, M.D. >>>>> Site: www.isaserver.org >>>>> Blog: http://blogs.isaserver.org/shinder/ >>>>> Book: http://tinyurl.com/3xqb7 >>>>> MVP -- ISA Firewalls >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: isapros-bounce@xxxxxxxxxxxxx >>>>>> [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Thor >>>>>> (Hammer of God) >>>>>> Sent: Thursday, July 06, 2006 7:17 PM >>>>>> To: isapros@xxxxxxxxxxxxx >>>>>> Subject: [isapros] Re: [ISAServer] Firewall client DNS >>>>>> resolution over control channel >>>>>> >>>>>> OK- I added the config option with "L" as described, and it >>>>>> still doesn't >>>>>> stop it. What exactly is the option? >>>>>> >>>>>> t >>>>>> >>>>>> >>>>>> On 7/6/06 2:13 PM, "Thomas W Shinder" <tshinder@xxxxxxxxxxx> >>>>>> spoketh to all: >>>>>> >>>>>>> Tim, >>>>>>> >>>>>>> You can change this behavior in the FWC configuration settings. >>>>>>> >>>>>>> Jim will be sad that you didn't read his semenal article on this >>>>>>> subject: >>>>>>> >>>>>>> >>>>>> http://www.isaserver.org/tutorials/ISA_Clients__Part_3_The_Fir >>>>>> ewall_Clie >>>>>>> nt.html >>>>>>> >>>>>>> BTW -- post to the big boys list first ;) >>>>>>> >>>>>>> Thanks! >>>>>>> Tom >>>>>>> >>>>>>> Thomas W Shinder, M.D. >>>>>>> Site: www.isaserver.org >>>>>>> Blog: http://blogs.isaserver.org/shinder/ >>>>>>> Book: http://tinyurl.com/3xqb7 >>>>>>> MVP -- ISA Firewalls >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Thor (Hammer of God) [mailto:thor@xxxxxxxxxxxxxxx] >>>>>>>> Sent: Thursday, July 06, 2006 4:03 PM >>>>>>>> To: ISA-MVP >>>>>>>> Subject: [ISAServer] Firewall client DNS resolution over >>>>>>>> control channel >>>>>>>> >>>>>>>> Greetings: >>>>>>>> >>>>>>>> As some of you may know, I practice least privilege whenever >>>>>>>> possible for >>>>>>>> all client access. Part of this strategy includes >>>>>>>> configuring internal AD >>>>>>>> DNS as root zones (with no possible forwarders.) In this >>>>>>>> way, internal >>>>>>>> clients can never have non proxy-aware applications resolve >>>>>>>> external hosts. >>>>>>>> Almost all of my clients are exclusively Web Proxy clients, >>>>>>>> which means that >>>>>>>> only services available via IE settings can have the DNS >>>>>>>> resolution proxied >>>>>>>> for them. >>>>>>>> >>>>>>>> However, in testing access with the Firewall Client, I have >>>>>>>> found that no >>>>>>>> matter what I do, I cannot restrict a client running the FWC >>>>>>>> from resolving >>>>>>>> external hosts via the FWC control channel. I have no rules >>>>>>>> allowing DNS >>>>>>>> access from the internal network, have ensured that the >>>>>>>> system policy only >>>>>>>> resolves to Domain Controllers for DNS, ensured that only >>>>>>>> Local Host can >>>>>>>> look up DNS, and have even explicitly denied Internal hosts >>>>>>>> from resolving >>>>>>>> DNS. Yet, if a system has the FWC on it (and enabled) then >>>>>>>> they can resolve >>>>>>>> external hosts. >>>>>>>> >>>>>>>> How do I stop this? An more importantly, are there >> any other FWC >>>>>>>> control-channel policy exclusions that I should know about? >>>>>>>> >>>>>>>> Thnx >>>>>>>> T >>>>>>>> >>>>>>>> >>>>>>>> --- >>>>>>>> To subscribe to the list - send an email to >> list@xxxxxxxxxxxxxxx >>>>>>>> In the subject line put in JOIN isaserver@xxxxxxxxxxxxxxx, >>>>>>>> youremailaddress >>>>>>>> >>>>>>>> To leave the list - send an email to list@xxxxxxxxxxxxxxx >>>>>>>> In the subject line put in LEAVE isaserver@xxxxxxxxxxxxxxx, >>>>>>>> youremailaddress >>>>>>>> >>>>>>>> Don't forget the comma! >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> >> > > >