Welcome to the IPFire Wiki

This wiki is a community-maintained resource about everything there is to know about IPFire. Join us and help us improving it!

Looking for something?

Use the search and find answers to everything about IPFire. If you cannot find what you are looking for, join our community and talk to fellow IPFire users, developers and everybody else involved in the project.

IPFire Community


Most of the installations of IPFire are done by installing it directly on a piece of hardware. However, Virtualization is an alternative where IPFire is installed as a running image, sharing hardware with other running instances. IPFire has been used successfully on the following virtual platforms.

More about Virtualization

Virtualization allows several virtual servers to run on the same piece of hardware. This is done through a special piece of software known as a hypervisor. When the physical machine is running, the main process is the hypervisor, which simply controls which virtual machines are temporarily in control.

Many servers spend significant time just sitting around, waiting for something to do. And, in many cases, they draw almost as much electricity during that time as they do when very busy. Using virtualization allows you to optimize your cost in equipment and maintenance by ensuring your server(s) are operating up to their full potential and capacity.

Advantages to virtualization include:

  • Decreased number of physical machines running in a data center, your office or home
  • Creating a snapshot image of a running virtual, making recovering from mistakes easier
  • Allows moving virtual servers from one physical machine to another, in some cases without having to shut down the machine.

Disadvantages of utilizing virtualization are:

  • Can cause a slowdown in response times of the server if multiple resource-intensive virtual images are being run at the same time.
  • Server designs and maintenance become more complex, requiring the individual servers and the hypervisor to be kept running simultaneously.
  • A failure on a physical machine will cause all virtuals on that machines to fail at the same time until the problem is solved or the virtuals are moved to a different physical machine.

Uses for Virtualized IPFire firewalls

"all in one" servers with public facing IP's

In some cases, you will require a single server with multiple virtuals, all of which may have public IP addresses. You could place a firewall in front of this machine, or simply use create an "all in one" server which contains the content and the firewall.

One possibility is a single physical machine providing web services and also backing up sensitive data from the corporate office. Clearly, you do not want the sensitive data to be on a public facing web/mail server, yet it only makes sense to build one physical machine (and pay one colocation fee). In this case, you could build a virtual web server and a virtual backup server, then add a virtual IPFire firewall on the front end. Access to the web server would be public, but connections to the backup server would be limited to the public IP address of the corporate firewall. This could be set up as a red/orange network in IPFire.

Multi-use firewall

IPFire uses very few resources. It is very possible to build a virtual IPFire instance and, on the same physical server, have a monitoring program (Cacti, Zabbix, Nagios) on the same machine. This consolidates your management functions into one physical machine.


A firewall is very important to your network. If the firewall is unavailable, your entire network may be down. With a virtual firewall, you can snapshot the instance before doing anything configuration changes. If your work gives you an unmanageable result, you can recover from the problems simply by reverting to the snapshot you created.

An even more robust solution would be if you have a shared storage system, such as iSCSI or NFS, which your IPFire block device ("disk drive") is stored on. Most virtualization systems have the ability to rapidly move a running virtual to another physical machine sharing the same block device. Called "migration" in Xen, on a slow network, it can be accomplished with a total downtime of less than 5 seconds. Thus, if you need to perform physical maintenance on a machine, migrate the firewall instance to another machine, perform the necessary work, then migrate it back to the original.

Finally (untested), you can set up DRBD+Heartbeat to create a High Availability firewall, for those places where you absolutely can not have downtime.

Edit Page ‐ Yes, you can edit!

Older Revisions • November 21 at 1:04 am • Stu