Strange Connection Issue

chrismcv

Hi,
I have a client connected in to a VPN server, and generally everything is working OK. However, I have one payload (which is the reponse to an SQL Query) that is causing me a problem. It only causes a problem for this one client, when I try connecting from other broadband connections, I don't have a problem with the payload. The way that the error manifests itself is a "timeout" reading the SQL TDS stream over TCP. When I look at this in something that progressively displays the stream, I see rows being retrieved up to a certain point, after which it errors.

My thinking is that the issue might relate to fragmentation and the response size from SQL Server. As such I have tried several MSSFIX directives on the client - these usually solve problems like this with SQL TDS over TCP for me, but it has not helped. I am unable to turn on fragment, as the server is in use by many other clients, who I cannot disconnect. The local network that the client is connected to does have Jumbo Frames enabled, which made me suspicious, but turning this off didn't seem to help.

Nothing is showing up on the client logs at any verbosity, and I've only verb 3 on the server logs, but nothing is showing up there.

I've used wireshark on the TAP Adapater and towards what I imagine to be the end of the stream i receive the following...

(dest server)[TCP Previous segment lost] [TCP segment of a reassembled PDU]
(dest client) [TCP Dup ACK...]
(dest client) [TCP Out-Of-Order [TCP segment of a reassembled PDU]

I'm not sure how to diagnose, or investigate further - so I would appreciate any advise on other things to try either with my configuration, or with my investigations.

Many thanks,
Chris

#OpenVPN Client conf
tls-client
client
dev tun
proto udp
tun-mtu 1500
mssfix 1200
remote <removed> 1194
pkcs12 <key>.p12
cipher BF-CBC
comp-lzo
verb 3
ns-cert-type server

Bebop

Its been quite a few days now. Did you get this resolved?

chrismcv wroteMy thinking is that the issue might relate to fragmentation and the response size from SQL Server

I was thinking exactly the same thing.

chrismcv wrote I am unable to turn on fragment, as the server is in use by many other clients, who I cannot disconnect

Thats got you in a bind then, because far as I know, you need the mss-fix and mtu parameters to be at both the client and server configurations.

chrismcv

I'm still not sorted, am in the process of setting up a cloned server for the client to connect exclusively to, so that I can tweak client and server settings.

Mimiko

Hello.

If the problem is only with one client. Did you tried checking the client itself insteed of OpenVPN server? Did yo done a quality check of the link from client to server? May be on the road to this specific client some internet routers does problems (including mtu problem). Did you try the same SQL query from other clients? Exactly the same things, that the problematic client does?

Making a "tracert" to the server's public IP from client can give you some hints where the packets may have problems. It's happening on internet that provider's gateways have problems, giving headache to final users.

janjust

Bebop is right: you MUST be able to change either the MTU size or the 'fragment' parameter or this will never work; is it possible to set up an extra openvpn instance on a different port (e.g. udp port 1195) and play with the 'fragment' parameter? simply playing with 'mssfix' won't do you much good.

also, you can find the best MTU size by using

ping -M do -s <size> <host>

on a linux client and

ping f -l <size> <host>

on a windows client. For <size>, try a sequence like
1500
1400
1300
1200
and stop when you receive ping replies from the server.
Then, set up a second openvpn instance on udp port 1195 with that mtu size set (or 'fragment' with that size) and connect the malfunctioning client to it.