Discussion:
[Openvpn-users] OpenVPN compression ratio
Abi Askushi
2017-07-20 21:04:42 UTC
Permalink
Hi all,

Do you know of any way that one could calculate the OpenVPN compression
ration for a specific amount of traffic? Except from wireshark/tshark
measurements that one may attempt, is it any other way that one could query
this statistic perhaps from the openvpn service?

Thanx,
Abi
Selva Nair
2017-07-20 21:41:54 UTC
Permalink
Hi,
Post by Abi Askushi
Hi all,
Do you know of any way that one could calculate the OpenVPN compression
ration for a specific amount of traffic? Except from wireshark/tshark
measurements that one may attempt, is it any other way that one could query
this statistic perhaps from the openvpn service?
The status output has the pre-compressed and post-compressed bytes info. To
get the status, either use "--status filename interval" in the config, or
send SIGUSR2 to the running process (status output goes to log), or connect
to the management interface and type status.

Selva
Abi Askushi
2017-07-20 21:51:34 UTC
Permalink
Hi Selva,

I have already enabled status file and I am getting the following:

Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
TestClient,192.168.0.180:48699,*364880*,*269678*,Thu Jul 20 16:08:39 2017

It seems that it has only two values for bytes received and sent.
I am using OpenVPN 2.2. Is this a feature provided from later VPN versions?

Thanx,
Abi
Post by Selva Nair
Hi,
Post by Abi Askushi
Hi all,
Do you know of any way that one could calculate the OpenVPN compression
ration for a specific amount of traffic? Except from wireshark/tshark
measurements that one may attempt, is it any other way that one could query
this statistic perhaps from the openvpn service?
The status output has the pre-compressed and post-compressed bytes info.
To get the status, either use "--status filename interval" in the config,
or send SIGUSR2 to the running process (status output goes to log), or
connect to the management interface and type status.
Selva
Selva Nair
2017-07-21 01:01:14 UTC
Permalink
Hi,
Post by Abi Askushi
Hi Selva,
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
TestClient,192.168.0.180:48699,*364880*,*269678*,Thu Jul 20 16:08:39 2017
It seems that it has only two values for bytes received and sent.
I am using OpenVPN 2.2. Is this a feature provided from later VPN versions?
I was referring to status on client. On server, compression stats is not
included in the status output. Debug level info on compression stats is
printed to the log at verb=9 but that may be too verbose to be useful for
regular stats collection.

As for 2.2, its very old -- upgrade.

Selva
Abi Askushi
2017-07-21 07:02:22 UTC
Permalink
Thank you Selva. I confirm I can read those values from client side.
Post by Selva Nair
Hi,
Post by Abi Askushi
Hi Selva,
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
TestClient,192.168.0.180:48699,*364880*,*269678*,Thu Jul 20 16:08:39 2017
It seems that it has only two values for bytes received and sent.
I am using OpenVPN 2.2. Is this a feature provided from later VPN versions?
I was referring to status on client. On server, compression stats is not
included in the status output. Debug level info on compression stats is
printed to the log at verb=9 but that may be too verbose to be useful for
regular stats collection.
As for 2.2, its very old -- upgrade.
Selva
Abi Askushi
2017-07-21 07:29:47 UTC
Permalink
I am getting the following values and I am a bit confused as they don't add
up:

OpenVPN STATISTICS
Updated,Fri Jul 21 07:12:57 2017
TUN/TAP read bytes,527859
TUN/TAP write bytes,678807
TCP/UDP read bytes,804077
TCP/UDP write bytes,702449
Auth read bytes,678807
pre-compress bytes,140358
post-compress bytes,131343
pre-decompress bytes,80635
post-decompress bytes,127443
END

I understand the following. Please correct me if I am wrong:

TUN/TAP read bytes,527859 : bytes received in tun interface (download)
TUN/TAP write bytes,678807: bytes sent in tun interface (upload)
TCP/UDP read bytes,804077: bytes received on WAN interface (this includes
VPN encapsulation)
TCP/UDP write bytes,702449: bytes sent on WAN interface (this includes VPN
encapsulation)
Auth read bytes,678807: ???
pre-compress bytes,140358: bytes to be sent in tun interface before they
are compressed (upload)
post-compress bytes,131343: bytes to be sent in tun interface after they
are compressed (upload)
pre-decompress bytes,80635: bytes received in tun interface before they are
decompressed (download)
post-decompress bytes,127443: bytes received in tun interface after they
are decompressed (download)

Why the values reported at the compression stats are so different from
TUN/TAP values? Don't they refer to the same payload traffic of VPN?

Thanx,
Abi
Post by Abi Askushi
Thank you Selva. I confirm I can read those values from client side.
Post by Selva Nair
Hi,
Post by Abi Askushi
Hi Selva,
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
TestClient,192.168.0.180:48699,*364880*,*269678*,Thu Jul 20 16:08:39 2017
It seems that it has only two values for bytes received and sent.
I am using OpenVPN 2.2. Is this a feature provided from later VPN versions?
I was referring to status on client. On server, compression stats is not
included in the status output. Debug level info on compression stats is
printed to the log at verb=9 but that may be too verbose to be useful for
regular stats collection.
As for 2.2, its very old -- upgrade.
Selva
Selva Nair
2017-07-22 04:00:04 UTC
Permalink
Hi,
Post by Abi Askushi
TUN/TAP read bytes,527859 : bytes received in tun interface (download)
TUN/TAP write bytes,678807: bytes sent in tun interface (upload)
Your usage of upload/download sounds reversed. What is written to tun by
openvpn either gets routed/forwarded or goes to local applications. In
other words, most of the TCP/UDP read bytes are eventually written to tun.
Post by Abi Askushi
TCP/UDP read bytes,804077: bytes received on WAN interface (this includes
VPN encapsulation)
TCP/UDP write bytes,702449: bytes sent on WAN interface (this includes VPN
encapsulation)
Auth read bytes,678807: ???
This is the size of authenticated packets received (after decompression)
ready for writing to the tun. Surprisingly this seems to exactly match with
what is eventually written to tun -- I thought some data like ping are
internally consumed and included in auth read bytes but not written to tun.

pre-compress bytes,140358: bytes to be sent in tun interface before they
Post by Abi Askushi
are compressed (upload)
post-compress bytes,131343: bytes to be sent in tun interface after they
Post by Abi Askushi
are compressed (upload)
Bytes read from tun for which compression is attempted and corresponding
compressed size.
Post by Abi Askushi
pre-decompress bytes,80635: bytes received in tun interface before they
are decompressed (download)
post-decompress bytes,127443: bytes received in tun interface after they
Post by Abi Askushi
are decompressed (download)
Compressed bytes received from server after decryption and corresponding
decompressed size.
Post by Abi Askushi
Why the values reported at the compression stats are so different from
TUN/TAP values? Don't they refer to the same payload traffic of VPN?
I suppose that is because compression is not attempted on all packets --
there is a size threshold and some adaptive compression logic that has to
pass before compression is tried.

Selva

Loading...