Forefront Edge Security TechCenter >
Forefront Edge Security Forums
>
Forefront Edge Security - Publishing
>
WCF NET.TCP Through ISA 2006
WCF NET.TCP Through ISA 2006
- I'm currently working on a proof of concept for a application that has been written to use the NET.TCP protocol using WCF. We're currently looking at configurations that would allow us to make those URL's (net.tcp://external.host.name:8820/Blah) available externally and then allow them to connect through to the internal host using the ISA basically as a port proxy. I currently have our ISA system configured using a Perimeter configuration. I've defined the new protocol as well as a non-webserver publishing rule. In the firewall logs I basically get the following:
8820 Unidentified IP Traffic (TCP:8820) Denied Connection Default rule 192.123.123.160 External Local Host
The configuration we have would basically result in the external hostname resolving to the Perimeter IP address on the ISA. Internally the IP on the second network interface in the ISA is in the internal range of IP's. The ISA internal IP is on the same subnet as the internal server hosting the WCF services. Based on the error in the log I'm under the assumption that the ISA is not really listening to port 8820 despite the listener configuration that is setup to do so. Any connection (external or otherwise) basically results in a failure and it never picks up the correct firewall rule that has been defined.
I've yet to really find a net.tcp example configured through an ISA to work from. This is my first real in depth exposure to the ISA itself, so if I've made some newbie mistake feel free to let me know where I likely went wrong in the configuration.
Thanks in advance.
Answers
- Just one default gateway. The proof of concept has about 10 servers actually working off the same VM host but we're using one range of IP addresses and excluding those that the ISA shouldn't be routing. There are ranges of IP's that are considered external and internal with a firewall on the back end that is allowing only point to point traffic through. I had that firewall turned off so that there was no blockage during the testing and that did not make a difference either. I ultimately undid all of the craziness just do do straight telnet and that did not work either. It only started behaving after rebooting the server. There were no other changes between yesterday and today other than the restart. Either way, it's working quite well now.
- Marked As Answer bySteve Dertien Wednesday, October 14, 2009 9:09 PM
All Replies
If i get this right you try to use non-web publishing.
In that case you have to define a new protocol definition for INBOUND TCP 8820 to use in the publishing rule.
Maybe you forgot to make the protocol "Inbound"?- I did create a new protocol called NET.TCP with inbound TCP 8820. What I think is happening is that the external network is making the proper connection to the Perimeter IP. What I'm not getting my head wrapped around at the moment is how the ISA takes in the request on the perimeter and then sends it out on the internal IP to the target host that is mapped in the non-web publishing rule. I did a packet capture on all the interfaces involved and I clearly see the calls going from the client to the perimeter IP. Something in the ISA is blocking that incoming request and it's not initiating itself over to the internal IP at all. I'm still trying to see if it's a Network Rule that's not correct or a Firewall rule that is simply missing that the publish rule did not create.
- I've done some more checking this evening and as best as I can tell when I publish ANY non-http based server it fails to create the corresponding listener. This essentially results in a rule created with no port. All the port denials by the client are the result of nothing to receive and relay the request across. When I do a netstat /an I can clearly see all the inside and outside IP's with their registered listeners. I went so far as to test publishing telnet to the same host and even that configuration does not work yet publishing a web rule to the same host works fine.
- Non-web publishing is designed for NAT relations
(Please read the following http://technet.microsoft.com/en-us/library/dd547089.aspx for details)
What is the relation on ISA between "Internal" and "External"..
Its hould be Internal -> External NAT...
..and your rule "listens" on one IP on the "External" and the published server is one IP in "Internal" - I've used the standard 3-Leg perimeter template. There are 5 network rules as follows:
- Local Host Access - Route - Local Host to All Networks (and Local Host)
- VPN Clients to Internal Network - Route - Quarantined VPN Clients and VPN Clients to Internal
- Perimeter Configuration - NAT - Internal + VPN Clients to Perimeter
- Perimeter Access - Route - Perimeter to External
- Internet Access - NAT - Internal + VPN Clients to External
Can you please provide details on IP ranges on networks and IPs used by published server as well as client from wher you try access the published server.
I fail to understand the traffic pattern in your scenario ;-)I think it should look like this
External client -> External IP of ISA -> Published server in Internal Network
The Perimeter Network of the ISA is not used as far as i can understand.On your publishing rule you should have the following settings:
Action: Allow
Traffic: The protocol you defined as Inbound TCP 8820
From: Anywhere
To: The IP of the server on the Internal Network that hosts the service
Networks: Selected "External" and selected the IP that public DNS resolves to.Please let me know if you have other settings.
- The Perimeter IP is configured as .100
The internal IP on the ISA is .104. The server that I'm publishing to is .104. The internal IP range includes the defaults as well from 0.0.0.1 to 126.255.255.255, 128.0.0.0 to the beginning of our IP range. I've included just a small subset (only 5 IP's) of our IP range. The internal IP range basically includes .99, .101 to .104. The IP range then starts at the end of our range all the way out to 223.255.255.255 and 24.0.0.0 - 255.255.255.254.
The external IP's are basically all other IP's that are not in that range obviously.
The publishing rule is as follows:
- Allow
- NET.TCP (8820)
- From Anywhere
- To .101 (I've attempted both forwarding rule types, neither made a difference)
- The Listener is External, Internal and Perimeter
The irony is I rebooted the server twice this morning for a completely different reason. The ISA now recognizes the NET.TCP protocol that I created and everything now appears to be working fine. Very strange, but something must have been cleared up after restarting the system at some point. - looks like you have or had multiple default gateways on your ISA.
and... you look to have some crazy IP and routing settings on your ISA box :-) - Just one default gateway. The proof of concept has about 10 servers actually working off the same VM host but we're using one range of IP addresses and excluding those that the ISA shouldn't be routing. There are ranges of IP's that are considered external and internal with a firewall on the back end that is allowing only point to point traffic through. I had that firewall turned off so that there was no blockage during the testing and that did not make a difference either. I ultimately undid all of the craziness just do do straight telnet and that did not work either. It only started behaving after rebooting the server. There were no other changes between yesterday and today other than the restart. Either way, it's working quite well now.
- Marked As Answer bySteve Dertien Wednesday, October 14, 2009 9:09 PM
- Glad it start working, maybe there was some IP-binding issue that was solved when you restarted.
If you think your issue is solved please set the thread to answered/solved
