Friday, February 24, 2012

Connection broken

We have added a new firewall to our network and now I keep getting my
connection dropped when running from home. Port 1433 is open.
I am connecting via a VPN and it was working fine. Nothing has changed in
this respect. If I disconnect my Firewall at home and go to the internet
directly, I have no problems (but this firewall worked fine before and does
now sporadically).
Now, however, I can connect fine but my queries give me the following
message after about 30 seconds:
[Microsoft][ODBC SQL Server Driver][DBNETLIB]ConnectionCheckForData
(CheckforData()).
Server: Msg 11, Level 16, State 1, Line 0
General network error. Check your network documentation.
Connection Broken
This says I was connected, but now the Connection is broken.
If I were to give it an invalid command such as "who_is", I do get the
following results:
Server: Msg 2812, Level 16, State 62, Line 1
Could not find stored procedure 'who_is'.
This comes directly from Sql Server, so I know the my machine at home can
talk to the Server fine.
Why am I not able to query without losing connection?
Thanks,
Tom
I found out what is happening, but not why.
Apparently, Sql Server using UDP service 17 port 1434 for something.
I looked at my firewall settings and it is dropping my packets because they
are fragmented. It was confusing at first, because it worked fine without
the firewall. But what must be happening is that the data is being passed
on 1433 (which I would expect) and since there is no firewall to strip bad
packets it lets the fragmented packet through. For some reason, because of
this packet the connection is dropped (not sure what constitutes a dropped
connection) so I assume the actual response hasn't been sent yet and now it
can't send it because the connection is now gone (I think).
Anyone know why this is happening or what this port (1434) is used for? I
knew about 1433, but this is the first I had heard about 1434.
Thanks,
Tom
"tshad" <tscheiderich@.ftsolutions.com> wrote in message
news:ewYccw6QGHA.5808@.TK2MSFTNGP12.phx.gbl...
> We have added a new firewall to our network and now I keep getting my
> connection dropped when running from home. Port 1433 is open.
> I am connecting via a VPN and it was working fine. Nothing has changed in
> this respect. If I disconnect my Firewall at home and go to the internet
> directly, I have no problems (but this firewall worked fine before and
> does now sporadically).
> Now, however, I can connect fine but my queries give me the following
> message after about 30 seconds:
> [Microsoft][ODBC SQL Server Driver][DBNETLIB]ConnectionCheckForData
> (CheckforData()).
> Server: Msg 11, Level 16, State 1, Line 0
> General network error. Check your network documentation.
> Connection Broken
> This says I was connected, but now the Connection is broken.
> If I were to give it an invalid command such as "who_is", I do get the
> following results:
> Server: Msg 2812, Level 16, State 62, Line 1
> Could not find stored procedure 'who_is'.
> This comes directly from Sql Server, so I know the my machine at home can
> talk to the Server fine.
> Why am I not able to query without losing connection?
> Thanks,
> Tom
>
|||UDP 1434 is the SQL Server Resolution Service used to find
what port number a named instance is listening on.
You can find more information in the following articles:
INF: TCP Ports Needed for Communication to SQL Server
Through a Firewall
http://support.microsoft.com/?id=287932
How to use static and dynamic port allocation in SQL Server
2000
http://support.microsoft.com/?id=823938
-Sue
On Fri, 10 Mar 2006 08:41:32 -0800, "tshad"
<tscheiderich@.ftsolutions.com> wrote:

>I found out what is happening, but not why.
>Apparently, Sql Server using UDP service 17 port 1434 for something.
>I looked at my firewall settings and it is dropping my packets because they
>are fragmented. It was confusing at first, because it worked fine without
>the firewall. But what must be happening is that the data is being passed
>on 1433 (which I would expect) and since there is no firewall to strip bad
>packets it lets the fragmented packet through. For some reason, because of
>this packet the connection is dropped (not sure what constitutes a dropped
>connection) so I assume the actual response hasn't been sent yet and now it
>can't send it because the connection is now gone (I think).
>Anyone know why this is happening or what this port (1434) is used for? I
>knew about 1433, but this is the first I had heard about 1434.
>Thanks,
>Tom
>"tshad" <tscheiderich@.ftsolutions.com> wrote in message
>news:ewYccw6QGHA.5808@.TK2MSFTNGP12.phx.gbl...
>

No comments:

Post a Comment