لطفا منتظر باشید ...
Frequently Asked Questions
The following Frequently Asked Questions, answered by the authors of this book, are designed to both measure your understanding of the concepts presented in this chapter and to assist you with real-life implementation of these concepts. To have your questions about this chapter answered by the author, browse to www.syngress.com/solutions and click on the 'Ask the Author' form. You will also gain access to thousands of other FAQs at ITFAQnet.com.
Q: I am using a dedicated FTP program to connect to my company's FTP server. I can authenticate and download information from the FTP site, but I can't upload. I have an Access Rule that allows the host access to the FTP protocol. Why can't I upload?
A: You need to right click on the Access Rule allowing the outbound FTP connection and click the Configure FTP command. Then configure the FTP Policy to allow FTP uploads
Q: I want to authenticate all connections through the ISA firewall. Do I need the Firewall client?
A: Yes! The Firewall client significantly improves both the security and performance of the ISA firewall. Without the Firewall client, you will not be able to authenticate connections made using Winsock applications through the ISA firewall. While you can configure the clients as Web Proxy clients, you will only get user information for HTTP, HTTPS and HTTP tunneled FTP connections. We recommend that you install the Firewall client on all client operating systems and configure Access Rules to require authentication.
Q: I created an Access Rule on the ISA firewall that allows anonymous access using the FTP protocol to our company's FTP site. However, users are not able to establish FTP connections to the site. When I look at the ISA firewall service log, I see that a rule requiring authentication denied the request. Why was the request denied when I had an anonymous access rule allowing the request?
A: The problem is probably related to the ordering of your rules. If you have a rule that applies to the FTP protocol and also requires authentication and that rule is above the anonymous access rule, then the connection request will be denied because that rule was processed before the anonymous access rule. We recommend that you put anonymous Deny rules first, then anonymous Allow rules. Then put authenticated Deny rules after the anonymous Allow. Finally, put your authenticated allow rules at the end of your Access Rule list.
Q: I created a custom Protocol Definition for a custom application we use in-house. The Protocol Definition includes TCP port 4467 outbound and secondary connections for 5587-5600 inbound. I created an Access Rule allowing all users outbound access to this protocol but the connection is denied by the Default Access Rule. Our clients are configured as SecureNAT and Web Proxy clients. What can I do to get this Access Rule to work?
A: The problem you're having is that SecureNAT clients cannot negotiate secondary connections without the aid of application filter. You can get your developers to create an application filter to support your in-house customer protocol. However, a much better solution is to install the Firewall client on your client operating systems. The Firewall client can negotiate secondary connections because it communicates directly with the ISA firewall's Firewall Service.
Q: I have created an Access Rule to allow our SecureNAT clients outbound access to a Web server on our Internal Network that we've published using a Web Publishing Rule. External users have no problem accessing the published server via the Web Publishing Rule but our Internal Network SecureNAT clients cannot connect to the Web site. What can we do to make the Access Rule work correctly?
A: The problem isn't with your Access Rule per se, but rather with the fact that you're looping back through the ISA firewall to access Internal Network resources. We will assume that the published Web server and the SecureNAT clients are all on the same ISA Network. Hosts that are on the same ISA Network should always communicate directly with one another and not loop back through the ISA firewall. From your description, it appears that the SecureNAT clients are resolving the name of your published Web site to the IP address on the external interface of the ISA firewall. To solve this problem, you need to create a split DNS, so that external hosts resolve the name of the Web site to the IP address on the external interface of the ISA firewall that's used by the Web Publishing Rule, and Internal Network SecureNAT clients resolve the IP address of the published Web site to the actual IP address of the Web server (that it uses on the Internal Network).
Q: The clients on my Internal Network are configured as Web Proxy clients. I created an Access Rule allowing outbound access to authenticated users for the HTTP and HTTPS protocols. This rule works fine except for users who need to connect to MSN Messenger using HTTP. Each time the Web Proxy clients attempt to connect to MSN Messenger via the Web Proxy, the connection attempt fails. Why is this happening and how can I fix it?
A: The problem is that the MSN Messenger is sending the MSN user account credentials to the ISA firewall when the Web Proxy authentication request is returned to the MSN Messenger. Since it is unlikely that the user's MSN Messenger credentials are the same as the user's domain credentials, the authentication attempt fails. To solve this problem, you need to bypass the HTTP 407 response returned by the Web Proxy filter on the ISA firewall. The best solution to this problem is to configure the clients as Firewall clients, and then configure the MSN Messenger sites for Direct Access. You can configure Direct Access in the Properties dialog box for the Network(s) from which the client(s) connect to the MSN site. When Direct Access for the MSN Messenger sites is enabled, the Web Proxy client ignores connections for those sites and hands off the connection to the client's Firewall client or SecureNAT client configuration. If you want to require authentication for outbound access, you should install the Firewall client on all client operating systems. The Firewall client transparently sends user credentials to the ISA firewall's Firewall Service.
