IPFire Firewall Setup

Why IPFire?

IPFire is built on Linux, so it uses the Linux kernel's network drivers. That can matter if a network card isn't well supported by FreeBSD-based firewalls such as OPNsense and pfSense. Its baseline memory recommendation is also modest (see below), although features such as the IPS need more. The web interface is plainer than OPNsense's; if you want to compare the two, the OPNsense Firewall Setup guide covers the FreeBSD-based alternative.

What you get:

• Colour-coded zones (RED = internet, GREEN = LAN, BLUE = wireless, ORANGE = DMZ)
• A Suricata-based intrusion prevention system
• A Squid web proxy with a URL filter
• VPNs: IPsec, OpenVPN and, since Core Update 195, WireGuard
• Add-on packages through the Pakfire package manager

Versions: this guide follows IPFire 2.29. As of October 18, 2026 the IPFire download page lists Core Update 204, for x86_64 and aarch64. The IPFire blog publishes the release notes for each core update.

Hardware Requirements

From the IPFire system requirements:

• Processor: x86_64 or ARM64, ideally 1 GHz or faster. 32-bit systems are no longer supported.
• Memory: at least 1 GB. The web proxy and URL filter, the intrusion prevention system and the DNS firewall need considerably more; for a system using all features the docs suggest 8 GB.
• Storage: 2 GB minimum, with 4 GB or more recommended for logs and add-ons.
• Network: at least two network adapters, one for RED and one for GREEN.

A small or older machine can work if it meets these requirements. Check that its CPU is 64-bit and that it has two network ports, or a slot for a second card, before you repurpose it.

Installation

Download the ISO image from the download page (or the flash image for boards that can only boot from their own storage) and write it to a USB stick with Rufus or dd. The installation guide shows each screen.

1. Boot from the USB stick and press Enter to start the installer
2. Select the language and start the installation
3. Accept the license
4. Choose the target disk (everything on it is erased)
5. Choose a filesystem (ext4 is the recommended default)
6. Wait for the installation to finish, then reboot
7. The setup program asks for the keyboard layout, timezone, hostname and domain, and two passwords: root for the console and SSH, and admin for the web interface

Network Configuration

Setup then asks for a network configuration type and assigns physical NICs to zones. This is where IPFire's colour system starts:

• RED - the internet connection (WAN)
• GREEN - your local network (LAN)
• BLUE - optional, a separate network for wireless clients
• ORANGE - optional, a DMZ for anything you expose to the internet

A standard installation is GREEN + RED. BLUE and ORANGE each need another network adapter; for BLUE, the docs recommend connecting a separate access point. Setup finishes by asking for addresses for each zone and offering to enable the DHCP server on GREEN.

Web Interface

From a machine on GREEN, open https://YOUR_GREEN_IP:444 in a browser.

The web interface listens on port 444, not 443.

Log in as admin with the admin password you set during setup. The root password only works on the console and over SSH.

Check: the home page shows the RED interface with an address from your ISP or modem, and a computer on GREEN can open a website. If RED has no address, recheck the cable and the network configuration type you picked in setup.

SSH access

The SSH server isn't running after installation. Under System → SSH Access, the SSH documentation describes three ways to run it: permanently (which it doesn't recommend), or temporarily with the buttons that stop the daemon after 15 or 30 minutes. IPFire listens on port 222 unless you tick the option for port 22:

ssh -p 222 root@192.168.1.1

Use your GREEN address. The same page explains how to add a public key and then switch off password logins.

If you need to redo the network settings

Run setup on the console as root to return to the setup program, where you can reassign network cards to zones and change zone addresses. Do this from the console rather than over SSH or the web interface: changing the GREEN address or swapping cards cuts off the session you're using.

The Zone System

Firewall policy is defined between zones rather than written as iptables rules by hand. By default GREEN can reach the other zones, while connections from RED, ORANGE or BLUE into GREEN are blocked. The default policy page has the full table; the main points:

• GREEN to RED, ORANGE and BLUE: allowed (the LAN reaches the internet and the other zones)
• RED to any internal zone: blocked (use port forwarding or a VPN)
• ORANGE to GREEN: blocked (a compromised DMZ host can't reach the LAN; use a DMZ pinhole rule if a service needs it)
• BLUE: devices can't reach anything, the internet included, until you allow them on the Blue Access page; BLUE to GREEN also needs a pinhole rule or a VPN

That makes BLUE a reasonable place for devices you don't fully trust, such as smart-home gadgets. If a BLUE device needs a specific service on GREEN, you add an explicit rule for it.

Firewall Rules

Firewall → Firewall Rules in the web UI.

Each rule has four pieces:

• Source (zone, subnet, or specific IP)
• Destination (zone, subnet, or specific IP)
• Protocol and port
• Action (ACCEPT, DROP, or REJECT)

Port Forwarding

A port forward is a firewall rule with destination NAT, created under Firewall → Firewall Rules → New rule (see the port-forwarding guide):

1. Source: RED (or Any)
2. NAT: tick "Use Network Address Translation (NAT)" and choose "Destination NAT (Port forwarding)"
3. Destination: the internal server's IP address
4. Protocol: TCP or UDP with the server's port (never "All"); fill in "External port (NAT)" only if the outside port differs

Intrusion Prevention System

IPFire has used Suricata as its IPS since Core Update 131. It is configured on the Intrusion Prevention page in the Firewall menu (IPS documentation).

• Enable the IPS and select at least one zone to inspect; traffic in zones you don't select isn't scanned
• Add a ruleset provider, for example the Emerging Threats Community Rules, and choose per provider whether rules update automatically
• Consider "Monitor traffic only" mode at first: matches are logged but not blocked, so you can spot false positives before enforcing

Broad rulesets can flag normal traffic. The IPFire docs give one example: the Emerging Threats policy rules can block apt update. Review the IPS log, then disable noisy rules under "Customize ruleset" or whitelist specific hosts. Deep inspection needs CPU and memory, so check the hardware requirements above before enabling several providers.

Web Proxy

IPFire includes a Squid-based web proxy. If you already filter DNS on your network (the Pi-hole Deployment Guide covers one way), you may not need it.

Network → Web Proxy

• Enable the proxy
• Transparent mode forces all HTTP through it without client config
• The URL filter lets you block by category

It's mostly useful for parental controls or for devices that ignore DNS-level blocking. A transparent proxy only sees plain HTTP. Filtering HTTPS by URL would mean installing your own CA certificate on every client, which most home networks don't do.

VPN Access

IPFire supports IPsec, OpenVPN and WireGuard. WireGuard has been built in since Core Update 195 and is managed in the web interface.

WireGuard for laptops and phones

From the WireGuard documentation:

1. Set a Client Pool in CIDR notation, for example 10.20.0.0/24. It must differ from GREEN, BLUE and the OpenVPN and IPsec client ranges, and the docs warn it can't be changed later without recreating every peer.
2. Set a custom endpoint: by default it's IPFire's hostname, which is unlikely to be the public name of RED. Use a DNS name that resolves to your public address. The listen port defaults to 51820.
3. Click Add, choose Host-to-Net Virtual Private Network (RoadWarrior), name the connection, and choose which networks the peer may reach: 0.0.0.0/0 sends everything through the tunnel, or pick GREEN for access to the LAN only.
4. Save, then scan the QR code or download the configuration straight away. The docs point out that IPFire doesn't keep the peer's private key, so this is the only chance to get it.

Create one connection per device. IPFire opens the needed firewall ports itself, but if RED sits behind another router, that router has to forward UDP 51820 to IPFire.

OpenVPN

Under Services → OpenVPN, generate the CA and server certificate, create one client certificate per device, and download each client's .ovpn file. For background on either protocol, OpenVPN Cloud Deployment and WireGuard Cloud Deployment set each one up by hand on a server.

Updates via Pakfire

IPFire → Pakfire in the web UI.

Pakfire installs both core updates and add-on packages. The add-ons list includes, for example, Tor, Samba, HAProxy, Guardian and tcpdump. Suricata, OpenVPN and WireGuard are part of the core system, not add-ons.

Apply core updates promptly: a firewall running unpatched software is a liability. The upgrade process also uses memory while it downloads and unpacks, which the requirements page mentions.

Backup

System → Backup.

A backup holds the system configuration, including firewall rules, port forwards, DHCP and IPsec, OpenVPN and WireGuard settings. Add-on settings are backed up separately, and the add-ons themselves have to be reinstalled after a restore (backup documentation). Download a backup before every core update and keep the copy somewhere other than the firewall.

Troubleshooting

No access to the web interface

• Use https:// and port 444; plain http:// or port 443 won't reach it.
• Connect from GREEN. The web interface isn't meant to be reached from RED, and BLUE devices only get access once they're allowed on the Blue Access page.
• If you changed GREEN's address or swapped network cards, log in on the console and run setup to check which card is assigned to which zone.

WireGuard: "received bytes" stays at zero

The tunnel's packets aren't arriving. The WireGuard docs suggest the default port may be blocked by a network in between and recommend trying port 4443. Also check the peer's endpoint name: it must resolve to your current public address. WireGuard doesn't log connection attempts on IPFire, so the transfer counters are the main signal.

Updates or ordinary traffic blocked after enabling the IPS

Switch the IPS to "Monitor traffic only", find the matching rule in the IPS log, and disable it under "Customize ruleset" before enforcing again. The docs' example is the Emerging Threats policy rules blocking package updates.

Port forward doesn't work

Test from outside your network, for example from a phone on mobile data; testing from GREEN against your own public address often fails for unrelated reasons. Confirm the internal server answers locally first, and that the rule's protocol and port match the service.

Tidy Up Before Going Live

• Remove test rules and any WireGuard or OpenVPN connections you created while experimenting.
• Turn off permanent SSH access if you enabled it, and use the 15- or 30-minute mode instead.
• Download a fresh backup and store it off the firewall.

Use IPFire when:

• You have modest 64-bit hardware that meets the requirements above and want a firewall with zones, an IPS and VPNs
• Your network cards have good Linux drivers but aren't well supported by FreeBSD-based firewalls

Consider something else when:

• You prefer OPNsense's interface and plugin system (see the OPNsense Firewall Setup guide)
• You want the IPS, the web proxy and the DNS firewall together on a machine with little memory; the docs say these features push memory use well past the 1 GB baseline
• You'd rather build a router from a general-purpose distribution and manage the rules yourself (see Linux Router Setup)