Verify compression in Log File

[OpenVPNTest]

I have compression off on server and client, the client log even says:

208-10-05 06:51:53 PROTOCOL OPTIONS:
Cipher: AES-256-GCM
digest: SHA256
compress: NONE

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?

[TinCanTech]

Very good question ..

Can you please post your configs and logs so we can verify that.

[OpenVPNTest]

I can and will but unfortunately, it'll be later this afternoon.

[OpenVPNTest]

Server is pfSense box running 2.4.4 which has OpenVPN 2.4.6.

View Originalserver

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

Code: Select all

Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1549,tun-mtu 1500,proto UDPv4,cipher AES-256-GCM,auth [null-digest],keysize 256,key-method 2,tls-server'
Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1549,tun-mtu 1500,proto UDPv4,cipher AES-256-GCM,auth [null-digest],keysize 256,key-method 2,tls-client'
TLS: Initial packet from [AF_INET], sid=
VERIFY SCRIPT OK: depth=1, CN=
VERIFY OK: depth=1, CN=
VERIFY SCRIPT OK: depth=0, CN=
VERIFY OK: depth=0, CN=
peer info: IV_GUI_VER=net.openvpn.connect.ios_3.0.2-894
peer info: IV_VER=3.2
peer info: IV_PLAT=ios
peer info: IV_NCP=2
peer info: IV_TCPNL=1
peer info: IV_PROTO=2
peer info: IV_IPv6=0
PLUGIN_CALL: POST /usr/local/lib/openvpn/plugins/openvpn-plugin-auth-script.so/PLUGIN_AUTH_USER_PASS_VERIFY status=2
TLS: Username/Password authentication deferred for username '' [CN SET]
WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1549', remote='link-mtu 1521'
Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
[] Peer Connection Initiated with [AF_INET]
user '' authenticated
PUSH: Received control message: 'PUSH_REQUEST'
MULTI_sva: pool returned IPv4=, IPv6=(Not enabled)
OPTIONS IMPORT: reading client specific options from: /tmp/openvpn_cc_12fc.tmp
MULTI: Learn:  -> 
MULTI: primary virtual IP for 
PUSH: Received control message: 'PUSH_REQUEST'
SENT CONTROL []: 'PUSH_REPLY,dhcp-option DNS ,redirect-gateway def1,route-gateway ,topology subnet,ping 10,ping-restart 60,ifconfig  255.255.255.0,peer-id 0' (status=1)
MANAGEMENT: Client connected from /var/etc/openvpn/server2.sock
MANAGEMENT: CMD 'status 2'
MANAGEMENT: CMD 'quit'
MANAGEMENT: Client disconnected
SIGTERM[soft,remote-exit] received, client-instance exiting 

View Originalclient

persist-tun
persist-key
cipher AES-256-GCM
ncp-disable
auth none
tls-client
client
remote udp
verify-x509-name "" name
auth-user-pass
remote-cert-tls server

Code: Select all

----- OpenVPN Start ----- OpenVPN core 3.2 ios arm64-bit PT_PROXY built on Oct 3 2018 06:35:04
UNUSED OPTIONS
0 [persist-tun]
1 [persist-key]
3 [ncp-disable]
5 [tls-client]
8 [verify-x509-name][][name]
Tunnel Options:V4,dev-type tun,link-mtu 1521,tun-mtu 1500,proto UDPv4,cipher AES-256-GCM,auth [null-digest],keysize 256,key-method 2,tls-client
Peer Info:
IV_GUI_VER=net.openvpn.connect.ios 3.0.2-894
IV_VER=3.2
IV_NCP=2
IV_TCPNL=1
IV_PROTO=2
IV_IPv6=0
Session is ACTIVE
EVENT: GET_CONFIG
Sending PUSH_REQUEST to server...
OPTIONS:
0 [dhcp-option] [DNS] [] 
1 [redirect-gateway] [def1] 
2 [route-gateway] [] 
3 [topology] [subnet] 
4 [ping] [10] 
5 [ping-restart] [60] 
6 [ifconfig] [] [255.255.255.0] 
7 [peer-id] [0] 
8 [block-ipv6] 
PROTOCOL OPTIONS:
cipher: AES-256-GCM
digest: NONE
compress: NONE
peer ID: 0
EVENT: ASSIGN_IP
NIP: preparing TUN network settings
NIP: init TUN network settings with endpoint: 
NIP: adding IPv4 address to network settings /255.255.255.0
NIP: adding (included) IPv4 route 
NIP: redirecting all IPv4 traffic to TUN interface
NIP: adding DNS 
NIP: blocking all IPv6 traffic
Connected via NetworkExtensionTUN
EVENT: CONNECTED via /UDPv4 on NetworkExtensionTUN/gw=[/]
EVENT: DISCONNECTED
Raw stats on disconnect:
BYTES_IN : 560364
BYTES_OUT : 94533
PACKETS_IN : 650
PACKETS_OUT : 654
TUN_BYTES_IN : 76430
TUN_BYTES_OUT : 541650
TUN_PACKETS_IN : 642
TUN_PACKETS_OUT : 639
Performance stats on disconnect:
CPU usage (microseconds): 538676
Tunnel compression ratio (uplink): 1.23686
Tunnel compression ratio (downlink): 1.03455
Network bytes per CPU second: 1215753
Tunnel bytes per CPU second: 1147405

[OpenVPNTest]

Any insight to this?

[TinCanTech]

We are hoping to hear from a developer quite soon

[ordex]

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.