Обсуждение: [GENERAL] Connection loosing at some places - caused by firewall
Dear Members!
It's not PGSQL server based.
Windows 10, PGSQL 9.4 and 9.6 (Debian with SSL, and Windows without it - it doesn't matter).
When I (or my boss) work(s) at home, I got connection lost errors from PGAdmin (3/4) or from other applications too.
server closed the connection unexpectedlyThis probably means the server terminated abnormallybefore or while processing the request.
PGAdmin, EMS PostgreSQL manager, Navicat for PGSQL, and psql too.
When minimum 5 minutes passed after the last request (select, insert, or any communication what I did) the connection lost.
The keepalive timer is 10 minutes in the server - so it is not the source of the problem.
I tried to set keepalive in the clients (EMS, Navicat called ping) to lower - no effect.
When I did any request in my side before the 5 minutes "limit" passed, I got a new 5 minutes.
It seems to be libpq.dll applications need traffic (started by the client) in 5 minute periods to keep the connection.
In the office I don't have this limitation.
My colleauge can work at home without time limit, and he has same Internet Provider as mine.
My colleauge can work at home without time limit, and he has same Internet Provider as mine.
It's not PGSQL server based.
When I use VPN connection from home to reach office PG server, I also got this problem.
From the office I can use same IP, same server without problem.
From the office I can use same IP, same server without problem.
I checked the router, I disabled all things - nothing happened.
I disabled my firewall at home - the problem vanished!!!
And: if I use a secondary test computer (also Windows 10, PGAdmin III) - it works at home!!!
I very-very wondered because it seems to be computer firewall problem.
I tried to use wifi and direct cable - no differents, so network card could be eliminated from the "problem sources" list.
It's very interesting!
The firewall could make differents between networks and limits these packages timeout to 5 minutes? Hmmm...
I made an exception to the firewall - nothing happened.
I know this is not Windows Admin list, but you may experienced same problem, or you have idea about what to do.
This is become important for us because one of my customer have same problem, and we don't know the solution...
What is your opinion about it?
Thanks
dd
Hello!
2017-11-14 12:09 GMT+01:00 Durumdara <durumdara@gmail.com>:
Windows 10, PGSQL 9.4 and 9.6 (Debian with SSL, and Windows without it - it doesn't matter).When I (or my boss) work(s) at home, I got connection lost errors from PGAdmin (3/4) or from other applications too.server closed the connection unexpectedlyThis probably means the server terminated abnormallybefore or while processing the request.PGAdmin, EMS PostgreSQL manager, Navicat for PGSQL, and psql too.When minimum 5 minutes passed after the last request (select, insert, or any communication what I did) the connection lost.
For PGAdmin III I found a solution-like thing.
dd
On Tue, 14 Nov 2017 12:09:31 +0100, Durumdara <durumdara@gmail.com> wrote: >*I disabled my firewall at home - the [keepalive] problem vanished!!!* What firewall are you using? Windows own firewall doesn't interfere with keepalive packets. Most commercial SOHO firewalls won't either. George
Hello!
2018-02-13 21:21 GMT+01:00 George Neuner <gneuner2@comcast.net>:
On Tue, 14 Nov 2017 12:09:31 +0100, Durumdara <durumdara@gmail.com>
wrote:
>*I disabled my firewall at home - the [keepalive] problem vanished!!!*
What firewall are you using? Windows own firewall doesn't interfere
with keepalive packets. Most commercial SOHO firewalls won't either.
Normal Windows Firewall (Defender). An ASUS test notebook works. The DELL isn't.
So something is different in the FW on DELL. With manually defined (faster) keepalive it's working.
So something is different in the FW on DELL. With manually defined (faster) keepalive it's working.
dd
On Mon, 19 Feb 2018 13:02:30 +0100, Durumdara <durumdara@gmail.com> wrote: >2018-02-13 21:21 GMT+01:00 George Neuner <gneuner2@comcast.net>: > >> On Tue, 14 Nov 2017 12:09:31 +0100, Durumdara <durumdara@gmail.com> >> wrote: >> >> >*I disabled my firewall at home - the [keepalive] problem vanished!!!* >> >> What firewall are you using? Windows own firewall doesn't interfere >> with keepalive packets. Most commercial SOHO firewalls won't either. >> >Normal Windows Firewall (Defender). An ASUS test notebook works. The DELL >isn't. >So something is different in the FW on DELL. With manually defined (faster) >keepalive it's working. Keepalive is part of the TCP protocol - it's an ACK that repeats the last used packet sequence number. Under normal circumstances, the sequence number is incremented (modulo rollover) for each new packet. Keepalive is recognized as a deliberate and particular breaking of the packet sequence. Windows firewall has no settings pertaining to keepalive separate from the operating system. Once you have permitted TCP connections to the port or program, if any keepalive packets are sent, the firewall must allow them through. [Of course, both sides must agree on the keepalive settings for it to work, but that is a different issue.] It may be that your firewall is f'd up. The firewall doe perform "stateful inspection" of open TCP connections - essentially looking for protocol mistakes that may indicate intrusion hacks or replayed connections. It could be that the SI module is losing synchronization when the connection goes idle. [Back in the day, there were a number of SOHO NAT routers that had this and other problems with their stateful inspection code.] You can try running a system file check to see if something has gotten corrupted: https://support.microsoft.com/en-us/help/929833/use-the-system-file-checker-tool-to-repair-missing-or-corrupted-system You also can try resetting the firewall rules to default from the control panel. Of course then you'll have to reauthorize every program that requires a connection. for more information on how the firewall works, see: https://technet.microsoft.com/en-us/library/cc779199(v=ws.10).aspx Hope this helps, George