However, at the end of the testing session the log shows:
2018-10-05 06:52:30 Performance stats on disconnect:
CPU usage (microseconds): 324644
Tunnel compression ratio (uplink): 1.52365
Tunnel compression ratio (downlink): 1.04308
Network bytes per CPU second: 765472
Tunnel bytes per CPU second: 712611
If compression is off, why are there Tunnel compression ratio stats?
Re: Verify compression in Log File
Posted: Fri Oct 05, 2018 11:36 am
by TinCanTech
Very good question ..
Can you please post your configs and logs so we can verify that.
Re: Verify compression in Log File
Posted: Fri Oct 05, 2018 11:44 am
by OpenVPNTest
I can and will but unfortunately, it'll be later this afternoon.
Re: Verify compression in Log File
Posted: Mon Oct 08, 2018 12:49 pm
by OpenVPNTest
Server is pfSense box running 2.4.4 which has OpenVPN 2.4.6.
server
dev ovpns2
verb 4
dev-type tun
dev-node /dev/tun2
writepid /var/run/openvpn_server2.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp4
cipher AES-256-GCM
auth none
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
client-connect /usr/local/sbin/openvpn.attributes.sh
client-disconnect /usr/local/sbin/openvpn.attributes.sh
local
tls-server
server 255.255.255.0
client-config-dir /var/etc/openvpn-csc/server2
username-as-common-name
plugin /usr/local/lib/openvpn/plugins/openvpn-plugin-auth-script.so /usr/local/sbin/ovpn_auth_verify_async user TU= true server2
tls-verify "/usr/local/sbin/ovpn_auth_verify tls '' 1"
lport
management /var/etc/openvpn/server2.sock unix
push "dhcp-option DNS "
push "redirect-gateway def1"
ca /var/etc/openvpn/server2.ca
cert /var/etc/openvpn/server2.cert
key /var/etc/openvpn/server2.key
dh /etc/dh-parameters.2048
tls-crypt /var/etc/openvpn/server2.tls-crypt
ncp-disable
persist-remote-ip
float
topology subnet
fast-io
Tunnel compression ratio (uplink): 1.52365
Tunnel compression ratio (downlink): 1.04308
the name is probably a bit misleading, but this is basically the ratio the bytes "outside" the tunnel over the bytes "inside" the tunnel. Both for outgoing and incoming traffic.
Therefore, even if compression is not enabled, it accounts for all kind of overhead.
However, I have to say I would have expected much similar values for both directions when compression is not enabled at all.