I think this is the server IP (where listener is running): 192.168.155.67
If so then try execute this command on client as following:
telnet 192.168.155.67 1521
Now, we've got three options:
1. Connection refused
Reason: listener is not running or firewall has rejected our connection
2. Nothing (connection hung)
Reason: firewall has droped our connection
3. Got escape character - connection is available
To check wheter listener is running execute "lsnrctl stat"
To stop firewall on Linux login as root and execute following command "/etc/init.d/iptables stop".
For disbling of FW permanently (will not start during next boot) - execute "setup" and disable iptables in "System services"
BTW: It's generaly byd ide to check connection via ping or traceroute utilility. Use telnet instead.
Because ICMP != TCP
Supposing that the listener is running on port 1521 this sounds like a firewall issue. You could verify that the firewall supports the Oracle Net (SQL*Net) protocol. If not you could solve this by using shared servers (formally known as MTS). You can determine the port then.
With MTS (Shared Server) the listener hands over the request to dospatchers. These dispatchers can be registered on static ip ports (eg 5123, 5124, etc). What happens is that with a normal sqlnet connection the server will reopen a connection on a random port. This it what the firewall might not understand. here a little schema:
client ----> listener on 1521 ----> server process ---> opens random port ----> client
client ----> listener ----> shared server process on a fixed port ----> communicates via fixed port ----> client
The only thing that rest is to open the fixed port in the firewall.
Yes using DISPATCHERS on static ports will help, when you connecting directly to them (ommiting the listener).
But you didn't mentioned about this fact in your previous post.
My primary idea was "problem with iptables" ecause many people don't know that default install of RH is starting with iptables which blocking incoming conenctions to port 1521.
This it what the firewall might not understand
This is not SQL*Net problem (or that FW does not understand SQL*Net) but this is port redirections (FW) problem.