# Port opening

## Poloch

Hi,

I have a machine where I could not have irc work. Then if I try for instance: telnet irc.mozilla.org 6667", it just holds with "Trying 63.245.208.159...", then after some minutes "telnet: connect to address 63.245.208.159: Connection timed out".

So I guess this is a problem of ports closed on my machine. Note that my machine is directly connected to the Internet with an IP on its own. So there must not be any firewall/router issue, as far as I know. Would you have an idea for me, so that I diagnose and fix this issue better (I am a developper, but not a network admin and don't know so much about all these network configurations).

Thanks.

Jehan

----------

## slackline

I very much doubt its anything to do with the ports being open/closed on your machine.

My understanding is that any request that originates from your machine is permissible, so even if you have a firewall in place and have all ports closed, you can still connect to a given IP address on a given port providing that port is open on the machine that you are making the request to.  Its why you can have port 80 shut on your firewall yet still bowse web-pages.

Its also confusing that you mention IRC and then give an example of trying to telnet to the remote host (and btw you shouldn't really use telnet as it sends passwords unencrypted, far better to use ssh to connect to remote machines).

So are you trying to connect to an IRC server or are you trying to connect to a remote machine using telnet?

The IP address you give appears to be for a server owned by Mozilla (stick the IP address into here).

If its running IRC and you want to connect then you need to use an IRC client, and telnet is NOT an IRC client.  If you want an ncurses IRC client that runs in a terminal then 'emerge -av rhapsody' or select an alternative from 'eix irc' (most are listed under /usr/portage/net-irc/).

slack

----------

## Poloch

Hi,

thanks for the answer. I know what you are saying. I am not using telnet for connecting to the machine or for irc (my irc client is irssi), but for the test, because telnet is always a very good way of first diagnosis of network issues (as it is a very raw way of connecting to a remote host).

irc.mozilla.org is indeed the IRC server of the Mozilla foundation. And 6667 is the port used by IRC servers. I just checked that with a simple connection on this port, it fails... If you make this command from a machine, you should receive some answer from the server (just make the test on your own machine, you will see this). But here I don't even connect. And I try to figure why. This is where my expertise comes to some limitation...

Thanks.

----------

## scherz0

 *Jehan wrote:*   

> Would you have an idea for me

 

I think that most IRC servers perform some bot detection before accepting a connection.  This includes probing a list of well-known ports on the client.

So it could be that the server detects a bot (check the list of listening ports on your machine) or fails to achieve the tests (if you have a firewall dropping packets).

----------

## Poloch

Hi,

what you write scherz0 is also one of my thoughts.

On the web, I found for instance this FAQ:

 *Quote:*   

> 
> 
> Why do I get timeouts when I want to connect to IRC? This is a frequently asked question, so I will explain the most common cause for this problem: For security reasons the Furnet servers check the ports 80, 1080, 3128 and 8080 for open proxies to prevent abuse of these ports for attacks and spamming. Additionally all IRC servers use port 113 (ident) to check the user's identity. Some programs like personal firewalls, or real firewalls, block connections to such ports. If this blocking works using the "drop" method (the firewall does not react to connections on this port, not even denying access) the IRC server will wait until the timeout with each connection attempt. So the IRC server will close the connection, because the client did not respond in time. Of course the IRC server will deny any connection if an open proxy actually has been found.
> 
> What can I do against the timeouts? The easiest solution is to set the (personal) firewall to reject unwanted connections actively (REJECT) rather than just ignoring them (DROP, DENY). If an open proxy actually is found it has to be shut down before the IRC server will accept the connection.
> ...

 

So I tested this all with telnet connection. 80 is opened, but this is normal, I have a web server. 8080, 1080 and 3128 are rejected automatically. But the port 123 is indeed timing out (instead of rejecting the connection or whatever). So first question is: why is this port handled differently, knowing that I have no firewall on this machine, thus no rule depending on the port number? I don't have either any server listening on this port (and if so, it would not time out, but accept the communication).

Second question: is there a way to handle different this port (rejecting actively) without using a firewall (as it is said in the Gentoo doc, configuring badly a firewall is worse than not having one. For hat I use it for, I think it is better not having one on this small personal machine)?

Thanks.

----------

## scherz0

 *Quote:*   

> But the port 123 is indeed timing out (instead of rejecting the connection or whatever).

 

I guess you meant 113

Rejecting with an icmp-port-unreachable is the default, so there should be some reason for the time out.

netstat -ln gives the exhaustive list of listening ports.  Can you post that list ? (feel free to replace the effective address by x.x.x.x)

----------

## Poloch

Yes 113.  :Wink: 

Here it is:

```
# netstat -ln

Connexions Internet actives (seulement serveurs)

Proto Recv-Q Send-Q Adresse locale          Adresse distante        Etat

tcp        0      0 0.0.0.0:5280            0.0.0.0:*               LISTEN

tcp        0      0 0.0.0.0:5222           0.0.0.0:*               LISTEN

tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN

tcp        0      0 0.0.0.0:143             0.0.0.0:*               LISTEN

tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN

tcp        0      0 0.0.0.0:41936           0.0.0.0:*               LISTEN

tcp        0      0 0.0.0.0:4369            0.0.0.0:*               LISTEN

tcp        0      0 X.X.X.X:53      0.0.0.0:*               LISTEN

tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN

tcp        0      0 0.0.0.0:5269            0.0.0.0:*               LISTEN

tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN

tcp        0      0 127.0.0.1:953           0.0.0.0:*               LISTEN

tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN

tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN

udp        0      0 X.X.X.X:53      0.0.0.0:*

udp        0      0 127.0.0.1:53            0.0.0.0:*

[... Unix Sockets part ... ]

```

----------

## magic919

Maybe you could run a netstat in another term with -c option and grep 6667 to see that connection attempt.  You may already have checked iptables -L -n -v to be sure you don't have any rules on your machine.

I guess your ISP could block that port.  Try some other IRC servers, like efnet, perhaps.

----------

## scherz0

(You did check that each port in this list is legitimate, did you ?)

About the 113 time out... when you tried to connect to this port on your machine, did you monitor kernel log and network activity ?

A normal reject should look like 

```
17:13:05.177287 IP 127.0.0.1.42762 > 127.0.0.1.113: S 686145330:686145330(0) win 32792 <mss 16396,sackOK,timestamp 3249979[|tcp]>

17:13:05.177310 IP 127.0.0.1.113 > 127.0.0.1.42762: R 0:0(0) ack 686145331 win 0
```

----------

## scherz0

 *magic919 wrote:*   

> I guess your ISP could block that port.  Try some other IRC servers, like efnet, perhaps.

 

You could use tcptraceroute irc.mozilla.org 6667 to check that you reach the server.

```
...

21  sand.mozilla.org (63.245.208.159) [open]  193.686 ms * 194.494 ms
```

----------

## Poloch

Hi all,

I checked on my dedicated server provider's interface. In fact it is indeed blocking the IRC ports by default, I had to remove this block... Maybe a lot of bad stuffs happen through IRC ports, so that they prefer to deactivate the port by default?..

Anyway thanks. It was as stupid as this.

----------

## slackline

 *Poloch wrote:*   

> Hi all,
> 
> I checked on my dedicated server provider's interface. In fact it is indeed blocking the IRC ports by default, I had to remove this block... Maybe a lot of bad stuffs happen through IRC ports, so that they prefer to deactivate the port by default?..
> 
> Anyway thanks. It was as stupid as this.

 

 :Laughing:  its a bit of a circular argument, any default ports that are regularly 'open' will naturally attract the interest of those wishing to use them maliciously.

----------

