Re: [Openvpn-users] tcp-client: large ping during transfers (fwd)

[Jan Just Keijser]

Hi,

On 08/11/17 12:30, Gof via Openvpn-users wrote:

Really noone had such problems with VPNs over TCP before?


you're using bridging + tap + proto tcp + port sharing on a VPS and are 
expecting good latency? hmmm
there are many reasons why that combination will NOT give you any 
performance.


However, I see an increase in ping time in my setup as well:
- udp
- tun

and during an iperf run on raw hardware I see the ping time go up too:

64 bytes from 10.200.0.1: icmp_seq=7 ttl=64 time=0.601 ms
64 bytes from 10.200.0.1: icmp_seq=8 ttl=64 time=0.567 ms
64 bytes from 10.200.0.1: icmp_seq=9 ttl=64 time=3.01 ms
64 bytes from 10.200.0.1: icmp_seq=10 ttl=64 time=4.42 ms
64 bytes from 10.200.0.1: icmp_seq=11 ttl=64 time=2.13 ms
64 bytes from 10.200.0.1: icmp_seq=12 ttl=64 time=5.48 ms
64 bytes from 10.200.0.1: icmp_seq=13 ttl=64 time=6.30 ms
64 bytes from 10.200.0.1: icmp_seq=14 ttl=64 time=4.68 ms
64 bytes from 10.200.0.1: icmp_seq=15 ttl=64 time=5.81 ms
64 bytes from 10.200.0.1: icmp_seq=16 ttl=64 time=4.00 ms
[...]
64 bytes from 10.200.0.1: icmp_seq=23 ttl=64 time=7.11 ms
64 bytes from 10.200.0.1: icmp_seq=24 ttl=64 time=8.01 ms
64 bytes from 10.200.0.1: icmp_seq=25 ttl=64 time=4.86 ms
64 bytes from 10.200.0.1: icmp_seq=26 ttl=64 time=5.68 ms
64 bytes from 10.200.0.1: icmp_seq=27 ttl=64 time=5.31 ms
64 bytes from 10.200.0.1: icmp_seq=28 ttl=64 time=4.17 ms
64 bytes from 10.200.0.1: icmp_seq=29 ttl=64 time=0.355 ms
64 bytes from 10.200.0.1: icmp_seq=30 ttl=64 time=0.577 ms


Admittedly, not as much as you are seeing but it's definitely there and 
it is to be expected over a VPN link: during the transfer/throughput 
test the VPN is encrypting+decrypting like mad, which will affect 
latency at some point.



HTH,

JJK


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 

Re: [Openvpn-users] Difference of usable bandwidth between versions

[Jan Just Keijser]

Hi,

On 08/11/17 18:07, Alarig Le Lay wrote:

Hi,

I’ve tested the version 2.3.4, 2.4.0, 2.4.3 and 2.4.4 between the same
two machines on the same link (100M).

The client and router configuration are available here:
https://wiki.grifon.fr/doku.php?id=reseau:openvpn

To test the bandwidth, I ran an iperf3 test inside the tunnel, with no
particular options. I got this results:

srv \ clt | 2.3.4 | 2.4.0 | 2.4.3 | 2.4.4
--+---+---+---+---
  2.3.4| 88.5M | 85.6M | 86.8M | 88.2M
--+---+---+---+---
  2.4.0| 80.7M | 84.2M | 80.2M | 83.0M
--+---+---+---+---
  2.4.3| 80.6M | 82.7M | 83.5M | 83.2M
--+---+---+---+---
  2.4.4| 93.8M | 83.0M | 83.6M | 80.9M

What could explain a difference of about 15M between the best and the
worst test?



I would have expected 2.4.4 client+server to be faster
Other than that, can you try running iperf / iperf3 using
  iperf -c ... -n 200M -r -fk

and see if the numbers become more "stable". I have often seen that 
running "just iperf" will produce wildly varying results, both on 
Ethernet and VPN links.


HTH,

JJK


--
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

Re: [Openvpn-users] Difference of usable bandwidth between versions

[Alarig Le Lay]

On mer.  8 nov. 13:57:17 2017, Eric Crist wrote:
> Is there anything in between these systems? Was this across the
> Internet or just on the local network?

Yes, it’s across Internet but the link was pretty unused when I did the
tests (I rerouted the rest of the traffic on another link).

I just rerun a test to the router outside of the tunnel, and I get 93.0
Mbits/sec without rerouting the traffic.

-- 
alarig


signature.asc
Description: PGP signature
--
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

Re: [Openvpn-users] Difference of usable bandwidth between versions

[Eric Crist]

Is there anything in between these systems? Was this across the Internet or 
just on the local network?

Eric Crist

> On Nov 8, 2017, at 11:07 AM, Alarig Le Lay  wrote:
> 
> Hi,
> 
> I’ve tested the version 2.3.4, 2.4.0, 2.4.3 and 2.4.4 between the same
> two machines on the same link (100M).
> 
> The client and router configuration are available here:
> https://wiki.grifon.fr/doku.php?id=reseau:openvpn
> 
> To test the bandwidth, I ran an iperf3 test inside the tunnel, with no
> particular options. I got this results:
> 
> srv \ clt | 2.3.4 | 2.4.0 | 2.4.3 | 2.4.4
> --+---+---+---+---
> 2.3.4| 88.5M | 85.6M | 86.8M | 88.2M
> --+---+---+---+---
> 2.4.0| 80.7M | 84.2M | 80.2M | 83.0M
> --+---+---+---+---
> 2.4.3| 80.6M | 82.7M | 83.5M | 83.2M
> --+---+---+---+---
> 2.4.4| 93.8M | 83.0M | 83.6M | 80.9M
> 
> What could explain a difference of about 15M between the best and the
> worst test?
> 
> Thanks,
> -- 
> alarig
> --
> 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

[Openvpn-users] Difference of usable bandwidth between versions

[Alarig Le Lay]

Hi,

I’ve tested the version 2.3.4, 2.4.0, 2.4.3 and 2.4.4 between the same
two machines on the same link (100M).

The client and router configuration are available here:
https://wiki.grifon.fr/doku.php?id=reseau:openvpn

To test the bandwidth, I ran an iperf3 test inside the tunnel, with no
particular options. I got this results:

srv \ clt | 2.3.4 | 2.4.0 | 2.4.3 | 2.4.4
--+---+---+---+---
 2.3.4| 88.5M | 85.6M | 86.8M | 88.2M
--+---+---+---+---
 2.4.0| 80.7M | 84.2M | 80.2M | 83.0M
--+---+---+---+---
 2.4.3| 80.6M | 82.7M | 83.5M | 83.2M
--+---+---+---+---
 2.4.4| 93.8M | 83.0M | 83.6M | 80.9M

What could explain a difference of about 15M between the best and the
worst test?

Thanks,
-- 
alarig


signature.asc
Description: PGP signature
--
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

Re: [Openvpn-users] tcp-client: large ping during transfers (fwd)

[Selva]

Hi,

On Wed, Nov 8, 2017 at 6:30 AM, Gof via Openvpn-users <
openvpn-users@lists.sourceforge.net> wrote:

> Really noone had such problems with VPNs over TCP before?
>

In case it helps: I recall seeing long latency with TCP tunnels under load.
But
don't have any TCP tunnels in real use, so never looked more into it.

I suspect most people use UDP, thus no replies.

Selva
--
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

Re: [Openvpn-users] "TUN/TAP I/O operation aborted, restarting"

[Jan Just Keijser]

On 08/11/17 12:17, Илья Шипицин wrote:



2017-11-08 16:11 GMT+05:00 Gert Doering >:

Hi,

On Wed, Nov 08, 2017 at 04:05:01PM +0500,  ?? wrote:
> is there a way to make "TUN/TAP I/O operation aborted, restarting" fatal ?

Sure, but most certainly not on the -users list


there're so many various configuration options, I'm still not sure about many 
of them
so, I was asking whether it is possible to do by config


nope; the code does this:

1064 /* Was TUN/TAP I/O operation aborted? */
1065 if (tuntap_abort(c->c2.buf.len))
1066 {
1067 register_signal(c, SIGHUP, "tun-abort");
1068 c->persist.restart_sleep_seconds = 10;
1069 msg(M_INFO, "TUN/TAP I/O operation aborted, restarting");
1070 perf_pop();
1071 return;
1072 }


which means we're restarting OpenVPN using SIGHUP ; currently there's no way to 
override this.
If the code would have said
1067  register_signal(c, SIGUSR1, "tun-abort");

then you could use something like
  -remap-usr1 SIGTERM
to get the desired behaviour.

HTH,

JJK

--
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

Re: [Openvpn-users] tcp-client: large ping during transfers (fwd)

[Gof via Openvpn-users]

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-flagsTCP_NODELAY
> port-share127.0.0.1 22
> cipherAES-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
> remote81.4.x.x
> ifconfig172.24.44.20 255.255.255.0
> comp-lzo  no
> keepalive 10 45
> tls-client
> persist-key
> persist-tun
> # socket-flagsTCP_NODELAY
> usernobody
> group   nogroup
> connect-retry 1
> connect-timeout   7
> verb4
> mute60
> script-security   2
> up/etc/openvpn/pi.up.sh
> down  /etc/openvpn/pi.down.sh
> cipherAES-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 

Re: [Openvpn-users] "TUN/TAP I/O operation aborted, restarting"

[Илья Шипицин]

2017-11-08 16:11 GMT+05:00 Gert Doering :

> Hi,
>
> On Wed, Nov 08, 2017 at 04:05:01PM +0500,  ?? wrote:
> > is there a way to make "TUN/TAP I/O operation aborted, restarting" fatal
> ?
>
> Sure, but most certainly not on the -users list
>

there're so many various configuration options, I'm still not sure about
many of them
so, I was asking whether it is possible to do by config


>
> gert
>
> --
> USENET is *not* the non-clickable part of WWW!
>//
> www.muc.de/~gert/
> Gert Doering - Munich, Germany
> g...@greenie.muc.de
> fax: +49-89-35655025g...@net.informatik.tu-
> muenchen.de
>
--
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

[Openvpn-users] "TUN/TAP I/O operation aborted, restarting"

[Илья Шипицин]

Hello,

is there a way to make "TUN/TAP I/O operation aborted, restarting" fatal ?

Cheers,
Ilya Shipitsin
--
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