What a great tool IPfire sounds to be. Unfortunately, however, after spending hours trying to set up and reading various forums, including the Wiki, I’m unable to get IPfire to work on my RPi4. So, I wonder if you’d help clarify a few points:
Downloading an image onto the SD card doesn’t seem to be working on my RPi4, no matter what card I use. There’s an endless boot thingy (error -5 or something). Downloading an image onto a USB drive seems to be working in that I can load IPfire and try to set it up. I’ve found this post (Raspberry Pi 4 Model B Rev 1.5 - error -5 whilst initialising SD card - #7 by wiesel), but building an image is beyond my ability at the moment. I hope that this doesn’t also mean that I should not be using IPfire because it’s meant for an advanced user.
Not sure what I’m doing wrong, but I’m unable to set the red zone. My set up is:
a) a Fritzbox 7530 connected to a DSL line (VDSL profile 17 here in the UK; dynamic IP address) which functions as both a DSL modem and router;
b) a RPi4 running IPfire is then connected to Fritzbox via an ethernet cable;
c) I also have Devolo Magic 1 adapters (LAN and WLAN) and I used the WLAN one to set up IPfire (by having an ethernet cable connected to its LAN port), given the distance between my TV used to set up IPfire and the Fritzbox. I chose the ‘bridge’, then when it didn’t work, ‘PPPoE’ options, but neither seems to be working in that when I try to set up the red zone, nothing comes up. All I can set up are blue and green zones, or a green one, if I choose the red + green set-up. When I eventually log into GUI, I see ‘Connecting’ for the red zone. My Internet is intermittent then, and my partner is complaining that ‘There’s no Internet’, and I’d rather avoid that (i.e. the complaining)!
(I think it’d be very helpful to have some examples of set-ups as part of Wiki, say with common routers like Netgear, Fritzbox and/or Draytek.)
the next problem that I’ve encountered is the ‘green’ and ‘blue’ zones. I understand that both can be merged and used as one pool of addresses (192.168.1.x), but if I assign ‘ethernet’ to one, but not ‘WiFi’ to the other, does that mean that IPFire is going to firewall devices connected to either ‘ethernet’ or ‘WiFi’ only? I have a mix of devices with my CCTV being connected directly to Fritzbox, while Chromecast and others to either Fritzbox or Devolo Magic 1 WiFi adapter, the latter of which then connects to Devolo Magic 1 DLan to then connect to Fritzbox.
I can’t always access GUI, with a message ‘Connection refused’ appearing if I log into 192.168.1.1:444 (192.168.1.1 is Fritzbox’s address).
Once I got access to the Internet, I tried to set up a DNS server (Cloudflare), but I get a message about ‘reverse lookup failed’ and its status is either ‘broken’ or ‘error’. I’ve found this post (Yet another DNS reverse lookup failed), but my set up is much simpler than that discussed there.
Thank you for your time and help. Any insights/helpful comments will be gladly received.
Just wanted to report on the progress. I’ve successfully managed to boot from the SD card on RPi 1.5 and to do so, I’ve done the following (for future reference):
‘burn’ the flash image for ARM architecture from the IPFire website
done the following:
a) edited the config.txt file by adding hdmi_safe=0 to the end
b) edited the uENV.txt file and change SERIAL-CONSOLE=ON to OFF
c) deleted the boot.scr file
d) edited
However, I’m still stuck on defining the red zone, i.e. the type of connection with Fritzbox - does Fritzbox need to be in the bridge mode, which it doesn’t support anyway?
fritz!box in router mode: This is needed if you want still use the telephony on the fritzbox but it has double nat. (so you may get problems with opening ports or vpn’s)
fritz!box in fullbridge mode: In this mode IPFire build up the PPPoE connection and get the public ip.
Router mode:
your green network could not have IP Range 192.168.178.0-255 or 192.168.179.0-255 unless reconfigure the fritzbox.
red is configured to DHCP and should get the configuration from the fritzbox.
The RPI4 support two boot modes. The first use the boot.scr and always use the uSD card. If this mode fail it fallback and try to boot via grub. So you can speedup the bootprocess on USB by deleting the boot.scr (and this also works around other uSD loading bugs.)
The change from ${fdt_addr_r} to ${fdt_addr} also result such boot fail and the fallback to grub. So it does the same like eraseing boot.scr
On RPI4 you can erase boot.scr but we cannot ship the image without because all other supported boards need it.