Hi Jan Just, (forgot to add openvpn-devel in previous mail)
Some background information. In openvpn3 we decided not to implement fragments, because: - this is quite a big feature which has to be supported through the whole stack (client, server, kernel module) - we assume that it is not used by most of users However, for those who needs --fragment, we'll implement: - mssfix support, this should solve problems with tcp-based protocols - sending icmp "packet too big" for other protocols, we assume that they'll respect icmp response --fragment is/was very useful on a system where you do not / cannot change > the tun MTU size. Up to Windows XP, this was not > possible without rebooting the OS. Since Vista, it *is* possible to change > the MTU of an adapter on the fly (as explained in my > trusty old cookbook, of course ;)) > As James wrote a while ago (13 years ago :) https://openvpn.net/archive/openvpn-users/2005-10/msg00354.html > A lot of experience gained during the OpenVPN 1.x releases showed that it's best to fix the tunnel MTU at > 1500 and vary the other parameters (and use --mssfix to prevent fragmentation rather than a lower tunnel MTU). Don't know if still holds. Assuming that we can change tun-mtu on any supported platforms, do you think that it is better to do _that_, rather than have mssfix/icmp ptb workaround? > With that, it would be possible to fix the link-mtu to 1500 (or > whatever is set on the outbound interface) and then subtract the header > size to get a meaningful tun-mtu size. > Do you think 1500 is a safe value? Arne just mentioned today that his network interface MTU is 1500 and router's MTU is 1492 due to PPPoE, and openvpn2 works because it assumes that mtu is 1450. > Having said all that, I do have one gripe with the way the link or tun mtu > is calculated in the current codebase: > In the 2.3 code base, the server tun mtu size was equal to the client > tun-mtu size. > In the 2.4+ code base, the server-side tun mtu size is set to some > ridiculous low level (with link-mtu 1500 set) in order to > accomocate all possible encryption ciphers - *even if I add ncp-disable* . > To me, that does not make a whole lot of sense. If I > add '--ncp-disable' I'd expect the client and the server to behave pretty > much like an OpenVPN 2.3 client (with a possible 3 > bytes difference to accomodate for the peer id). > With 2.4 codebase I noticed that what man page says is not what openvpn2 code does - it does include transport overhead, while man page says it doesn't (copying my mail here): Announce to TCP sessions running over the tunnel that they should limit their send packet sizes such that after OpenVPN has encapsulated them, the resulting UDP packet size that OpenVPN sends to its peer will not exceed max bytes. The default value is 1450. The max parameter is interpreted in the same way as the --link-mtu parameter, i.e. the UDP packet size after encapsulation overhead has been added in, but not including the UDP header itself. Resulting packet would be at most 28 bytes larger for IPv4 and 48 bytes for IPv6 (20/40 bytes for IP header and 8 bytes for UDP header). So it means that with "mssfix" 1300 resulting IPv4 packet size would be at most 1328. This is what I see in Wireshark (server - git master, client 2.4.6): Internet Protocol Version 4, Src: 128.199.xxx.yyy, Dst: 10.0.200.20 0100 .... = Version: 4 .... 0101 = Header Length: 20 bytes (5) Total Length: 1300 Protocol: UDP (17) User Datagram Protocol, Src Port: 1194, Dst Port: 1194 Source Port: 1194 Destination Port: 1194 Length: 1280 OpenVPN Protocol Type: 0x49 [opcode/key_id] Peer ID: 0 Data (1268 bytes) While man page statement is technically correct - UDP packet size is 1300, which is "at most 1328", I think it should say: > the resulting IP packet size that OpenVPN sends to its peer will not exceed max bytes and > The max parameter is interpreted in the same way as the --link-mtu parameter, i.e. the IP packet size after encapsulation overhead has been added in, including UDP and IP headers. -Lev
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
