Intro
I have to give credit to my colleague “Ben” for cracking this case, which left me scratching my head. Users at drjohns were getting new Windows 7 PCs and some of the old software wasn’t going to run on those new PCs, including our indirect tax sales and use software from Thomson Reuters. The new approach is SaaS – software as a service. The new package was approved and everyone thought it was going to work fine, until late in the game it was actually tested. They couldn’t bring up their old tax returns. So at the last hour they bring in the Internet experts.
The Details
At drjohns our users are insulated from the Internet by proxy servers. There are no direct routes. It’s private address space and an explicit proxy connection to browse out to Internet. 99% of the time this works fine. And it sure is a secure way to go. But those exceptions can be quite a headache. This case is a very typical presentation of what we see, though the particular solution varies case by case.
We get detailed network requirements. They usually talk about opening up the firewall to certain servers, etc. We always patiently explain that the firewall is open – to the proxy! The desktops have no Internet routes, nor can they resolve Internet domain names. That’s right we have private root DNS servers. Most vendors have never encountered this setup and so they dig in their heels and insist that the only way is to ‘open the firewall…”
This case was no different, except we didn’t actually talk to the vendor. But their requirements were crystal clear in this networking document. Here’s the snippet that would seem to be fatal given our Intranet architecture:
RS APPLICATION SERVERS The ONESOURCE Sales & Use Application Servers use TCP/IP communications from the client PC to the Server. The requirements for communications with the ONESOURCE Application Servers are itemized below: - DNS Name Resolution is not used for the Application Servers. - Proxy Server access to the Application Servers is supported ONLY in transparent mode. The Proxy Server must not translate the TCP/IP address of the Application Servers. PCs must be able to establish a connection using the actual TCP/IP address and port numbers of the Application Server without application “awareness” of a Proxy Server. - Network Address Translation (NAT) is supported for the client addresses but is NOT supported for the Application Server addresses. - Connections are outbound only from the client to the server. - Security policies, firewall rules, proxy rules and router packet filters must allow outbound connections (and inbound replies) on destination port 2429 to the Class “B” network address 164.57.0.0. when using the non-WCF application servers. If the client’s account has been configured to use Windows Communications Foundation or WCF, there are no additional port requirements. The source port selection uses standard port numbers 1024 and above. |
The application installs about 10 ActiveX controls and it wouldn’t run on my desktop. Ben managed to get it to run using the OpenText socks client. It has an option to “socksify everything else” which he says proves to be very useful when you don’t know what specific application to socksify. So now let me repeat what I have just said: Ben got it to work without any changes to the firewall, ignoring all the vendor’s advice and requirements!
I was very pleased as this was getting to be a high-priority issue what with these sales and use taxes due each month.
But Ben didn’t stop there. He came up with even better solution. He said he was looking around at the folder where all the stuff is installed by the application. He noticed a file called ConfigProxy. He configured it to use the system proxy settings. Then he exempted the target site from proxy authentication. Lo and behold that worked as well, with no socksification required at all. We only socksify an app as a last resort.
This latest finding completely contradicts the vendor’s stated network requirements. But it’s better this way.
We now have a happy tax department. Case closed.
Conclusion
Vendor network requirements are not always what they seem. Clearly they are not testing in the more obscure environments such as a private Intranet with an independent namespace that connects to the wider Internet only via explicit proxy. If you’re in this situation, which offers some serious security advantages, there are things you can do to get demanding applications to work.