Hello,
I just re-read Michael Tremel’s blog post from 2020 “Why not Wireguard”
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)
Thanks, John
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.
Anyway, it didn’t seem to hurt to ask.
Indeed it doesn’t hurt.
What is wrong that you cannot use OpenVPN?
Many benchmarks indicate that in my application Wireguard is quite a bit faster, but even more important to me is the near instantaneous handshake vice a much longer handshake on OpenVPN.
Okay, but how much bandwidth do you have that OpenVPN is becoming a bottleneck?
And how many handshakes a second do you perform? As a home user this should not really matter at all.
Hi Michael,
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.
Thank you, John
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.
So if there is someone out there who needs to use wireguard and has the programming skills required to create the IPFire menu cgi page and the interaction with the wireguard program then I would suggest they should join the Development mailing list and offer their services.
https://wiki.ipfire.org/devel/contact
https://wiki.ipfire.org/devel/mailing-lists
Hello Adolf and Michael,
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.
Sincerely, John
Hi John,
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.
Hi again and thank you again Michael and Adolf for replying.
I’m using an APU2e4 so I don’t think OpenVPN will be able to saturate it, but that is ok.
Also, are you able to share a progress update on IPFire 3 and maybe even forecast a timeframe?
Cheers, John
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.
I absolutely agree. This is why we are funded by donations. So practically everything is funded by the community.
However, Wireguard is not at the top of the list. We have some things that have some higher priority first (e.g. IPv6 and some other things around the base system). But after that, why not?
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.
Hi,
welcome to the IPFire community. 
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,
Peter Müller
If that is true, you probably misconfigured OpenVPN. It is technically slower, but not by that much.
I know I necro an old thread even over two years later. But things should stay together, and I appreciate the blog and this thread. I wanted to throw a new use case in. Don’t get me wrong, not begging for the implementation, have it running on a home assistant but I would be interested with other interested, to help implementing it into the core or at least as add-on.
MCUs with RISC architecture running something like a dual core 160 or 80 MHz with 1 MB of RAM. IoT, sensors, small GPS trackers, watches with ESPs and RPI2040 or other microchips, where micro is still ruling (compared to an I5 GEN11 or ARMs in our phones) connected over NB-IoT or other LoRa/low bandwidth networks.
Some of them provide functionality for FW updates through cloud services mostly using unknown protocols (at least to the user), but we want local update servers that talk to those devices, we want to be able to remotely control them or transfer barcodes, sensor values or even pictures from them to our systems behind the IPFire firewalls.
Sure, there are other solutions, like in LoRa, wait for the sensor to contact the server, then tell the sensor to start the download, which might be even better for battery powered devices. But those powered by mains or similar (cars, trucks, trains, solar, wind, etc.) can stay active in the network and can respond to inputs, like displays at the gate 1 km away from the house or a gps tracker in a truck.
For those devices it does not matter if you manually need to assign an IP, you are happy they are able to connect to your network. You are happy when they do not send the barcode or location in plain text. You are happy when you can open the web interface to check the sensors, which naturally comes on port 80, unencrypted as expected.
You offered two routes in your post, donation and community.
I am up for both. Who is willing to start the journey with an add-on and if we need help we can ask the pro support around Michael, Arne and Peter by exchanging some of the colorful papers.
Cheers,
Alex
Edit reason: typos