Really noone had such problems with VPNs over TCP before?

On Fri, 27 Oct 2017, Gof via Openvpn-users wrote:

> Hi,
> 
> I have a problem with OpenVPN and I hope you'll be able to help...
> 
> I have two OpenVPN daemons on one Linux machine - one listening on TCP and 
> one bound to the UDP port. They are using TAP devices that are bridged 
> together, and TCP additionally shares port with ssh via "port-share".
> 
> The problem is with clients connected to the TCP server (I can't switch 
> them to UDP because of the firewall). During testing, I switched one UDP 
> client (Linux) to TCP and observed the problem only over TCP.
> 
> Ping time between them when connection is idle is about 30 ms both over 
> the Internet and over VPN and that's okay.
> 
> #v+
> $ ping -c 5 vps
> PING vps (81.4.x.x) 56(84) bytes of data.
> 64 bytes from vps (81.4.x.x): icmp_seq=1 ttl=53 time=29.9 ms
> 64 bytes from vps (81.4.x.x): icmp_seq=2 ttl=53 time=31.5 ms
> 64 bytes from vps (81.4.x.x): icmp_seq=3 ttl=53 time=31.1 ms
> 64 bytes from vps (81.4.x.x): icmp_seq=4 ttl=53 time=30.5 ms
> 64 bytes from vps (81.4.x.x): icmp_seq=5 ttl=53 time=31.1 ms
> 
> --- vps ping statistics ---
> 5 packets transmitted, 5 received, 0% packet loss, time 4006ms
> rtt min/avg/max/mdev = 29.915/30.859/31.529/0.582 ms
> 
> $ ping -c 5 vps.v
> PING vps.v (172.24.44.18) 56(84) bytes of data.
> 64 bytes from vps.v (172.24.44.18): icmp_seq=1 ttl=64 time=32.1 ms
> 64 bytes from vps.v (172.24.44.18): icmp_seq=2 ttl=64 time=30.4 ms
> 64 bytes from vps.v (172.24.44.18): icmp_seq=3 ttl=64 time=30.8 ms
> 64 bytes from vps.v (172.24.44.18): icmp_seq=4 ttl=64 time=29.8 ms
> 64 bytes from vps.v (172.24.44.18): icmp_seq=5 ttl=64 time=30.2 ms
> 
> --- vps.v ping statistics ---
> 5 packets transmitted, 5 received, 0% packet loss, time 4006ms
> rtt min/avg/max/mdev = 29.845/30.722/32.160/0.816 ms
> #v-
> 
> When I start a full-speed transfer from server to client, the ping raises 
> over VPN to about 3500-4000 ms, but over Internet it stays the same. It 
> makes remote work nearly impossible despite having enough Internet 
> capacity.
> 
> #v+
> $ ping -c 5 vps.v
> PING vps.v (172.24.44.18) 56(84) bytes of data.
> 64 bytes from vps.v (172.24.44.18): icmp_seq=1 ttl=64 time=3438 ms
> 64 bytes from vps.v (172.24.44.18): icmp_seq=2 ttl=64 time=4167 ms
> 64 bytes from vps.v (172.24.44.18): icmp_seq=3 ttl=64 time=4110 ms
> 64 bytes from vps.v (172.24.44.18): icmp_seq=4 ttl=64 time=3959 ms
> 64 bytes from vps.v (172.24.44.18): icmp_seq=5 ttl=64 time=3976 ms
> 
> --- vps.v ping statistics ---
> 5 packets transmitted, 5 received, 0% packet loss, time 4141ms
> rtt min/avg/max/mdev = 3438.649/3930.410/4167.983/258.253 ms, pipe 4
> 
> $ ping -c 5 vps
> PING vps (81.4.x.x) 56(84) bytes of data.
> 64 bytes from vps (81.4.x.x): icmp_seq=1 ttl=53 time=31.5 ms
> 64 bytes from vps (81.4.x.x): icmp_seq=2 ttl=53 time=36.7 ms
> 64 bytes from vps (81.4.x.x): icmp_seq=3 ttl=53 time=33.4 ms
> 64 bytes from vps (81.4.x.x): icmp_seq=4 ttl=53 time=30.6 ms
> 64 bytes from vps (81.4.x.x): icmp_seq=5 ttl=53 time=30.7 ms
> 
> --- vps ping statistics ---
> 5 packets transmitted, 5 received, 0% packet loss, time 4007ms
> rtt min/avg/max/mdev = 30.650/32.641/36.799/2.314 ms
> #v-
> 
> What can be the cause for this? And how could I remedy? I already tried 
> adding TCP_NODELAY option to the socket, but it didn't help.
> 
> My full configs are below.
> 
> #v+ server config (no IP address, because it's set on the bridge)
> dev           tap1
> port          443
> proto         tcp-server
> ca            /etc/openvpn/ca.crt
> cert          /etc/openvpn/svpst.crt
> key           /etc/openvpn/svpst.key
> dh            /etc/openvpn/dh2048.pem
> crl-verify    /etc/openvpn/crl.pem
> mode          server
> tls-server
> client-to-client
> keepalive     10 45
> max-clients   64
> verb          4
> mute          20
> persist-key
> persist-tun
> comp-lzo      no
> user          nobody
> group         nogroup
> # socket-flags        TCP_NODELAY
> port-share    127.0.0.1 22
> cipher                AES-256-CBC
> #v- 
> 
> #v+ client config
> dev             tap0
> port          443
> proto           tcp-client
> ca              /etc/openvpn/ca.crt
> cert            /etc/openvpn/pi.crt
> key             /etc/openvpn/pi.key
> remote                81.4.x.x
> ifconfig        172.24.44.20 255.255.255.0
> comp-lzo      no
> keepalive     10 45
> tls-client
> persist-key
> persist-tun
> # socket-flags        TCP_NODELAY
> user            nobody
> group           nogroup
> connect-retry 1
> connect-timeout       7
> verb            4
> mute            60
> script-security       2
> up            /etc/openvpn/pi.up.sh
> down          /etc/openvpn/pi.down.sh
> cipher                AES-256-CBC
> #v-
> 
> Mentioned up and down scripts only set default routing through the VPN 
> (I'm using two routing tables and fwmark to be able to access all ports on 
> the server except 443 through the VPN, and only 443 through the default 
> gateway), but the machine I did testing on doesn't use this form of 
> routing and the problem is the same, so it can be ruled out...
> 
> Thank you!
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Openvpn-users mailing list
> Openvpn-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-users
> 

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Reply via email to