|
From: John H. <jh...@im...> - 2016-04-22 01:43:41
|
On Thu, 21 Apr 2016, Markus Metz wrote: > Hello John : > > You are the best!!! > > You hinted at the correct issue, Sir: > > The solution is that I needed to add the line > -A INPUT -p tcp --dport 5432 -j ACCEPT > to the /etc/sysconfig/iptables file. If your database server host can somehow be seen from the Internet, that opens your postgres server to the entire world. I'd strongly suggest something a little more limited, for example adding: -s 10.2.0.0/16 so that only traffic from your local network is permitted. (...assuming that your client is also on the 10.2.x.x network...) > Next 'sudo /etc/init.d/iptables restart'. > > Please note my firewall was not set up. > > Now I can see all data in my remote database. > > Again, thank you very much. You're very welcome. > Markus > > > On Thu, Apr 21, 2016 at 4:27 PM, John Hardin <jh...@im...> wrote: > >> On Thu, 21 Apr 2016, Markus Metz wrote: >> >> Hi John and others: >>> >>> I used nmap: >>> >>> nmap -p T:5432 localhost >>> >>> ouput: >>> Port state Service >>> 5432/tcp open postgresql >>> >>> So, the port should be reachable. >>> >> >> Please clarify this detail: are you also running squirrel on the server >> computer itself? I gather you're not from the discussion so far, please >> tell us explicitly. >> >> If you're not, run the nmap and telnet tests against the IP address >> Squirrel is configured to use, **from the client computer**. If you're not >> running Squirrel on the server, it's not relevant whether or not the server >> can successfully talk to itself via localhost. >> >> And if you *are* running Squirrel on the server itself, try configuring it >> to connect to 127.0.0.1 >> >> >> I executed the tcpdump command on the linux server and ran squirell. This >>> is the ouput: >>> >>> 14:36:32.1111111 IP hostname.58260 > hostname.postgres: Flags [S], seq >>> 1111111111, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], >>> length 0 >>> 14:36:35.222222 IP hostname.58260 > hostname.postgres: Flags [S], seq >>> 1111111111, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], >>> length 0 >>> 14:36:41.222222 IP hostname.58260 > hostname.postgres: Flags [S], seq >>> 1111111111, win 8192, options [mss 1460,nop,nop,sackOK], length 0 >>> >> >> Apologies, add "-n" to the tcpdump command line and you'll get port >> numbers and IP addresses rather than names. That may make it a little >> easier to interpret. >> >> It looks from that like the client is sending the initial packet of the >> three-way TCP handshake and is not getting a response from the server >> (there are no SYN/ACK packets in response). It retries twice more and gives >> up. >> >> However: this trace won't tell you if the server is sending ICMP port >> unreachable responses, which is what I would expect if you're seeing >> "connection denied" on the client end. >> >> Run the nmap and telnet tests from the client end and see if they report >> connectivity problems. And on the server run this tcpdump command to >> capture a little more info: >> >> tcpdump -n -i eth0 ip host ip.address.of.client >> >> Where "ip.address.of.client" is the client computer's IP address. >> >> Then try to connect again. >> >> I kinda expect to see the inbound TCP SYN (like above), and in response an >> ICMP port unreachable packet (which would explain the "connection refused"). >> >> Not sure what it means. Can you please help? >>> >> >> Check the firewalling on the server, it may not be configured to allow >> inbound traffic to the postgres port from that client / at all. >> >> >> Thank you, >>> Markus >>> >>> On Thu, Apr 21, 2016 at 2:33 PM, John Hardin <jh...@im...> wrote: >>> >>> On Thu, 21 Apr 2016, Markus Metz wrote: >>>> >>>> Java.util.concurrent.ExecutionException: java.lang.RuntimeException: >>>> >>>>> org.postgresql.util.PSQLException: Connection to 10.2.44.27:5432 >>>>> refused. >>>>> >>>>> >>>> Can you telnet to 10.2.44.27:5432 from the client? Granted you probably >>>> won't be able to talk the postgres protocol, but that would confirm >>>> whether >>>> or not you have basic network connectivity. >>>> >>>> Just to confirm that squirrel actually is attempting to connect: >>>> immediately after getting that error, on the client run a netstat >>>> command. >>>> You *should* see a TCP connection with the database server's IP/name and >>>> port number on the "far end". >>>> >>>> You could also run something like "tcpdump -i eth0 tcp port 5432" on your >>>> client (assuming *nix and needed privileges) to see whether it's trying a >>>> network connection. >>>> -- John Hardin KA7OHZ http://www.impsec.org/~jhardin/ jh...@im... FALaholic #11174 pgpk -a jh...@im... key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 ----------------------------------------------------------------------- The difference is that Unix has had thirty years of technical types demanding basic functionality of it. And the Macintosh has had fifteen years of interface fascist users shaping its progress. Windows has the hairpin turns of the Microsoft marketing machine and that's all. -- Red Drag Diva ----------------------------------------------------------------------- 2 days until Max Planck's 158th birthday |
