Hi Pieter,
On 29/10/18 14:05, Pieter Hulshoff wrote:
Hello all,
I'm trying to determine the overhead differences between V1 TUN and
TAP mode, and I'm running into some difficulties.
Using AES-CBC with SHA-256 in TUN mode, I calculate 20 (IP) + 8 (UDP)
+ 1 (OPCODE) + 32 (HMAC) + 16 (IV) + 4 (PACKET-ID) + 16 (max PADDING)
= 97 bytes. This matches the value I get on my tunnel MTU (1403) when
I use -link-mtu 1472: 1500-1403 = 97.
For TAP mode, I would have expected 14 (without CRC) or 18 (with CRC)
additional bytes (is the original CRC encrypted in TAP mode?). If I
use -link-mtu 1472 again however, I get a tap MTU of 1371:
1500-1371=129; 32 more than the 97 I had before.
Where do I go wrong in my calculations/assumptions?
your assumption is that in TAP mode, OpenVPN would allow only Ethernet
802 II traffic. For these type of packets, an extra 14 bytes would
suffice. However, for a full blown Ethernet virtual Ethernet adapter you
need to allocate some extra space for other frame types. This is why
OpenVPN uses a (fairly arbitrary) value of 32 bytes for Ethernet (tap)
packets , compared to 'tun' packets. This is controlled using the
--tun-mtu-extra flag, which is set to 0 for tun and to 32 for tap. You
can test this yourself by setting
tun-mtu-extra 14
on both sides in tap mode and then see if your connection still works;
If you set it to anything lower than 14, the link will fail. It *will*
mean that you can only send Ethernet/IP traffic of a tap link.
Having said that, I do see a few odd things with OpenVPN 2.4 clients
versus servers, even in 'tun' mode:
If I launch a basic 2.4.6 server using
proto udp
port 1194
dev tun
server 10.200.0.0 255.255.255.0
dh /etc/openvpn/cookbook/dh2048.pem
ca /etc/openvpn/cookbook/ca.crt
cert /etc/openvpn/cookbook/server.crt
key /etc/openvpn/cookbook/server.key
persist-key
persist-tun
keepalive 10 60
topology subnet
cipher aes-256-cbc
auth sha256
ncp-disable
verb 5
link-mtu 1500
I see on the server
Mon Oct 29 17:25:07 2018 us=637291 TLS-Auth MTU parms [ L:1500 D:1212
EF:38 EB:0 ET:0 EL:3 ]
Mon Oct 29 17:25:07 2018 us=638046 /sbin/ip link set dev tun0 up mtu *1379*
Mon Oct 29 17:25:07 2018 us=642591 Data Channel MTU parms [ L:1500
D:1450 EF:121 EB:386 ET:0 EL:3 ]
If I run the same command using OpenVPN 2.3.18 (minus the
'ncp-disable'), I get:
Mon Oct 29 17:32:32 2018 us=106309 TLS-Auth MTU parms [ L:1500 D:1212
EF:38 EB:0 ET:0 EL:3 ]
Mon Oct 29 17:32:32 2018 us=107031 /usr/sbin/ifconfig tun0 10.200.0.1
netmask 255.255.255.0 mtu *1431* broadcast 10.200.0.255
Mon Oct 29 17:32:32 2018 us=112405 Data Channel MTU parms [ L:1500
D:1450 EF:69 EB:12 ET:0 EL:3 ]
Now on the corresponding client I see:
Mon Oct 29 17:27:29 2018 us=816805 Control Channel MTU parms [ L:1500
D:1212 EF:38 EB:0 ET:0 EL:3 ]
Mon Oct 29 17:27:29 2018 us=818161 Data Channel MTU parms [ L:1500
D:1450 EF:121 EB:386 ET:0 EL:3 ]
Mon Oct 29 17:27:29 2018 us=818239 Local Options String (VER=V4):
'V4,dev-type tun,link-mtu 1500,tun-mtu *1379*,proto UDPv4,cipher
AES-256-CBC,auth SHA256,keysize 256,key-method 2,tls-client'
Mon Oct 29 17:27:29 2018 us=818264 Expected Remote Options String
(VER=V4): 'V4,dev-type tun,link-mtu 1500,tun-mtu *1379*,proto
UDPv4,cipher AES-256-CBC,auth SHA256,keysize 256,key-method 2,tls-server'
[...]
Mon Oct 29 17:27:31 2018 us=20504 OPTIONS IMPORT: peer-id set
Mon Oct 29 17:27:31 2018 us=20513 OPTIONS IMPORT: WARNING: peer-id set,
but link-mtu fixed by config - reducing tun-mtu to 1376, expect MTU problems
Mon Oct 29 17:27:31 2018 us=20530 Data Channel MTU parms [ L:1500 D:1450
EF:72 EB:386 ET:0 EL:3 ]
Mon Oct 29 17:27:31 2018 us=20929 /sbin/ip link set dev tun0 up mtu *1428*
and with OpenVPN 2.3.18:
Mon Oct 29 17:34:07 2018 us=724147 Control Channel MTU parms [ L:1500
D:1212 EF:38 EB:0 ET:0 EL:3 ]
Mon Oct 29 17:34:07 2018 us=724817 Data Channel MTU parms [ L:1500
D:1450 EF:69 EB:12 ET:0 EL:3 ]
Mon Oct 29 17:34:07 2018 us=724839 Local Options String: 'V4,dev-type
tun,link-mtu 1500,tun-mtu *1431*,proto UDPv4,cipher AES-256-CBC,auth
SHA256,keysize 256,key-method 2,tls-client'
Mon Oct 29 17:34:07 2018 us=724847 Expected Remote Options String:
'V4,dev-type tun,link-mtu 1500,tun-mtu *1431*,proto UDPv4,cipher
AES-256-CBC,auth SHA256,keysize 256,key-method 2,tls-server'
Mon Oct 29 17:34:10 2018 us=97262 /usr/sbin/ifconfig tun0 10.200.0.2
netmask 255.255.255.0 mtu *1431* broadcast 10.200.0.255
so for some wicked reason the 2.4 client side tun-MTU is LARGER than the
server side MTU, and a 2.4 client sets an entirely different value for
the MTU ?!?!?
Of course, if I fix the tun-MTU then the link-MTU value simple increases
on the one end.
So, the '32' is easily explained. However, the rest of the MTU
calculation baffles me.
HTH,
JJK
_______________________________________________
Openvpn-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-users
