Ctrl.blog

Installation

You’re required to know the basics of local network administration and services to use IPFire. Beyond that, you’ll also need to be familiar with IPFire’s unusual names for the standard network zones: red, green, blue, and orange for WAN, LAN, WLAN, and DMZ respectively.

These colored network zone names can be a bit confusing and they’ve standard rules applied to them, and can’t be used interchangeably. During setup, you’re presented with the following screen with no context or explanation:

Here you’re asked to choose how many zones you want to use, and later which network interface to assign to each zone and how they should be configured. Without knowing which zones are what color, you may be more than a little lost and can end up with a non-functioning setup.

The remainder of the initial installation and setup process doesn’t hold any other great mysteries if you’ve ever configured a network before. Once you’ve completed the initial setup, you should have a basic working network and a working web administration interface.

The colored zone names also leads to some confusing user interfaces in the web administration interface. The below is a screenshot from the main status page. Despite “Internet” being showed with a red background, a color that’s normally used to signal that there’s something wrong, the red network/the internet interface is working just fine.

To make matters worse, the web interface sometimes transmits the page up to and including the red “Internet” label, while the rest of the page takes a few seconds longer to load in the web browser. The page is partially transmitted by the web server on the router, which reinforces the oddity of choosing a red/error background color in this part of the user interface.

I found it quite interesting to note that you can’t reassign or make changes to the configured network interfaces or zones from the web interface. You can reconfigure it from a terminal using the setup command, but it’s a task the web interface rally should have been able to handle.

Wireless

You can install the hostapd package through the web interface, which adds a new menu entry called WLanAP for configuring a wireless access point on your IPFire box. WLanAP has support for configuring either a 2,4 GHz or a 5 GHz network – but not at the same time. You must choose between the older frequency range for device compatibility, or the newer range with higher speeds.

No device is allowed to connect on WLAN, as IPFire defaults to using MAC allow-listing under a page called “Blue Access”. You can disable this by adding an allow-listing entry with an empty MAC address. There’s no hint that this should work, quite the opposite in fact, but that’s how you disable it.

Alternatively, you can connect a dedicated wireless access point to your WLAN zone/interface. A separate guest network access point can be connected to the DMZ zone/interface.

Both of these approaches may cause you problems down the line, which I’ll get back to in more details in the ‘Getting local devices talking to each other’ section.

If you just want wireless networking to work for home use-cases, then configure a wireless access point in passive access point mode (no DHCP broadcast) and connect it you your LAN zone.

Getting local devices talking to each other

What is a router but a bridge between your home network and the public network? Well, it can be an appliance that can wall off some portions of your network from each other. In the default configuration, devices on the LAN and WLAN can’t talk to each other. Devices in the DMZ can’t talk to any zone other than the internet.

This default zone configuration is just fine if you don’t need to transfer data from mobile devices or laptops to any device on the wired LAN. If you want to stream videos from your laptop to your Ethernet bound Chromecast or have device and service auto-discovery working, you’re in trouble. IPFire don’t want you to pass multicast broadcast packages between the two networks.

First of all, you can’t have multicast packets traveling between the LAN and WLAN using any method available in the web interface. You can pass TCP/UDP traffic back and forth between the LAN and WLAN zones just fine.

However, both networks need to be within reach of each other’s netmasks which is automatically computed from their assigned subnet ranges for use in DHCP broadcasts. You can configure your network in a way where they’ll be assigned different subnet ranges and a netmask that will allow multicast broadcast packages to travel between the two networks.

Such a setup can’t, unfortunately, be configured in the firewall to allow traffic to pass between them as to the firewall they’ll appear with the same network profile (netmask + subnet.) You’ll then also run in to trouble with WLAN clients as they can’t communicate with the default route, which is located on the LAN network.

The above problem is a side effect of how the zones are structured in IPFire. You’re clearly not meant to pass traffic between the two networks.

Your next best option is to combine the green and blue – I mean LAN and WLAN — networks into one network. You can accomplish this by moving the network connection for your external wireless access point from the assigned blue network interface to the green – or to behind a switch on the green network. However, if you’ve configured your IPFire box to be your access point you’ll need to be a bit more creative.

The IPFire forum and wiki contains a script that you can use to combine the two networks. The blue network will be just another part of the green network. However, the web interface won’t reflect this change, and changes you make in the web interface can end up breaking your WLAN zone without warning. It’s not a supported configuration mode and again is something that takes you out of the web administration interface to configure.

To get TCP, UDP, and multicast working you better just add a wireless access point to your LAN zone.

Getting external things talking to your services

Port forwarding and other traditional network configuration is a breeze. You may run in to some weird word choices in the configuration interface, but if you’ve ever configured this in a consumer grade router you’re good to go.

Automatically configuring port allocations for your games, apps, and services — best known as UPnP — isn’t supported by IPFire out of the box. You can add support by installing the miniupnpd package. The default configuration of this service isn’t securely configured by default, doesn’t automatically adjust based on your network profile, and hasn’t ever worked since it was introduced in 2010.

You can fixup the configuration file in the terminal, as there’s no web administration interface for it, and get working UPnP quite easily if you’re familiar with MiniUPnPd configuration. (Who is?) I’ve submitted a patch to IPFire to at least make the service work by default after its installed. However, UPnP should just be an option you turn on for a network zone in the web administration – it shouldn’t need any more configuration than that.

Odds and ends

By now it’s starting to become clear to me that IPFire isn’t meant for home users. At least not today’s modern homes with lots of devices needing to talking to each other unhindered. Here is a collection of odds and ends before I draw a more complete conclusion towards the end:

Good ones:

• Quality-of-Service (QoS) works out of the box. Just specify your exact bandwidth constraints, and it does a good job. This is quite unusual as routers usually need a month’s worth of configuration and repeated beatings to behave.
• Graphs and statistics are great. I’d wish there was per-host statistics for bandwidth usage, but overall you’ve all the information you could need neatly presented in the web interface.
• Easy to configure transparent HTTP web caching.

Bad ones:

• The web interface can be quite confusing. Uou may submit a form to add an entry to some kind of list, and upon submission the form changes slightly to allow you to update the entry you just added. There’s no confirmation that it was added and the values you typed in are still where you added them. There are in many places no confirmation that anything was added, and I’ve even sat there for a while waiting for it to submit and clear the form – only to realize it has been done for some time already. To add another entry, you then have to reload the page to reset the form.
• The web administration interface isn’t mobile-friendly. It’s not just not optimized for mobile, but I’d say it’s actively mobile unfriendly. IPFire’s table based layout (sic) is hard to keep in view at a reasonable size on mobile, and the hover-driven menus are all but impossible to traverse with a touch screen.
• Unfortunately, you’ll have to resort to reading the web interface’s source code to do any troubleshooting. Many error messages are vague to the point of being meaningless. They often don’t explain the problem, and the same error message is reused for different situations.
• IPFire sees regular security updates, releases, and development activity on its 2.x release branch. In 2009, a IPFire 3.0 alpha version was released. This version promises to be a complete rewrite of IPFire. However, it’s been 8 years since that initial release. I believe we can conclude that it’s in fact vaporware.

Conclusion

IPFire can be a good starting point for a router for a home or small office network. It does require prior knowledge of networking services, but I assume you already have some if you’ve read this far.

If you want a Linux based and open-source firewall with a built-in web administration interface, then IPFire is a strong contender in a weak market.

I think I can conclude that IPFire is not suitable for a home network. It requires too much fiddling to get it up and running in terms of network basics like having multicast work between LAN and WLAN, and configuring UPnP.

IPFire can be made to fill the role, but it’s not purpose built for it. You’re required to know a lot about the software that runs the services you want to use. In the end, you could have just as well configured any general-purpose Linux distribution to provide this services without IPFire getting in the way.

IPFire should be treated as a generic Linux server in terms of security. The development team behind IPFire have a good track record with security updates to the services they bundle. However, your network security needs may be better served by being backed by a larger distribution with a dedicated security team such as Fedora Linux, Debian, or Ubuntu.

You’d want your home network to just work, and that isn’t what you get out of the box with IPFire. It may not even be what you’ve after a few hours of configuration.