Problems connecting to Teiid behind firewall hosted on virtual machine

[benjes]

Hi,

I am having problems connecting to teiid which is running behind a firewall on a virtual machine (on Windows).

The port 31000 is open so that should be the problem. My client (JBoss AS) can initially connect but then gets

either a EOFException or a time out reading from the socket. There is nothing in the teiid logs.

A packet sniffer gives me this:

SYN

ACK, SYN

ACK

ACK, FIN

while on a connection to my local test installation I get:

SYN

ACK, SYN

ACK

ACK,PUSH

ACK

ACK,PUSH

...

So it seems teiid (or the virtual host?) is closing the connection straight away. Does anyone have some experience with running teiid on a virtual host or behind a firewall?

Is this likely a problem with teiid or with the network setup?

Thanks for your help

Regards

Immo

[rareddy]

We have tried both scenarios successfully in the past. My guess would be network setup.

During the startup, depending upon what you have provided in "deploy.properties" as the host name, Teiid resolves this host name to create socket to accept the client connections. If this resolved address is different and not visible from out side the firewall, you will have issues in connecting to it. You can see resolved address in Teiid logs.

Please let us know what you find out.

Thanks

Ramesh..

[benjes]

Hi Ramesh,

just run a few tests and came accross this exception:

com.metamatrix.common.comm.exception.CommunicationException: DH KeyFactory not available

at org.teiid.transport.SocketClientInstance.receivedHahdshake(SocketClientInstance.java:128)

at org.teiid.transport.SocketClientInstance.receivedMessage(SocketClientInstance.java:140)

at org.teiid.transport.SSLAwareChannelHandler.messageReceived(SSLAwareChannelHandler.java:211)

at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:324)

at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:249)

at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:172)

at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:293)

at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:280)

at org.jboss.netty.channel.socket.nio.NioWorker.readIntoHeapBuffer(NioWorker.java:300)

at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:254)

at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:163)

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)

at java.lang.Thread.run(Thread.java:619)

Caused by: [CryptoException]DH KeyFactory not available

1 [NoSuchAlgorithmException]DH KeyFactory not available

at com.metamatrix.common.util.crypto.DhKeyGenerator.getSymmetricCryptor(DhKeyGenerator.java:120)

at org.teiid.transport.SocketClientInstance.receivedHahdshake(SocketClientInstance.java:126)

... 13 more

Caused by: java.security.NoSuchAlgorithmException: DH KeyFactory not available

at java.security.KeyFactory.<init>(KeyFactory.java:108)

at java.security.KeyFactory.getInstance(KeyFactory.java:142)

at com.metamatrix.common.util.crypto.DhKeyGenerator.getSymmetricCryptor(DhKeyGenerator.java:106)

... 14 more

2010-04-08 14:55:22,359 DEBUG [New I/O server worker #1-1] org.teiid.Server - Channel closed

Any idea what could cause it?

Regards

Immo

[shawkins]

Hi Immo,

Sun 1.5/1.6 VMs support DH as a valid KeyFactory algorithm name.  It looks like other VMs may use the full name DiffieHellman.  What VM are you using?  To workaround, if you are using SSL or if you don't care that the logon password is encrypted in transit, then you can set client.encryption.enabled=false

Steve

[benjes]

I am using Sun's (sorry Oracle's) JDK 1.6 and judging from the dump of security providers (attached) DH should be supported.

I've tried disabling client encryption and that worked but unfortunately I can't use that (the client doesn't want their data in the clear, strange :-)

I will try with SSL but I have the feeling that I will have the same problems. Could it be that the real problem is not that it can't find the DH algorithm but that it thinks something fishy is going on (with the server running on a virtual host, behind two firewalls and address translation).

Immo

[shawkins]

Yes, it sure looks like DH is aliased to DiffieHellman.  Is there any chance that jce jar is not in your classpath for running Teiid?

The client encryption setting only encrypts logon/admin traffic and leaves the data in the clear.  If the client wants the everything encrypted, then SSL is the way to go.

However, you are likely to run into problems with SSL unless you pick up the pending M3, since there were fixes related to SSL handling on the server side.

Steve

[benjes]

Thanks for the info. It wasn't clear to me that only the login was encrypted. The deploy.properties documentation wasn't clear about that.

May I ask what your definition of pending is? Is it imminent or just pending? Are we talking days, weeks month?

Regards

Immo

[rareddy]

We are talking hours at most days.. We found some performance issues we are fixing now. M3 should be out very soon. You can subscribe to teiid-users list here to get updates and follow the changes coming in the upcoming releases.