Yes, we encountered this same problem about a month ago, and by all accounts, it was the first time SAS had seen the problem. I'm not a network guru, but will try to explain the situation as best I can:

The problem occurs when a firewall is placed between the web server and the application server. Your client request makes it to the application server, and the request is processed. The return communication just doesn't make its way back through the firewall. SAS stated that one of the reasons they hadn't seen the problem earlier was that most installations had put the app server outside the firewall along with the web server.

Specifically, the problem occurs because of the way that SAS has designed communications to occur between ports. This is orchestrated by the broker.exe on your web server. Your app server is configured to 'listen' on port 5001. That is the only port exclusively 'hard-coded' in the entire process. The broker randomly selects the outgoing port from the web server (say, port 6931) upon a client request, and passes info on to the application server instructing the app server to respond back via a random outgoing port (not the incoming port, 5001) and to direct the return communication to port 6930 (n-1 from the outgoing web server port) of the web server.

This presents a major problem to the firewall software, since it has been instructed to only allow outgoing communication from a specific port from an IP address. It's likely that you don't want to open your firewall for every potential port that can be defined. That would alleviate the problem, but present other data security issues.

SAS has been working on developing a new broker package that will get around this problem.

If you want to discuss this matter further, contact me at: rcoughenour@highmark.com

Rick Coughenour