Re: [openjms-user] Client JMS Applet through a port forwarding firewall

[Ken M <wg...@fl...>]

Tim -

I've modified the server xml to do as stated, but it still doesn't quite 
work as expected.

The reason is that when an unsigned Applet tries to connect to a server 
that isn't the server the Applet's host - it isn't an IOException that 
is thrown
(as coded in IpcJmsServerStub.createClientConnection()), but a 
java.security.AccessControlException instead.

Solution 1) We sign the applet.. shh..
Solution 2) We modify IpcJmsServerStub.createClientConnection to catch 
all exceptions on createClientConnection() and try the internal host if 
it's not null anyhow. 

Thoughts?

K




Tim Anderson wrote:

> I think you're after the internalHost attribute of <TcpConfiguration/>:
> http://openjms.sourceforge.net/config/reference.html#TcpConfiguration
>  
> -Tim
>  
>  -----Original Message-----
> *From:* ope...@li... 
> [mailto:ope...@li...] *On Behalf Of *Ken M
> *Sent:* Saturday, 22 January 2005 9:53 AM
> *To:* OpenJMS User
> *Subject:* [openjms-user] Client JMS Applet through a port forwarding 
> firewall
>
>     Hey guys -
>
>     I have a client applet that has been JMS-enabled.
>
>     The server runs inside the DMZ on a 172.18.XX.XX network.
>
>     The external IP is forwarding the JNDI and JMS ports (3030 / 3035)
>     properly.
>
>     Now.. I have servers and clients needing to connect internally (on
>     the 172.18.XX.XX) and externally (on the external IP forwarded
>     thru a firewall).
>
>     I have set the applet JMS's PROVIDER_URL to 
>     tcp://ex.ter.nal.ip:3035 (by way of
>     Applet.getDocumentBase().getHost()) in order to get the ball
>     rolling.. Which it does nicely.
>
>     All seems well until the client on the Outside tries to connect,
>     and he receives an error that he can't get his JNDI connection -
>     access denied / connection refused on the internal IP address.
>
>     ...
>     SEVERE: Can not create TopicConnection.
>     javax.jms.JMSException: Failed to create connection:
>     java.security.AccessControlException: access denied
>     (java.net.SocketPermission 172.18.XX.XX:3030 connect,resolve)
>         at
>     org.exolab.jms.client.mipc.IpcJmsServerStub.openConnection(IpcJmsServerStub.java:338)
>         at
>     org.exolab.jms.client.mipc.IpcJmsServerStub.createConnection(IpcJmsServerStub.java:197)
>         at
>     org.exolab.jms.client.JmsConnection.<init>(JmsConnection.java:189)
>         at
>     org.exolab.jms.client.JmsTopicConnection.<init>(JmsTopicConnection.java:81)
>         at
>     org.exolab.jms.client.JmsTopicConnectionFactory.createTopicConnection(JmsTopicConnectionFactory.java:113)
>         at
>     org.exolab.jms.client.JmsTopicConnectionFactory.createTopicConnection(JmsTopicConnectionFactory.java:10
>     ...
>
>
>     This erroneous IP tracks this configuration line in openjms.xml:
>
>     <ServerConfiguration host="172.18.XX.XX" embeddedJNDI="true" />
>
>
>     If I change this to the external IP, internal clients can't
>     connect and vice versa.  I'm assuming that the initial connection
>     to the OpenJMS server on port 3035 serves up some kind of
>     configuration (InitialContext in this case) to the next stage of
>     the connection on port 3030.  Instead of using the IP that got us
>     to the server in the first place, it's returning the IP in the
>     config file - thus hosing all attempts to connect further.
>
>     As I write this my developers tell me there's another issue -- if
>     we change the host to the external IP - the applet doesn't
>     complain durining initialization, but it never receives any
>     messages now.
>
>     Again -- internal is fine, external is hosed.
>
>     Any ideas?  Did I miss a port?  Is there a way to STOP OpenJMS
>     from serving up the ServerConfiguration IP address to clients - as
>     this seems to be the source of the issue.  Is there a way to poke
>     the JMS client to tell it the REAL address of the server?  Can a
>     server have multiple <ServerConfiguration> lines?  One for
>     internal one for external?
>
>     As far as I can tell, this limitation means that the OpenJMS
>     server can only reside on a single homed machine without a
>     firewall that port-forwads traffic.  -- Somehow I have to believe
>     I missed something.
>
>     Ken
>