Question, Now that IPFire 2.27 - Core 159 and up are on LTS Linux kernel 5.10, does this change anything regarding future plans for Wireguard support? (Wireguard entered the Linux kernel at version 5.6)
The flaws Michael mentioned are not in the Linux kernel or Wireguards integration therein, but in the design of Wireguard itself.
So your question can only be answered by investigating the actual design of Wireguard
The genesis of my post was speculation regarding the following.
When Michael first wrote that blog post, IPFire was on an older kernel that did not include Wireguard, which would have made inclusion much more difficult, and essentially, not worth the effort. Now that it is in the kernel, I was wondering if Wireguard inclusion would be much easier.
Most of Michael’s observations in that blog post are regarding the application of Wireguard in a corporate environment, however, I am a home user, and most of those observations don’t apply for home users. Wireguard appears fairly ideal for a home user, even if not ideal for a corporate network.
Thank you for your replies, you are very generous with your time.
Bandwidth - I have a 1Gbps fiber connection.
Also, I have not used a VPN before, I have been reading extensively about how to set one up and these questions are in preparation for that. One of the attractions of Wireguard is that there are far fewer parameters for the client side configuration. This is an advantage for someone like me who doesn’t have much networking experience.
Based on your essay, it was clear that it just wasn’t worth it to include Wireguard, however, now that it is in the kernel, I was just wondering if implementing it might be sufficiently lower effort as to now be worth it.
Just to add another voice of support: It would be great if Wireguard could be considered for inclusion. I’m another similar user as John in that it would be helpful to be able to have a choice to access a Wireguard VPN (vs OpenVPN) with an almost 1Gbps connection.
I would also make the observation that the IPFire Core Team is small and with all the work required on IPFire 2.x to fix bugs that are found or deal with security issues that are discovered, they are already struggling to work as much as they would like to on IPFire 3 which solves some of the infrastructure problems of how the core part of IPFire was originally developed.
So to have IPSec, OpenVPN and Wireguard in IPFire someone needs to step up who has the programming skills and can create the cgi screen and make wireguard work in a secure way in the IPFire system and commit to supporting that package on a long term (multi year) basis otherwise the resources would need to be taken from somewhere else.
Thank you for your replies. I understand, and my thread was not intended to be a whining and demanding screed from some ungrateful user. I was just asking because I was wondering if kernel inclusion might make it sufficiently easy for your team to implement. Now I know the answer.
I will maintain hope for the future but also look forward to all of your efforts for version 3.
Thanks again for taking the time to reply and thank you for all your very hard work.
I didn’t read your thread in that vein and my apologies if my reply came across as though I had.
I just wanted to communicate to the wider forum that the IPFire team is always happy to accept and welcome new people willing to support the development activities.
That also applies if, like me, people don’t have very skilled programming capabilities but are willing to try and learn. There are simple bugs in the IPFire bugzilla that people can try out first. You do need to go through the wiki pages on git and patches etc.
I started out in that way supporting the bacula add-on and then started with some simpler bugs. Two years ago when I started with this I could just about spell git but that was it. I learned as I went along.
Good luck with your use of IPFire and keep asking the questions.
Cool. Provided sufficient hardware, OpenVPN can saturate such a link.
This isn’t a problem, because with IPFire, you simply download a configuration file for the client that you will have to import into the client and you are ready to connect.
No, it is still a massive task to do if we want to do it right and I personally have currently no resources for this.
I don’t think anyone saw it like this, but generally we are confronted with that opinion a lot. People who believe that they are “entitled” to this and who send us “pretty” messages and tell us how “shitty” our software is and that it “DOES NOT WORK”, although it is them who don’t know basic things on how to set up a network.
Yes, I personally would like to move away from IPFire 2 as soon as possible and leverage all the code that was already written for IPFire 3. Integrating Wireguard there would be a fraction of the work it would be in IPFire 2.
It would appear to me that the only way the IPFire team are to get version 3.x out of the door is to place a change freeze on 2.x branch. i.e. no new features, just critical security fixes. Now that IPFire 2.x is running on a newer kernel that fits better on modern hardware, should give some breathing space to progress development on 3.x.
Just an idea: How about you let the community pay for it? If there is really such a big interest in getting this properly integrated into IPfire, why not doing a fundraising for this specific feature?
I understand that you don’t really see the need for it, but in terms of making the digital world a bit safer I guess it would be better if trusted people like you integrate it than the users turn to some other half-baked solutions. In the GUI you could even “educate” the users about the pros and cons. Maybe in the end it’s a win:win. If the fundraising fails, then we also know that the use case is just not there, not from a technical perspective and also not from a user-demand perspective.
Hello. Any changes to this? Actually every other router firmware does support Wireguard now. And where OpenVPN uses 100% of CPU we have Wireguard on idle CPU usage.
You may check out how RouterOS (Mikrotik) implemented that, we have no problems using that.
I take the liberty to reply on Michael’s behalf: No, this still is not a priority to us. At the moment, we focus on finally getting IPFire 3.x ready, since topics such as IPv6, a more flexible network configuration, and a less monolithic update scheme become more and more pressing.
Sorry to disappoint, and best regards,