openVPN statistics - need help in intepreting the stats

fallopen

Hello all,

Could someone please help me in understanding the openVPN statistics as below -

OpenVPN STATISTICS
Updated,Tue Jun 11 16:45:33 2013
TUN/TAP read bytes,1728
TUN/TAP write bytes,1061
TCP/UDP read bytes,2156
TCP/UDP write bytes,2626
Auth read bytes,1428
pre-compress bytes,1326
post-compress bytes,863
pre-decompress bytes,434
post-decompress bytes,674
END

As far as I know,
"TUN/TAP read bytes" and "TUN/TAP write bytes" refer to the total number of bytes being read from the tunnel and written to the tunnel, respectively.

I am not able to understand the other fields - explanation is appreciated.

Thanks

janjust

traffic inside the tunnel:

TUN/TAP read bytes,1728
TUN/TAP write bytes,1061

traffic outside the tunnel:

TCP/UDP read bytes,2156
TCP/UDP write bytes,2626

authentication traffic (non-data-channel):

Auth read bytes,1428

You're using compression and thus far it isn't doing you much good:

pre-compress bytes,1326
post-compress bytes,863
pre-decompress bytes,434
post-decompress bytes,674

this will change once you really start sending traffic back and forth...

fallopen

Thanks for your response, Jan Just.

With regards to TUN/TAP data - shouldn't this be a bigger value if it includes TCP/UDP data? How different is TCP/UDP data from TUN/TAP data?

janjust wrotetraffic inside the tunnel:

TUN/TAP read bytes,1728
TUN/TAP write bytes,1061

janjust wrote traffic inside the tunnel:
TCP/UDP read bytes,2156
TCP/UDP write bytes,2626

janjust wrote You're using compression and thus far it isn't doing you much good:

Shouldn't the pre-compress bytes and post-decompress bytes be equal? It looks like there is some loss - though I suspect this depends on the compression algorithm (lzo algorithm in this case)

janjust wrote pre-compress bytes,1326
post-compress bytes,863
pre-decompress bytes,434
post-decompress bytes,674
this will change once you really start sending traffic back and forth...

janjust

I made a small typo in my post: TCP/UDP data is the amount of data after encapsulation, encryption, compression etc. This is almost always higher then the tun/tap data.

The compress and decompress data is bi-directional: the compress figures are for the data that is compressed before it is sent to the remote end; the decompress figures are for the *received* data before and after (de)compression.

fallopen

Thanks for the correction, Jan Just.