Open ports on Linux server

[DaJo]

Hi,

I have a RHEL 5 Server, and would like to open the following ports:
15701
15702
1521

I tried a few things, including:
1. iptables -A INPUT -p tcp --dport 1521 -j ACCEPT
2. service iptables save
3. service iptables restart

Output:
Flushing firewall rules: [ OK ]
Setting chains to policy ACCEPT: filter [ OK ]
Unloading iptables modules: [ OK ]
Applying iptables firewall rules: [ OK ]
Loading additional iptables modules: ip_conntrack_netbios_ns [ OK ]

However, when I try telnet to this machine on port 1521 (remotely), it doesn't work:
remote machine%
telnet: Unable to connect to remote host: Connection refused

remote machine% telnet 22
This works.

Please help.

Thanks.

[Steven Schweda]

> [...] would like to open the following
> ports:
> [...]

I never know what peopke mean when they say
this.

> [...] Connection refused

This normally means that there's no server
program listening (or registered to listen)
at the requested port. If you want some
server program to listen at this port, then
you need to install and configure it. Whom
do you expect to be listening at these ports?

[Michal Kapalka (mikap)]

hi,

normally the port 1521 is used for oracle listener, did you start the listener ???

mikap

[Ivan Ferreira]

Use netstat -an | grep LISTED to identify if the port 1521 is in the LISTEN state. If don't, then you won't be able to connect as the service for that port is not started (oracle listener).

As we don't know your previous rules, you may want to try just stopping the service for troubleshoot purposes.

service iptables stop
telnet host 1521

If that works, then your firewall is the problem, if don't, then the firewall is not related.

[DaJo]

Thanks for the input. The stmt "open port" might sound quite generic, but here are some more details:

Source machine A (windows server)

Runs a service that connects to machine B on port 15701
-- this is not related to the oracle listener

Target machine B (Linux server)

Needs to allow connections via port 15701 from Source machine A

I'm trying to find out the best way to achieve this, and the first thought is to make sure "machine B" is equipped to allow connections on port 15701

[Steven Schweda]

> Target machine B (Linux server)
>
> Needs to allow connections via port 15701
> from Source machine A

Ok. Who's stopping it?

> However, when I try telnet to this machine
> on port 1521 [...]

I see where you tried to get to port 1521.
I see nothing about any test of port 15701.

> [...] Whom do you expect to be listening at
> these ports?

Still wondering...

> -- this is not related to the oracle
> listener

Ok. So, WHAT _IS_ IT RELATED TO?

> [...] the first thought is to make sure
> "machine B" is equipped to allow
> connections on port 15701

_My_ first thought would be to make sure that
someone (server program) on "machine B" is
listening on port 15701. Then, if I got an
error message other than "Connection
refused", I might start worrying about some
firewall (like, say, iptables) getting in the
way.

[Steven E. Protter]

Shalom,

Diagnostic:

nmap hostname

This will show open ports.

iptables -L

This will show current firewall configuration after your changes.

Note:
remote machine% telnet 22
Should not work. Port 22 is not open.

SEP

[DaJo]

Steven S and Steven P

Thanks for working on this with me. I'll try my best to convey more details, hopefully it helps.
Here's the output for the two commands:

# nmap hostname

Not shown: 1675 closed ports
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
111/tcp open rpcbind
631/tcp open ipp
926/tcp open unknown

Nmap finished: 1 IP address (1 host up) scanned in 0.068 seconds

# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

With regards to error msgs, I get the same "connection refused" for all three ports via telnet: 15701, 15702 and 1521. I just mentioned one error msg with 1521.
I just chose telnet since I understand that's the sure fire way of testing if a port is open.

There is a security software agent/service that runs on source machine A, that needs to connect to ports 15701 and 15702 on target machine B.

From source machine A, when I try a
# telnet machine B 22

Escape character is '^]'.
SSH-2.0-OpenSSH_4.3

basically it works...in the sense that the port looks open. Also, I can ssh from machine A to machine B, so the port is open I presume.

If the ports are open on machine B, shouldn't we see the same result for:
# telnet machine B 15701
and
# telnet machine B 15702

telnet: Unable to connect to remote host: Connection refused

Are you saying that a corresponding service has to run on machine B as well? in order for the ports to be open on machine B?
We actually don't have a service defined that way on machine B, rather everything is handled by the service on machine A. It needs the port open on machine B so it can connect to machine B, complete some process (say sending log/audit info) and then closes it.

Thanks for your help.

[Steven E. Protter]

Shalom again,

Try testing port 22 with ssh, instead of telnet.

ssh -vvv hostname.

SEP

[Steven Schweda]

> Try testing port 22 with ssh, instead of telnet.

Why? The Telnet test works just fine. And,
there's apparently a working SSH server
listening at port 22 (as usual).

> If the ports are open on machine B, [...]

That depends on what you mean by "the ports
are open". As I tried to explain before,
"Connection refused" normally means that you
can talk to the server system, but that
there's no server program listening at the
requested port number. It doesn't matter if
no one is blocking the network traffic, if
no one is listening at the far end. For
example, if you kill the "sshd" process on
the server, then your SSH test should also
fail with a "Connection refused" complaint.

> > [...] Whom do you expect to be listening at
> > these ports?
>
> Still wondering...
>
> > -- this is not related to the oracle
> > listener
>
> Ok. So, WHAT _IS_ IT RELATED TO?

I'm tired of asking.