"Joe Pearse" <[EMAIL PROTECTED]> wrote:
> That's just it, though. Take the firewall out of the equation, and the
> application works fine. I understand that the destination port is what
> matters, and it does; you're right about that. Let me describe a scenario,
> to see if this helps explain the problem.
>
> I'm running tomcat + application at location A, you're running the same
> application + tomcat at location B.
>
> Scenario 1) You, site B, have no firewall restrictions. I, site A, send
> you, site B a message to port 443. Application does its thing, and sends a
> confirmation message, on _your_ local port, between 1024-5000. The
> destination is port 443 of site A. I receive the confirmation, and everyone
> is happy.
>
> Scenario 2) Now, your new security guru puts the clamps down on all
> outbound ports at site B. Taking the same scenario as 1), all works fine
> UNTIL you, site B, tries to send the response. Because all outbound ports
> have been blocked, the message does not get back to site A.
>
> Having said all that (sorry so long), at site B, you convince your security
> guy to open ports 2000-2005 (for example). What can I alter to guarantee
> that messages will be sent out on these ports? Thanks again for your help.
Yes, tipical scenario used in business process... Use the constructor I
mentioned and tell the security folks to open connections on this socket:
Local (B) IP:2000-2005 -> Remote (A) IP:443
And don't forget to write the appropriate outbound connection queue...
Pier
