IPFire behind AVM 7590AX making sense?

Hi, my network has grown over a couple of years to five AVM Fritzboxes running 90+ IPV4 nodes in the network. The amount of Fritzboxes is due to the building situation and WIFI coverage and the simplicity of using their MESH technology.
Wrt firewalls so far I solely rely on the FW built into the 7590AX, for DNS a PiHole is used.
Now I am thinking about increasing security for my core PCs, Server and NAS devices, by putting those behind an IPFire, where the IPFire shall remain behind the Fritzbox router, i.e. not become an exposed host. I’d also like to keep my WIFI devices else it would require four additional WiFi access point which I want to avoid. Due to the lack of cabling I also have to deal with the caveat to run all traffic over the same layer two switches, red and green traffic :frowning: .

Here is a simplified schema of the network Left is as-is right is to-be

I am aware I would need to drill some holes to allow admin PC to work across all LAN segments, but that is config stuff and shouldn’t be a big deal.
However before I start to finally implement an IPFire I’d like to ask you if this setup makes sense at all or if the switch issue would limit the increase of security I hope to get.

txs

Carlos

Update: Just figured out VLAN switches are quite cheap meanwhile, so replacing the switches would be an option.

Hi,

welcome to the IPFire community. :slight_smile:

While the link to your network schema gives a 404 to me, I guess I am still able to help you thanks to the detailed description:

Everything is fine here…

As you already relaised, this is where trouble starts.

You will need to either use distinct VLANs for the two network zones, and upgrade your switches to support VLANs, or use a dedicated layer 1 connections.

Personally, I’d prefer the latter for security reasons. Should the VLAN implementation in any involved component be vulnerable, or there is a misconfiguration in place, IPFire can be silently bypassed. Dedicated layer 1 connections are less flexible, but more secure, and error-prone to software issues or misconfigurations. :slight_smile:

Thanks, and best regards,
Peter Müller

1 Like

@pmueller Thanks for your help Peter, (fixed typo in link, sorry about that)
So bottom line some additional cabling is the way to go as far as I understand. Unfortunately as of today I have no option to run additional cables through the house and shop, but I’ll give it some thoughts.
Meanwhile I’ll make myself more familiar with the IPFire, VLANs and DNS… I still have the PiHole which I understood isn’t the best option and shall be dropped and make IPFire taking over DNS… So far I like PiHole’s UI which let me know what’s going on with my clients, so before I shut this down…more stuff to be read I guess.
Best
Carlos

Its me again…after reading some DNSSEC stuff my personal view, pls correct me if I am wrong., is as follows:
I should use DNSSEC as this provides more security, not 100% but better than w/o it
The global DNSSEC availability is just a bit over 25%
PiHole is capable of handling DNSSEC
If I keep my PiHole with DNSSEC acticvated AND my DNS resolver test is OK, I am at least gaining a bit of security.
Keeping in mind my network is a home LAN I should be OK with slightly degraded performance by using DNSSEC

Again, this is what I derived from redings with my limited understanding. Happy to get your view and corrections where required.

Txs C.

IPFire uses DNSSEC also.

@bbitsch I do understand this, but as I have the PiHole set up and running since quite some time, I got used to the GUI and I really do like it. So I want to avoid trashing PiHole and try to build a decent coexistence.
I would have trashed PiHole though IF there would be significant risks compared to using DNSSEC with IPFire, but this doesn’t seem to be the case, seen from a home LAN admin :wink:

@Carlos Breeze:

I also still use a Pi Hole, although I now use the proxy.
Reason: The proxy filters ridiculously few trackers with standard lists like from Shalla. It may be that you can do better with the proxy. But then you need much better lists that also work.
If interested, check out my post in the link below or the thread linked there.
So far I can not see where there should be disadvantages. I can only see advantages. But maybe I am blind?

Hi Carlos,

wish you a happy new year!

My advice for you is to read the IPFire Series Part 2 on Kuketz-Security-Blog - but you will have to translate it from german into spain (or english - I guess). There you find how to implement the functionality of PiHole on IPFire by using the script dns_blocker.sh - it’s quite easy but without any UI.

Later you could virtualize ioBroker and RaspbarryMatic on IPFire (via Qemu/KVM).

Regards,
Marc

@mroland thanks for the recommendation and a happy new year too. I,'ll read the blog tonight. (German is no problem)
Wrt. Iobroker and Raspimatic, ioBroker and some other stuff is running on a NUC / Proxmoxx in different VMs already. My first thoughts indeed were to run everything virtualized but as I am not a Linux expert I have chosen to have some system as a dedicated setup.
Having my Proxmoxx VM learning curve in mind I am pretty sure I would mess up IPF if I put other stuff on top :sweat_smile:. But hey, you never know…

@mroland Hi Marc, I checked out the blog, which is absolutely worthwhile to read in general.
For testing I shut down PiHole and I installed the script which worked right away.
Did some testing with nslookup, looks all OK :slight_smile:
I did enable the logging, but all I can get is something like this:

19:26:06	unbound: [14656:0]	info: server stats for thread 0: 10 queries, 0 answers from cache, 10 recursion s, 0 prefetch, 0 rejected by ip ratelimiting
19:26:06	unbound: [14656:0]	info: server stats for thread 0: requestlist max 59 avg 9.7 exceeded 0 jostled 0
19:26:06	unbound: [14656:0]	info: average recursion processing time 0.188664 sec
19:26:06	unbound: [14656:0]	info: histogram of recursion processing times
19:26:06	unbound: [14656:0]	info: [25%]=0.04096 median[50%]=0.174763 [75%]=0.305835
19:26:06	unbound: [14656:0]	info: lower(secs) upper(secs) recursions
19:26:06	unbound: [14656:0]	info: 0.008192 0.016384 2
19:26:06	unbound: [14656:0]	info: 0.032768 0.065536 2
19:26:06	unbound: [14656:0]	info: 0.131072 0.262144 3
19:26:06	unbound: [14656:0]	info: 0.262144 0.524288 3
19:26:09	unbound: [17026:0]	notice: init module 0: validator
19:26:09	unbound: [17026:0]	notice: init module 1: iterator
19:26:09	unbound: [17026:0]	info: start of service (unbound 1.13.2).
19:26:09	unbound: [17026:0]	query: 192.168.168.43 dl.acronis.com. A IN
19:26:09	unbound: [17026:0]	query: 192.168.168.43 dl.acronis.com. A IN
19:26:09	unbound: [17026:0]	reply: 192.168.168.43 dl.acronis.com. A IN NOERROR 0.455726 0 131
19:26:09	unbound: [17026:0]	reply: 192.168.168.43 dl.acronis.com. A IN NOERROR 0.455726 0 131
19:27:04	unbound: [17026:0]	query: 192.168.168.43 www.googleapis.com. A IN
19:27:05	unbound: [17026:0]	reply: 192.168.168.43 www.googleapis.com. A IN NOERROR 0.064878 0 100
19:27:05	unbound: [17026:0]	query: 192.168.168.43 www.googleapis.com. A IN
19:27:05	unbound: [17026:0]	reply: 192.168.168.43 www.googleapis.com. A IN NOERROR 0.000000 1 100
19:27:08	unbound: [17026:0]	query: 192.168.168.43 dl.acronis.com. A IN
19:27:08	unbound: [17026:0]	reply: 192.168.168.43 dl.acronis.com. A IN NOERROR 0.012727 0 131

What I liked with PiHole was the option to get an overall view about what my clients are doing.
Am I missing something or is this a true fire and forget solution, i.e. set up once and let it run ? Which is OK if it works, don’t get me wrong.