Re: Server not listening

From: Andy Shellam <andy(dot)shellam-lists(at)mailnetwork(dot)co(dot)uk>
To: Joris Dobbelsteen <Joris(at)familiedobbelsteen(dot)nl>
Cc: George Heller <george(dot)heller(at)yahoo(dot)com>, pgadmin-support(at)postgresql(dot)org
Subject: Re: Server not listening
Date: 2007-04-25 19:24:54
Message-ID: 462FAB06.3050103@mailnetwork.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-support

I concur, but just so you know I suggested SSH so George can get up and
running quickly while diagnosing the problems later as it requires a lot
of information he doesn't seem to have. We've already established he
has SSH access so it seemed an obvious way to connect so he could
actually begin to use PostgreSQL.

I've asked questions about the firewall before, to which George doesn't
appear to know much about the way the server is set up so I'm guessing
its been set up by somebody else, hence I suggested George try and find
out how/who configured the network between himself and the server.

George reported that a telnet from the server's console to the server's
remote IP address and PostgreSQL port connects, therefore that shows
PostgreSQL is running.

A ping and SSH from the XP machine to the server works, so it appears an
outgoing firewall on the Windows machine is not the problem (as you say,
few firewalls block outbound traffic.)

I'm fairly certain it's a firewall issue, either on the server itself,
or on an intermediate router/switch.

As George doesn't appear to have any information about these, I'm
guessing it's out of his control.

Andy.

Joris Dobbelsteen wrote:
> Adding SSH makes the mix makes it all slightly more complicated. Now
> let us first find where its going wrong:
>
> If I scan the previous e-mails I come up with the following (please
> correct me if I'm wrong!!!):
>
>
> 1.
> Your postgresql server (linux) and client (XP) are on different
> machines.
> 2.
> The server and client are on different subnets, meaning there
> must be at least one router inbetween.
>
> On the server (Linux):
>
> *
> The server is actually running (the 'ps' output gives this
> evidence).
> *
> On the server you can connect to 5432 port on the remote IP.
> This gives the evidence that the postgresql server is listening
> here.
> *
> Which Linux distribution you happen to use?
>
> On the client (XP):
>
> *
> It cannot connect to the postgresql server.
> *
> The firewall is disabled (though the WIndows Firewall does not
> block outgoing connections).
>
> Intermediate systems:
>
> * The MUST exist (since server and client are not in the same
> subnet). But no information is known about these.
> * There is a working path between the client and server (since we
> can do some things).
> * Not under George its control(?)
> Seems this way, not sure, may, or may not, be important...
>
> Please ensure the above assertions are valid, they are important for
> diagnosing where the problem is.
> I think the next best step is to identify what your network looks like:
>
> On the XP machine execute the following two commands in the DOS prompt:
> "ipconfig /all"
> "tracert <postgresql server>"
> "telnet <postgresql server> 5432"
> (How fast do you get a response, within ~5 seconds or it takes longer?)
>
> On the XP machine, see if you have any firewall installed. This is
> current a great pain in several situations. Other software that might
> interfere is:
>
> * Network Associates McAfee Virus scanner (8.0 and onward)
> * Network Associates McAfee Firewall
> * Symantic Internet Security
> * Kapersky
> * ZoneLabs
> * ...
> * ...
>
>
> On the Linux server:
> "ifconfig"
> "tracepath <client>"
> "iptables -L"
>
> On the linux server start the following while trying to connect:
> "tcpdump port 5432"
> For each test, include wheter you see no, few or a lot (more than a
> screen) of packets. You should also see the word ack a lot of times.
>
> I would really consider picking up one of the boxes and putting them
> on the same subnet. This reduces the complexity caused by the
> intermediate systems and might reduce the problem to the intermeidate
> systems only.
> Alternatively pick any box on the server its network and do a telnet
> to <postgresql server> at port 5432. If this works, the problem is
> most likely in the intermediate systems (or client).
>
> Also try it from your own client at its current location. Ensure that
> during tries the tcpdump tool is running.
>
> Hopefully this leads us a little closer to finding the actual problem.
> I have the strong feeling that either the server has the firewall
> configured or, more likely, that any intermediate system doesn't
> forward this traffic.
>
> - Joris Dobbelsteen
>
>
> ------------------------------------------------------------------------
> *From:* pgadmin-support-owner(at)postgresql(dot)org
> [mailto:pgadmin-support-owner(at)postgresql(dot)org] *On Behalf Of
> *George Heller
> *Sent:* woensdag 25 april 2007 18:05
> *To:* andy(dot)shellam-lists(at)mailnetwork(dot)co(dot)uk
> *Cc:* pgadmin-support(at)postgresql(dot)org
> *Subject:* Re: [pgadmin-support] Server not listening
>
> Hi,
>
> Thanks for that mail. I tried to follow the steps to create a
> tunnel, but when I add the connection, I dont really see an option
> to Save the settings. So make the changes and log in to my server
> with the actual hostname, it logs me in. I open another session on
> Putty, and the changes I made in the port forwarding are gone, I
> make the changes again, and try to log in using 'localhost' this
> time, it says Connection refused.
>
> I also tried logging into PgAdmin using localhost, but it gave me
> the same error as before, only this time it said ip address 127.0.0.1
>
> Thanks.
> George.
>
> */Andy Shellam <andy(dot)shellam-lists(at)mailnetwork(dot)co(dot)uk>/* wrote:
>
> [snip]
>
> !DSPAM:37,462fa73a89291812814777!

In response to

Responses

Browse pgadmin-support by date

  From Date Subject
Next Message Andy Shellam 2007-04-25 20:30:20 Re: Server not listening
Previous Message Joris Dobbelsteen 2007-04-25 19:09:28 Re: Server not listening