IPFire on Raspberry Pi 4B - Observations and Questions

[lexuspolaris]

Hello community,

I stumbled upon the IPFire-Project on the kuketz-blog a couple of weeks ago and have been on fire ever since (pun intended ). Although I have some experience with networks (CCNA Routing & Switching), I’m far away from being an expert and my knowledge regarding firewalls is little. So please bear with me here. =)

Anyway, I was very excited about the project and wanted to get to know IPFire on a small basis in my home environment and so I bought a Raspberry Pi 4 (8GB) and followed the instructions on the website. My board is from 2018, so I’m not affected by the problem with/without the firmware EEPROM. Installation was totally simple and everything works. However, I made some obervations and came across some problems, I wanted to share with you. Maybe it could help other people, too.

First of all, my setup:

(attached to a USB3-Port of the Pi is a Delock-USB-to-LAN-Adapter capable of Gigabit-speed, correctly identified and supported by IPFire due to its Realtek 8153 Chipset).

Please! Please! Please! No judgement about the logic of the structure! Originally I wanted to use the Pi as an AP too but the internal WiFi-chipset is just to weak and is only capable of about 50mbit/s max when acting as an AP (even with 802.11ac activated and not only HT-Caps, but also VHT-Caps “registered”). I still got a AlfaNetwork AWUS1900, but hence that I’m not a linux “pro”, I hesitate trying to implement the driver by compiling IPFire new or building an AddOn or whatever you have to do .
Apart from that, Laptop and Smartphone are protected on client-site and the MFP and the NAS are only occasionally running and have no internet-acces (blocked by the FritzBox). So the fact, that only the Desktop-PC is behind the firewall is ok with me, so please so judgement. =) Additionally IPFire serves as a DNS-Server (with some blockling lists) for all the devices.

Now my observations / questions.

1. With masquerading deactivated (and the correct firewall-rules of course), I can reach the FritzBox, the MFP and the NAS from the Desktop-PC. If I want to reach any of the WiFi-clients (Laptop for example) I have to activate masquerading. I tried without masquerading (at whole) and just punching in the source-nat-option within a firewall rule but that doesn’t seem to work. I guess the FritzBox is the problem here, I guess all the wired devices are on the same “bridge” and therefor can reach each other without any problems, but for the WiFi-clients there is some kind of interface-change necessary (client isolation deactivated does not do the trick). Any ideas or explanations?

2. Sadly I had to realise, that the throughput over the wired connection (when transferring data from the NAS to the Desktop-PC) is about 250mbit/s tops. I checked via htop and saw that the first core of the Raspberry is at 100%. Oddly enough, when I transfer data from a Laptop to the Desktop at about 200mbit/s the core was only at about 40%. I guess the problem here is the “queueing” of the data packets, because the NAS pushes with 1.000 whereas the Laptop only gives about 200. Is there some way to improve the ethernet-speed?

3. I fiddled around with fcrontab to automatically update my blockling list for the dns and found some entries, I thought of as a bit “too much” like: “testing run-parts” every minute and every 5 minutes, timechecking every 5 minutes, ddns-update every 5 minutes, connection scheduler every 5 minutes, etc. Is this really necessary (again, I’m no expert ) or would it be enough to reduce this intervals? I guess it’s not that performance consuming, so this question is just out of interest. =)

So, that’s it from me for now. I’m sorry for the long text but I wanted to contribute as detailed as it gets.

Thanks very much to the IPFire-team, keep up the good work, donation is on the way.

Greetings

Alex

[pmueller (Peter Müller)]

Hi,

first, my apologies for the tardy reply. I thought I wrote a response earlier, but now see I did not.

I will comment on your observations and questions inline…

@lexuspolaris

I stumbled upon the IPFire-Project on the kuketz-blog a couple of weeks ago and have been on fire ever since (pun intended ).

Glad to hear IPFire is being useful for you.

@lexuspolaris

I’m far away from being an expert and my knowledge regarding firewalls is little.

Should you not have already read those, please have a look at this and this blog post. Perhaps they are helpful as well…

@lexuspolaris

With masquerading deactivated (and the correct firewall-rules of course), I can reach the FritzBox, the MFP and the NAS from the Desktop-PC. If I want to reach any of the WiFi-clients (Laptop for example) I have to activate masquerading. I tried without masquerading (at whole) and just punching in the source-nat-option within a firewall rule but that doesn’t seem to work. I guess the FritzBox is the problem here, I guess all the wired devices are on the same “bridge” and therefor can reach each other without any problems, but for the WiFi-clients there is some kind of interface-change necessary (client isolation deactivated does not do the trick). Any ideas or explanations?

Yes: If I understood you correctly, the WiFi clients are in a different subnet than the MFP and the NAS. If so, you will need to configure a static route in IPFire to the subnet not directly “visible” on its RED interface, so it knows where to route the traffic to.

@lexuspolaris

Sadly I had to realise, that the throughput over the wired connection (when transferring data from the NAS to the Desktop-PC) is about 250mbit/s tops. I checked via htop and saw that the first core of the Raspberry is at 100%. Oddly enough, when I transfer data from a Laptop to the Desktop at about 200mbit/s the core was only at about 40%. I guess the problem here is the “queueing” of the data packets, because the NAS pushes with 1.000 whereas the Laptop only gives about 200. Is there some way to improve the ethernet-speed?

While the overall system requirements for IPFire are rather low, having good NICs is very important. Raspberry Pis neither were designed for such purposes, nor are they really suitable for it - as you observed, even saturating a 1 GBit/sec link is tricky.

For a evaluation setup or a “firewall in a pocket” (some people in the project carry a SBC around as a firewall when traveling), a Raspberry Pi is fine. In the long run or for a professional environment, please consider using a decent machine for your IPFire installations. See here for buying considerations and some turn-key appliances.

@lexuspolaris

I fiddled around with fcrontab to automatically update my blockling list for the dns and found some entries, I thought of as a bit “too much” like: “testing run-parts” every minute and every 5 minutes, timechecking every 5 minutes, ddns-update every 5 minutes, connection scheduler every 5 minutes, etc. Is this really necessary (again, I’m no expert ) or would it be enough to reduce this intervals? I guess it’s not that performance consuming, so this question is just out of interest. =)

No, especially if you have the IPS enabled, Cron jobs do not matter in terms of load and performance at all.

ddns-update every five minutes makes sense to update DDNS records quickly after reestablishing internet connectivity, so services are quickly back online and reachable again.

In general, we do things wisely here, and the core developers can be quite picky while discussing whether a change lands into the distribution or not. Tedious, but that keeps the quality up.

However, should you want to change or improve anything, please do not hesitate to contribute to IPFire. Please refer to this page for further information on how to do so.

@lexuspolaris

So, that’s it from me for now. I’m sorry for the long text but I wanted to contribute as detailed as it gets.

Thank you for your detailed feedback. Feel free to ask questions here any time.

@lexuspolaris

Thanks very much to the IPFire-team, keep up the good work, donation is on the way.

Lovely. Thank you very much.

Best regards,
Peter Müller

[lexuspolaris]

@pmueller

Hi,

first, my apologies for the tardy reply. I thought I wrote a response earlier, but now see I did not.

Hey Peter,

no need for apologies, thank you very much for the response.

@pmueller

Should you not have already read those, please have a look at this and this blog post. Perhaps they are helpful as well…

Thanks for the links, it will be my bedside reading.

@pmueller

Yes: If I understood you correctly, the WiFi clients are in a different subnet than the MFP and the NAS. If so, you will need to configure a static route in IPFire to the subnet not directly “visible” on its RED interface, so it knows where to route the traffic to.

Not quite right. The WiFi clients and the MFP and NAS are in the same subnet (192.168.2.0/24), just like the red interface. And that’s the weird thing, because MFP/NAS are reachable without masquerading but the WiFi clients are not. Anyway, I guess the “fault” lies somewhere in the interfaces/routing of the FritzBox. Never meant to bother you IPFire-Guys with this, just wanted to ask, because maybe some other member of the community could verify this behaviour.

@pmueller

While the overall system requirements for IPFire are rather low, having good NICs is very important. Raspberry Pis neither were designed for such purposes, nor are they really suitable for it - as you observed, even saturating a 1 GBit/sec link is tricky.

I already thought so, thanks for the clearing up. Because it’s just for my home-set-up, it doesn’t bother me that much. It’s still fast enough for the internet-speed and I’m not transferring files from/to the NAS that often, so it’s ok. Maybe the speed increased with the new kernel, had no time to test it, yet.

@pmueller

No, especially if you have the IPS enabled, Cron jobs do not matter in terms of load and performance at all. […] In general, we do things wisely here, and the core developers can be quite picky while discussing whether a change lands into the distribution or not. Tedious, but that keeps the quality up.

Ok dok, good to know… Didn’t mean to tread on anyones foot here.

@pmueller

Lovely. Thank you very much.

Thank you guys! May you all have a Happy New Year!

Alex

[pmueller (Peter Müller)]

Hi,

@lexuspolaris

Not quite right. The WiFi clients and the MFP and NAS are in the same subnet (192.168.2.0/24), just like the red interface. And that’s the weird thing, because MFP/NAS are reachable without masquerading but the WiFi clients are not. Anyway, I guess the “fault” lies somewhere in the interfaces/routing of the FritzBox. Never meant to bother you IPFire-Guys with this, just wanted to ask, because maybe some other member of the community could verify this behaviour.

I see, thanks for elaborating on this.

While I cannot rule out a missing configuration on IPFire completely, the FritzBox might do some separation between LAN and WiFi clients here - even if they are in the same subnet on layer 3. Perhaps WiFi clients experience different routing, or something similar. Unfortunately, I am not familiar with FritzBox internals.

@lexuspolaris

Didn’t mean to tread on anyones foot here.

No harm done.

Thanks, and best regards,
Peter Müller