Hello everyone.
Core Update 196 is now available for Testing.
https://www.ipfire.org/blog/ipfire-2-29-core-update-196-is-available-for-testing
As always we greatly appreciate any testing feedback, bug reports on any newly introduced regressions, etc.
Looking forward to your feedback.
Hello Community,
Core Update 196 out for testing—thanks for starting the thread, Adolf!
A couple of highlights to check out:
WireGuard gets better with this update. You can monitor connections on the Home WUI page, and there are performance tweaks for handling more traffic or multiple tunnels. Some net-to-net issues identified with Core Update 195 should also be fixed.
The console graphics have had a big upgrade. It now uses a modern system (Linux DRM) for sharper text and higher resolutions, like Full HD or 4K. Test it out and see if it works smoothly with your hardware.
There’s also improved firewall rule tracking, some IPsec security upgrades, and a bunch of updated packages (ClamAV, Git, QEMU, and more). Plus, a new add-on called FORT Validator. The blog post has the full list.
Looking forward to hearing how it goes in your setups!
Thanks,
A G
Hello dev team,
first of all thanks for the update! - I gave it a try just an hour ago on two virtualized systems running core195 Development Build: master/4e8f4314 which should be identical to the actual stable version.
The reboot screen showed a huge number of errors like 'iptables v1.8.11 (legacy): unknown protocol “…”. My review showed that at least many (if not all) customer defined services and service groups were translated with errors, for example:
The previously defined service PING_REQUEST (icmp echo request) was changed to “tcp” without a port number. Other customer defined services (e.g. MS/SMB) were also affected. The system booted, but the firewall rules were not functional any more. As these virtual systems are in production use, I rolled back immediately, so I regret not to be able to deliver further information.
I have updated 4 vm IPFire systems and none of them showed any of those messages at all.
Only one of my vm systems has firewall groups defined and that is just Hosts entries.
Can you give more details of the sorts of services and service groups you have created. I can then look at adding them to a CU195 clone and then doing the update to CU196 Testing to see if I can reproduce the problem you described.
It is the /var/ipfire/fwhosts/customservices file that was overwritten by the upgrade!
I will have to look at that.
Back in CU193 an addition was made to the default customservices file but the updated file was not shipped so it never got deployed.
That was identified recently and the shipping of the customservices file was carried out in CU196 Testing.
It looks like we need to do that differently to get the additional default service in any existing lists.
I will think further on the best way of doing this.
If you have this problem doing a restore from your backup carried out before doing the update will restore your previous customservices file but without the additional service of DNS over TLS.
I have submitted a patch to revert the shipping of the new default customservices file.
This will mean that any fresh install will have the updated default customservices file with the “DNS over TLS” entry but the upgrade will leave the existing customservices file alone.
Thank you. Merged!
Hello @bonnietwin ,
thanks - as the cause of the problem was identified (while I did nothing), you don’t need further details of my custom defined services. So I will give it another try.
Wait a while though.
The patch has been merged but now it needs to be built before it will be available for the upgrade.
When this file in the builds tree includes the core196: Revert ship of customservices from fwhosts patch in the list then the CU196 Testing update can be carried out again.
EDIT:
Forgot to include the link to the file
https://nightly.ipfire.org/master/latest/x86_64/changelog.txt
The build has been completed now for the x86_64 architecture so you can now test out the CU196 Testing update again.
Hello
The update went smoothly and has been running for a couple of hours.
But I am still seeing this issue with the IPS logs.
It is enabled, but no log since last update.
Danny
Hello Adam G
What do you mean with “Some net-to-net issues identified with Core Update 195 should also be fixed.”. I am planning on replacing an OpenVPN net-to-net connection by a WireGuard net-to-net connection on a place where I have limited access to. OpenVPN worked great so far but I would also appreciate a higher throughput with WireGuard. So the issues you mention lead me to thinking that I might better wait for final 196 release.
The following is a test to check the working of the suricata engine to detect something and log it.
If you don’t have the Emergingthreats.net Community Rules Ruleset installed then install it.
The select the emerging-attack_response.rules entry. There is a rule within that group that is enabled by default called
GPL ATTACK_RESPONSE id check returned root
Then got to a machine on your green network or you can also do this via your IPFire terminal (ssh or console) and run the command
curl http://testmynids.org/uid/index.html
The command will not complete as it will be blocked so you will need to press Ctrl-C.
You should then see the following entry in your Logs - IPS Logs WUI page.
I just did the test myself and here is the result I just got.
This rule has been especially created for this testing situation and is documented in the Suricata manual.
https://docs.suricata.io/en/latest/quickstart.html#alerting
If this works but you have a problem with the Talos VRT rules then I have read that this could be because those rules are designed to work with Snort rather than with Suricata.. They will also work (in most cases) with Suricata but some things will not function the same and maybe the logging is defined differently in their signatures. I think the same thing happens the other way round. Not all rules designed for Suricata will fully work with Snort.
This patch was included in Core Update 196 which fixes some routing issues.
Core Update 196 also contains two changes which should improve throughput. I mentioned them both in this post.
This is what testing is for 
feel free to test Core Update 196 which has gone into testing.
It’d be interesting to hear about the performance improvements over your OpenVPN setup once you’ve migrated.
Thanks,
A G
OK, Adam G. You’ve asked for it. So I did a little test. I have two networks at different locations.
Location 1: Fiber 100 Mbit up/down
Intel(R) Celeron(R) CPU N2930 @ 1.83GHz x4
(note that this CPU does not feature AES-NI)
IPFire Core 195
Location 2:
Fiber: 1 Gbit up/down
Intel(R) Celeron(R) J6412 @ 2.00GHz x4
(this CPU features AES-NI)
IPFire Core 195
I connected theses sites with OpenVPN (AES-GCM-256 and SHA2-512). Then I pulled a Windows ISO-file from location 2 down to location 1.
Result: speed is going up and down between around 6 and 8 MB/s
Then I disconnected the OpenVPN connection and activated the WireGuard connection between these sites. I started the same copying again. This time a different ISO just to make sure there is no caching etc. involved.
Result: speed is now at 10 MB/s. So it’s at the maximum that I can expect from the 100Mbit connection I have.
Interestingly, the speed does not fluctuate much. It’s at a constant 10.2 to 10.4 MB/s. I tried different large ISO-files and always got the same result.
So on my hardware net-to-net speed is definitely much faster when using WireGuard.
I also tried a roadwarrior scenario: I connect to Location 2 using my laptop at home (LAN, 100Mbit Internet connection) and downloading that file again.
With WireGuard I got around 9.5 MB/s and OpenVPN around 6 MB/s. Other family members were online gaming so that might explain why the speed was slightly slower than the net-to-net connection in my office.
So from my experience: WireGuard is definately faster and was only limited by the 100Mbit/s internet connection where as on OpenVPN I could not fully saturate the internet speed I have.
Hope you find this little test interesting and helpful. If other people are using OpenVPN for their site-to-site connection, I can really recommend trying out WireGuard. You can switch between these to VPN technologies without having to reboot. I simply made sure that they are not both switched on at the same time.
And there is another advantage I have realised. When I’m at home I can use OpenVPN on my laptop to connect to the office at location 1 or location 2. But not at the same time. It’s one OR the other. With WireGuard I can simply activate both tunnels at the same time so I can access both locations simultaneously.
That’s awesome, @alain !
Did you have IPS activated on your VPNs during testing, or no?
Nice post, @alain.
Great to see that—even on Core Update 195, before the latest performance tweaks—your 11-year-old N2930 can still comfortably max out your 100 Mbps line.
Cheers,
A G
Have you tried the following method?
Regards
IPS was active, but only on RED and GREEN.
I just did a quick check and activated IPS on WireGuard on the server-side and pulled the ISO down to the client-side. Still full 100 Mbit transfer. But then I activated IPS on the client side (the one with the weaker/older CPU) and transfer immediately dropped to 25 Mbit). I’ll do some more testing and comparison with OpenVPN too. Also I wonder if it makes a difference if I push or pull a file over the tunnel. Anyway, it looks like IPS definitely does have an impact on throughput. But that makes sense, doesn’t it.
These are the rulesets that are identical on both sides:
