If I understand it will, the only way to work with it, is to have the SecureNat client installed since these protocols are not supported by the firewall client.
It seems that in a production environment combining both (SecureNat and Firewall) is not a good practise.
Why? If you need policies on users and groups and e.g. PPTP, you have no choise, have you?
a single machine can be configured as a SecureNAT, Firewall and Web Proxy client at the same time without any adverse interaction between the client configuration settings. In fact this is the standard configuration I always use for the clients.
you are reading very thoroughly Tom's book. That's very good!
Very often I'm working with a routed internal network. In that situation the clients all have DNS, WINS and Default Gateway set. So technically they are configured as SecureNAT client. Even if it is a simple internal network, I always set the Default Gateway.
The Firewall client works on the Winsock level and handles only requests for TCP/UDP protocols if they are *not* in the LAT. All other requests are not touched and follows the normal packet processing of the TCP/IP stack. In the latter case we say that the requests are sent as from a SecureNAT client. To learn more about the Firewall client, check out http://www.isaserver.org/articles/Understanding_the_Firewall_Client_Control_Channel.html .
If you carefully read the above mentioned article and look at the network monitor traces, you will see that the packets sent from a Firewall client has the ISA server internal IP address as destination IP address. The same holds true for a Web Proxy client. However, if you take a network monitor trace of a SecureNAT session, you will see that the packets sent from a SecureNAT client has the IP address of the real destination as destination IP address. Therefore it is common to say that if you see packets with the real destination IP address, they are sent as from a SecureNAT client.
Now, what Tom is referring to in his book is that although the client may be configured as SecureNAT client, if the Firewall client is installed and enabled, TCP/UDP packets will be handled by the Firewall client (if destination is not in the LAT).
Why combining all tree client types together? If you want to ping external destinations, the client must be a SecureNAT client because ping uses the ICMP protocol and that is *not* handled by the Firewall client.
I never thought of this the way you document it with network monitor traces.
The fact that you see in case of a securenat clients the real destination address and in other cases the internal IP of the ISA server explains also why the secureNat is completely responsible for DNS resolving and why for the other client ISA server can do the resolving, isn't it?
Regards for your answer,
Geert
Now that I finished this chapter, I'll go through all documents I can find on this site concerning ISA services and ISA clients. I already saw your document on your site.
BTW --- I'm a networking guy. So, I like to document things with Ethereal (a very good free network monitor) and compare them to the ISA log files. In that way I have learned a lot on how to read the log files.
your tips are and will be very usefull. At this moment I do to much reading and not enough testing myself. I always start reading about and studying a product before actually realy using it. I should pay more attention to the "testing myself" part to become realy close with a product
The PPTP issue is a real security concern for a number of reasons. You can't control who has access to PPTP through the firewall, so if you allow access, you allow it for everyone. As you can image, if you allow users to PPTP into an untrusted network, you allow allow sort of things to enter your network and they completely bypass your security configuration on the firewall.
|
My Subscription |
My Forums |
Address Book |
Member List |
Search |
FAQ |
Ticket List |
Log Out
Printable Version
All Forums >> [ISA Server 2000 Firewall] >> Firewall Client >> Non UDP - TCP protocols 
Non UDP - TCP protocols - 
RE: Non UDP - TCP protocols - ![[Big Grin]](/image/smiles/biggrin.gif)
RE: Non UDP - TCP protocols - ![[Smile]](/image/smiles/smile.gif)
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