With the default settings for OpenVPN connections, I get several warnings in the log file. This may confuse users and should be cleaned up if possible. WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead. WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC). WARNING: cipher with small block size in use, reducing reneg-bytes to 64MB to mitigate SWEET32 attacks. WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400)
Hi Larsen, since i work at this time also on OpenVPN updates/some_fixes, i found your bugzilla entry here where also one point is listed where i also work on, but i took also a look into your other 2 points. So i leave you a quick answer with possible fixes. 1) WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead : This is the point where i´am working on and i think it is the more problematic one. As far as i could work out until now, there is the need to generate a new host certificate (root certificate by the way too) cause IPFire lacks there with the needed key usage extension entries under /var/ipfire/ovpn/openssl/ovpn.cnf (OpenVPN´s OpenSSL configuration). The host certificate should include X509v3 Extended Key Usage: TLS Web Server Authentication X509v3 Key Usage: Digital Signature, Key Encipherment to use "--remote-cert-tls" or to stay compliant to RFC3280 TLS rules --> https://www.ietf.org/rfc/rfc3280.txt . For a more detailed description take a look into the forum --> https://forum.ipfire.org/viewtopic.php?f=50&t=18852#p108144 . Some more testings are definitely needed. A patch for ovpn.cnf are already there findable, a patch for ovpnmain.cgi is currently in testing and i will add it subsequently in there. 2) WARNING: INSECURE cipher with block size less than 128 bit (64 bit): This should be fixed on OpenVPN side since 2.3.13 --> https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn23#OpenVPN2.3.13 and --> https://community.openvpn.net/openvpn/ticket/796 but also on IPFire side with the currently new OpenVPN-2.3.16 on Core 111 --> http://www.ipfire.org/news/ipfire-2-19-core-update-111-released since OpenVPN integrates an automatic reneg-sec after 64MB data traffic if small block ciphers are used. Nevertheless, IPFire´s default value is, i think AES-256-CBC (which is a 128-bit block cipher), old ciphers are only for compatibility purposes and should nevertheless not be used anymore i think. 3) WARNING: normally if you use --mssfix and/or --fragment : This is a very old one, you can also find in here --> https://openvpn.net/archive/openvpn-users/2004-12/msg00037.html a useful answer to this. The problem is that OpenVPN gives mssfix a default value of 1450 if it is not defined over the configuration files. You can see it over verbose level 4 in the logs: Fri Jun 16 14:44:13 2017 us=367153 fragment = 0 Fri Jun 16 14:44:13 2017 us=367169 mssfix = 1450 so this warning will be fired if e.g. the MTU is NOT 1500 and no fragment or mssfix entries are in the configuration file defined, but the default value of mssfix is nevertheless '1450' (OpenVPN expects an MTU with 1500 if fragment or mssfix have values other then 0). To prevent this, there is the need to deactivate '--mssfix' which can be done with a 'mssfix 0' but the WUI do not provide this possibility. Have made a patch for the Roadwarrior and N2N which you can find in the attachment, may you can go also for a test for this. I have checked this patch also for already existing clients (RW only), if the server.conf includes 'mssfix 0' but the old (not modified) client do NOT have those entries, the clients fires as usual the known warning but as far as i could see now, the connection have no problems with this. In here more testings and feedback might also be great. Some infos from here. Greetings, Erik
Created attachment 525 [details] Patch to prevent mssfix/fragment/mtu warning This patch should prevent the old "WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400)" . If the MTU != 1500 and fragment and mssfix is deactivated, this patch will add 'mssfix 0' to the configuration files. OpenVPN default values for mssfix are 1450 if no other values are set. This is useless in this case cause OpenVPN uses the MTU value for package sizing.
Hi Erik, I would like to help testing this. 2) So, I should install Core 111. Do I have to recreate OpenVPN connections completely? Or simply edit/save a connection and the put the new config file onto the user's computer? Or perhaps do nothing at all? 3) Apply the patch and what else do I have to do? Basically, the same questions as for 2)
Great, thanks for your help to test this. May it is an idea if i make one patch with all changes in it or should we go step by step through it ? Your questions: 1) Using "--remote-cert-tls" is the biggest hassle here cause the extended TLS key usage needs to be set in the OpenSSL config (/var/ipfire/ovpn/openssl/ovpn.cnf) BEFORE the X509 (root and host certificate) are created, changing only the directives didn´t work for me cause all existing clients rely on the deprecated "Netscape" cert attribute. So a complete regeneration of ALL certificates is needed as far as i could see now. It makes it even worst (and a little urgent) since OpenVPN will remove '--ns-cert-type' with version 2.5 --> https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage . ToDo: Patching ovpn.cnf, patching ovpnmain.cgi (patch is already there --> http://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=e9ef03b059f72dbff64e410b911459dceb3b3e53 , and deleting the whole PKI and regenerate it with the new parameters again. 2) Have positively tested some time ago the new '--reneg-bytes' feature for ciphers with small block size ONLY in my OpenVPN-2.4 (server and clients) environment (work currently to integrate it on IPFire --> https://forum.ipfire.org/viewtopic.php?f=50&t=18067 ). Here is a small log portion: Tue Apr 11 15:21:05 2017 VERIFY OK: depth=1, C=AF, O=test, CN=test CA Tue Apr 11 15:21:05 2017 VERIFY OK: nsCertType=SERVER Tue Apr 11 15:21:05 2017 VERIFY X509NAME OK: C=AF, O=test, CN=192.168.20.30 Tue Apr 11 15:21:05 2017 VERIFY OK: depth=0, C=AF, O=test, CN=192.168.20.30 Tue Apr 11 15:21:05 2017 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key Tue Apr 11 15:21:05 2017 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC). Tue Apr 11 15:21:05 2017 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Tue Apr 11 15:21:05 2017 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key Tue Apr 11 15:21:05 2017 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC). Tue Apr 11 15:21:05 2017 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Tue Apr 11 15:21:05 2017 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA Tue Apr 11 15:23:04 2017 VERIFY OK: depth=1, C=AF, O=test, CN=test CA Tue Apr 11 15:23:04 2017 VERIFY OK: nsCertType=SERVER Tue Apr 11 15:23:04 2017 VERIFY X509NAME OK: C=AF, O=test, CN=192.168.20.30 Tue Apr 11 15:23:04 2017 VERIFY OK: depth=0, C=AF, O=test, CN=192.168.20.30 Tue Apr 11 15:23:05 2017 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key Tue Apr 11 15:23:05 2017 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC). Tue Apr 11 15:23:05 2017 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Tue Apr 11 15:23:05 2017 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key Tue Apr 11 15:23:05 2017 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC). Tue Apr 11 15:23:05 2017 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Tue Apr 11 15:23:05 2017 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA Tue Apr 11 15:25:04 2017 TLS: soft reset sec=3481 bytes=72974412/67108864 pkts=78750/0 Tue Apr 11 15:25:04 2017 VERIFY OK: depth=1, C=AF, O=test, CN=test CA Tue Apr 11 15:25:04 2017 VERIFY OK: nsCertType=SERVER Tue Apr 11 15:25:04 2017 VERIFY X509NAME OK: C=AF, O=test, CN=192.168.20.30 Tue Apr 11 15:25:04 2017 VERIFY OK: depth=0, C=AF, O=test, CN=192.168.20.30 Tue Apr 11 15:25:06 2017 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key Tue Apr 11 15:25:06 2017 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC). Tue Apr 11 15:25:06 2017 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Tue Apr 11 15:25:06 2017 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key Tue Apr 11 15:25:06 2017 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC). Tue Apr 11 15:25:06 2017 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Tue Apr 11 15:25:08 2017 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA Have made there a bigger upload, if you watch the timestamps between the soft resets you can see how often it was changed and this connection is not the fastest. I currently can´t say how this works on 2.3.16 have only see the change logs where it indicates that the changes are included since 2.3.13 version... ToDo: There was no need to patch or to modify something. 3) If you use the patch in the attachment with an e.g. patch -b < OpenVPN_prevent_mssfix_warning.patch /srv/web/ipfire/cgi-bin/ovpnmain.cgi (-b makes also an backup of the existing ovpnmain.cgi) you will need to stop the OpenVPN server, hit the 'save' button and start the OpenVPN server again so that the changes can take affect. - The first and most important thing is that existing configurations works as before without further modifications on server or client side. - If all went OK, you should see on a) server side (in verbose level 4) after an server start a line like this Jun 18 09:31:54 ipfire-server openvpnserver[31355]: mssfix = 0 this occurs only if --fragment and --mssfix are empty and deactivated in the webinterface. The server log should NOT fire the 'WARNING: normally if you use --mssfix and/or --fragment... ' anymore after the patch (and a stop|save|start of the server) if the MTU = NOT 1500, mssfix = deactived and fragment = empty. b) On client side all old configurations will have the old behavior cause the needed directive '--mssfix 0' will only be printed into the client.ovpn after the ovpnmain.cgi patch. So every new generated client should be OK, the old ones needed to be manually modified or will have furthermore to old warning message. ToDo: Patching ovpnmain.cgi after the patch the server and all NEW clients should have the new functionality without modifying something else. It might be also an idea for bigger testings to checkout a forum thread may some more people can help out with the testings ??? Lot´s of text now sorry for that ;-) . Greetings, Erik
1) As far as i understand, the generation of the root certificate will prevent old clients to connect. Therefore, we would have to re-configure around 25 clients, which I'm afraid isn't possible at this moment. 2) Do I have to only install Core 111? 3) Seems to be fixed fine. Steps to reproduce for anyone else: wget "https://bugzilla.ipfire.org/attachment.cgi?id=525" -O OpenVPN_prevent_mssfix_warning.patch patch < OpenVPN_prevent_mssfix_warning.patch /srv/web/ipfire/cgi-bin/ovpnmain.cgi Stop OpenVPN-Server Save settings Start OpenVPN-Server New client confs are ok, old ones need to be adapted manually (add "mssfix 0") or re-downloaded from IPFire.
1) Yes this is correct, host certificate should include the new extended TLS key parameter the CA needs to be regenerated so all old client certificates won´t work anymore. I can understand that this is a problem if there are a bigger number of clients to manage, this is also the reason why i made this also in the forum public cause it might be problem in a not so far future. May there comes some free time where those changes are possible. Nevertheless, the made changes should not affect existing configurations, the changed CGI should invest by itself if the host certificate parameter are available, if they are not the old --ns-cert-type directive will be set automatically. 2) Yes, in my 2.4 testings no more steps where needed. But as mentioned i haven´t tested that for version 2.3.16. 3) Great.
2) Still confused... The release notes for Core 111 state that OpenVPN will be updated to 2.3.16 and that it will use SHA512 for new installations. Do you mean that 2.3.16 might already bring the fix? Or that using SHA512 will?
Hi Larsen, no the changes from SHA1 to SHA512 have nothing to do with this. OpenVPN should bring this fix --> https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn23#OpenVPN2.3.13 since 2.3.13 --> "Limit --reneg-bytes to 64MB when using small block ciphers" Erik
Update to Core 111 is scheduled for Thursday, 18:00 CEST
Core update 111 has been released since June 14, 2017 at 7:00 pm --> http://www.ipfire.org/news/ipfire-2-19-core-update-111-released .
I know. It's the internal update that is scheduled, not the release =)
2) With Core 111, I still see the following warnings in my local log. I have only updated IPFire, not recreated any OpenVPN connections. Fri Jun 23 09:06:48 2017 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC). ... Fri Jun 23 09:06:48 2017 WARNING: cipher with small block size in use, reducing reneg-bytes to 64MB to mitigate SWEET32 attacks.
I think the warnings won´t go, even this warning now displays the new security feature with an "reducing reneg-bytes to 64MB to mitigate SWEET32 attacks." but the more important thing to check might be that the session key will really be renewed after the --reneg-bytes limit of 64 MB. You can see it like in my posted logs above. The regular behavior of OpenVPN is a soft reset (TLS: soft reset) after one hour (reneg-sec 3600), this should be different now if the traffic in the tunnel exceeds 64 MB before an hour has been past. But generally, in my opinion you should setup some new connections with better ciphers. Erik
Hmm... the warning is "block size less than 128 bit (64 bit)" but the connection is using "Cipher 'BF-CBC' initialized with 128 bit key". See entries from the log below (also: soft reset after 64 mb seems to be ok). Why the difference? And which cipher is the preferred one in respect to security but also speed? ... Fri Jun 23 11:46:42 2017 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 1024 bit RSA ... Fri Jun 23 11:46:43 2017 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key Fri Jun 23 11:46:43 2017 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC). Fri Jun 23 11:46:43 2017 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Fri Jun 23 11:46:43 2017 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key Fri Jun 23 11:46:43 2017 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC). Fri Jun 23 11:46:43 2017 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Fri Jun 23 11:46:43 2017 WARNING: cipher with small block size in use, reducing reneg-bytes to 64MB to mitigate SWEET32 attacks. ... Fri Jun 23 11:46:48 2017 MANAGEMENT: >STATE:1498211208,CONNECTED,SUCCESS,10.164.252.194,217.110.124.150,1194,, Fri Jun 23 12:04:43 2017 TLS: soft reset sec=2519 bytes=76333108/67108864 pkts=88179/0 ... Fri Jun 23 12:04:43 2017 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key Fri Jun 23 12:04:43 2017 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC). Fri Jun 23 12:04:43 2017 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Fri Jun 23 12:04:43 2017 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key Fri Jun 23 12:04:43 2017 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC). Fri Jun 23 12:04:43 2017 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Fri Jun 23 12:04:43 2017 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
This problem is independent of key lengths, this problem is a block cipher problem (CBC) whereby short block sizes (64-bit) are vulnerable. Blowfish is a 64-bit block cipher --> https://en.wikipedia.org/wiki/Blowfish_%28cipher%29 which causes the warning and the potential security problem. This problem is long known in the crypto community but i think practical attacks arises firstly with the sweet32 birthday attack --> https://sweet32.info/ which makes a lot of ciphers to a potential problem. On OpenVPN of the current IPFire version all DES variants and BLOWFISH are affected and the current way to prevent this vulnerability is to change the session key after ~64MB which is, as you can see in your logs, far more often then the old one hour cycle before. Core 111 delivers OpenVPN-2.3.x and there is currently not yet the GCM Cipher available which i would prefer (no patents on it, less overhead, other architecture then CBC, possibly also faster) and OpenVPN-2.4.x use/prefers AES-GCM-256 automatically if both sides have the ability (newer OpenSSL). At this time AES-CBC and CAMELLIA-CBC are better options and currently the only 128-bit block ciphers for OpenVPN on the current IPFire (not sure if CAST is not also a 128 bit block cipher). Regarding to the speed, there are also 128 bit key lengths for both available but i´m not sure if it makes really a big difference if you use 256 bit instead but this depends surely also on your hardware capabilities in relation to the number of your user. Erik
@Erik: Is the patch "Patch to prevent mssfix/fragment/mtu warning" already added to Core?
Problem with "SWEET32" did not occur again after I switched to AES-CBC (128bit) (and recreated all OpenVPN users).
Is this all fixed and merged?
Point 1) and 2) are fixed but point 3) is still open but it is also only a (very old) warning which do not restrains the functionality. This is why this message appears often -> https://openvpn.net/archive/openvpn-users/2004-12/msg00037.html . Should we give the possiblity to deactivate mssfix completely ? Best, Erik
What does mssfix do? I think this entire thing is getting quite complicated here. There is also the fragment and MTU options and it is not very clear what should be configured where.
Mssfix handles the maximum packet size of TCP packets sending via an UDP tunnel. Since a lot of people did probably the wrong way by configuring a wrong MTU the OpenVPN people decided to set a default of 1450 for Mssfix (can be seen in verbose level 4) to possible preventthis kind of misconfiguration... Even Mssfix has been deactivated in IPFires WUI, 1450 bytes are nevertheless used for Mssfix. There is the need to add a mssfix 0 in the server but also in the client configuration to set the MTU completely free, might be possibly interesting for e.g. jumbo frames but also an opening for possible misconfiguration ? Patch is there but am not sure if we should deliver this ? What do you think ? Best, Erik
To be honest, I ideally would like to get rid of all of this. The MTU of the OpenVPN tun devices should always be 1500 bytes. That doesn't require any MSS fixing because the MTU of all NICs (GREEN, BLUE, etc.) is always 1500 bytes. Anything else is probably difficult to run. But since we have this configuration out there now, there is probably no way to migrate this. IPFire doesn't really support jumbo frames. So we shouldn't consider that. What if we only offer a field to configure the MTU for new connections?
In fact the OpenVPN MTU needs place for the overhead (encapsulation etc.) that´s why Mssfix has been set to 1450 by the OpenVPN people. If Mssfix has a value, fragment uses the same accept a different value (fragment [value]) has been set in the configuration files. Also in some cases it might makes sense according to the infrastructure to use much smaller MTUs (satellite links, smartphones, etc.) An own MTU field for every connection would causes problems cause the settings should be equal on both sides even OpenVPN do works on that topic, in 2.4 version is also already an MTU adjustment via connection ID findable. In my opinion i think we are currently OK with the current state, and this bug can be closed if no other thoughts/ideas arises ? Erik
On Mon, 2018-06-18 at 15:00 +0000, IPFire Bugzilla wrote: > Also in some cases it might makes sense according to the infrastructure to use > much smaller MTUs (satellite links, smartphones, etc.) Yes, but you never really know the MTU to the other side. Routers on the way will fragment the packets when they need to. > An own MTU field for every connection would causes problems cause the settings > should be equal on both sides even OpenVPN do works on that topic, in 2.4 > version is also already an MTU adjustment via connection ID findable. I thought we are talking about N2N here which run an own process each and should be independent from each other. > In my opinion i think we are currently OK with the current state, and this bug > can be closed if no other thoughts/ideas arises ? Yes, I suppose so. Potentially we can make documentation really clear about this. I am okay with this being closed.
Yes, even OpenVPN offers a MTU test the values can change for the mentioned uplinks. For N2N the possibility is there to adapt the MTU (mssfix, fragment) for each connection since there are mostly static infrastructures involved it makes more sense to test the connection via MTU-Test and configure it for the possible best values. With OpenVPN-2.4 some new core functionalities comes for this topic and some additional infos can also be added to the wiki, can make there soon some more. Best, Erik
Hi, is this bug still valid?
At least not with my current configuration, but I can't say if those messages would also not appear on connections created with a fresh install of IPFire.
Hi all, (In reply to Peter Müller from comment #26) > Hi, is this bug still valid? in fact this are only "Warnings" and no bugs. Since we have three in here i would comment to one-by-one. 1) The "WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead" has been patched with Core 115 --> https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=b66b02ab73863bcb9130300d8ef0eecdc51efde3 but needs nevertheless user interaction to renew the PKI since OpenVPN will drop the "--ns-cert-type" directive with version 2.5. For further information please take a look in here --> https://forum.ipfire.org/viewtopic.php?t=18852 . 2) The "WARNING: INSECURE cipher with block size less than 128 bit (64 bit):" message will be managed by OpenVPN itself if the usage of weak ciphers (64bit block cipher), which are outlined in IPFire as such, are detected. According to the Sweet32 exploit --> https://sweet32.info/ the session key will be automatically renewed after 64MB data transfer. Nevertheless AES-GCM should be used! 3) "WARNING: normally if you use --mssfix and/or --fragment :" is a configuration hint from OpenVPN. As in the link to the OpenVPN mailinglist explained, the best practice is to leave the tun-mtu to 1500 and use the "--fragment" value to handle the paket size via --mssfix and --fragment. There is a patch available in here which disables mssfix (set it to 0) if the MTU != 1500 and --fragment and --mssfix is deactivated but this would breaks in a kind the described best practice --> https://openvpn.net/archive/openvpn-users/2004-12/msg00037.html . So in my opinion the only one which needed to be (would say updated not fixed) was point 1) which has been done with Core 115. But may there are other ideas ? Best, Erik
3) I have just recreated my OpenVPN host certificate (and created empty files for "server.conf" and "settings" in "/var/ipfire/ovpn") and got a MTU of 1400 not 1450 (as mentioned above). Therefore, I still get the warning about mssfix on connecting a roadwarrior. @Erik: You wrote "the best practice is to leave the tun-mtu to 1500" (and not apply the patch), but for me it seems like the default is NOT 1500. Also, the link you provided is dead (couldn't find a working one).
Hi Larsen, (In reply to Larsen from comment #29) > 3) > I have just recreated my OpenVPN host certificate (and created empty files > for "server.conf" and "settings" in "/var/ipfire/ovpn") and got a MTU of > 1400 not 1450 (as mentioned above). Therefore, I still get the warning about > mssfix on connecting a roadwarrior. 1400 is the default in server.conf. 1450 is the max. if mssfix is not deactivated via 'mssfix 0' which IPFire currently do not provide. The appended patch above addresses this. > > @Erik: > You wrote "the best practice is to leave the tun-mtu to 1500" (and not apply > the patch), but for me it seems like the default is NOT 1500. Also, the link > you provided is dead (couldn't find a working one). Which link ? Best, Erik
This one: https://openvpn.net/archive/openvpn-users/2004-12/msg00037.html
OpenVPN seems to clean up their archives. In essence you can find the same here --> https://sourceforge.net/p/openvpn/mailman/message/13218191/ also from the same author. What question do you have regarding to the above statement ? Erik
I wanted to read about the best practice you mentioned. The new link should provide that.