Suppose you have the following scenario:
You are running ISA Server in 3-Leg configuration with a route relationship between the Internal and Perimeter networks. There's a FTP Server and some Web Servers operating in your Perimeter network.
FTP Server Address is 126.96.36.199 connected to Perimeter network
You have already published some Web Servers connected to your Perimeter network, and made them available to External and Internal Users. Now you want to publish a Non-Web Server e.g. the FTP Server connected to the Perimeter network to the Users in the External and Internal networks. You want to use the ISA IP-Addresses for this publishing scenario.
To do so you open the ISA MMC right-click Firewall Policy and Select New ->'Non-Web Server Protocol publishing rule'. You Enter a Name for the rule e.g. "Publish Perimeter FTP Server to Internal and External", in the Next Window you enter the IP Address of the Server, e.g. 188.8.131.52, next you select the FTP-Server Protocol. Then you select on which networks and which IP-Addresses the ISA Server will listen for requests intended for the published FTP Server.
On the Next Page you Finish the Wizard and Apply the changes.
That's easy, isn't it?
Now you want to verify the access to the FTP Server.
You first check the access from External to IP 192.168.101.15, works fine.
Next you want to access the Server from your Internal network using IP 184.108.40.206... it doesn't work.
But why? You start troubleshooting, looking at the ISA Live Logging, and realize, that no ISA rule matches the requests and therefore the request is denied.
On the ISA Server start a command window (Start, Run, cmd), and check if there is a socket Listening to Port 21 using the command netstat -an | findstr 21
The Output shows, that there actually is a Listening socket for the configured External IP, but no socket for your Internal IP.
ISA Server provides a tool called fwengmon to analyze and troubleshoot firewall connectivity issues by monitoring ISA Server in kernel-mode driver (fweng.sys) (ISA 2006: http://www.microsoft.com/downloads/details.aspx?familyid=01fc5551-5d44-4a99-966a-bd86caeb43d7 or ISA 2004: http://www.microsoft.com/downloads/details.aspx?FamilyID=F3306399-D4F9-4989-865E-C61F8293C330).
You execute fwengmon.exe with the /C parameter to check the created objects and receive output similar to this:
The output shows, that ISA has created one socket for 220.127.116.11:21 (FTP Server IP) and one for your external IP 192.168.101.15:21, but no socket for your internal IP. This is called ISA 'port stealing' and represents the route relationship for the traffic.
Does ISA simply ignore the complete publishing rule? Why is there no internal socket, and why can ISA Server create sockets for IP Addresses not configured on ISA?
The Answer: ISA will only create sockets and bind them to ISA Servers owned IP-Addresses for Non-Web Server Protocol publishing rules when there is a NAT relationship between those networks.
If ISA recognizes that there is a route relationship between the networks ISA will not create a socket for the Server IP Address you want to publish. Therefore the access will work when you try to directly connect to the Server IP Address 18.104.22.168:21.
!NOTE! The Web Listener used for Web publishing will always include the ISA Web Proxy Filter. Because an application proxy mechanism such as the Web Proxy Filter creates a completely new connection between ISA and the published server, and because the default for Web Publishing rules is to “Use the ISA computer IP address” when creating these connection. Thus, ISA appears to perform NAT on the traffic between the client and server, because it creates sockets for its configured IP Addresses even if there is a route relationship between the networks.
Question - But for all that, is it possible to publish my FTP Server without changing the network relationship between Perimeter and Internal to NAT?
Answer - Yes, you can do this ;-)
To solve the issue, you have to create a new network rule.
1. Navigate to Configuration, right-click Networks and select New -> Network Rule.
2. Choose a Name, e.g. "Internal to Perimeter FTP Server"
3. Add the FTP Server to the Sources. Click Add, New/Computer and create a Computer Object for your FTP Server. Then select this Object to add it to the Sources.
4. Add your Internal network to the destinations.
5. Configure a Network Address Translation (NAT) relationship.
6. Finish the Wizard and verify that the new rule order is lower (numerically) than the rule defining the route relationship between Perimeter and Internal. Apply the changes.
7. After the changes have been applied, you can use fwengmon to verify that the socket has been created in Kernel Mode and use netstat -an to check if there is a listening socket.
You can see, that the socket for the 22.214.171.124:21 disappeared and a new socket for 126.96.36.199:21 is created.
8. When you verify the access from your Internal, you'll see, that you now can connect to the 188.8.131.52:21 and that the correct rule is being matched.
Philipp Sand | Support Specialist ISA Server
Thanks for the guide, helped me alot!
Good info. Thanks for posting this case .