Virtualizing Your Border Firewall

I will not run a consumer grade router as my border firewall. There are a number of reasons, but the largest is that manufacturers often quickly stop supporting the devices.  This translates to a lack of updates and patches leaving many systems vulnerable.  The recent NetUSB flaw is a prime example.  How many devices are vulnerable that will never receive a patch?

The better alternative is to run a dedicated, purpose built firewall system.  There are a number of very good firewall distros (Endian, IPFire, pfSense, Untangle, etc).  They provide more capabilities than any consumer grade router and receive regular updates.  Another alternative is to build a firewall from from a general release *NIX OS.  The latter option provides greater control over the system.  The drawback to this alternative is that it requires a dedicated computer or must be run as a virtual machine on existing hardware.

How can I run a firewall as a virtual machine with a cable modem?

TL;DR – Prevent the hypervisor from sending ARP packets to the cable modem.

There is a quirk with the way that DHCP leases are handed out with a cable modem.  It is a common enough issue that the question has been asked in several forums.  The responses tend to be along the lines of “use an old computer and don’t run your firewall as a vm”.  I think that there are a number of valid reasons to run the firewall as a vm and not on separate, dedicated hardware.  Some advantages for running as vm are:

  • Easy backup and restore of the firewall image.
  • Easy major upgrade.  The new/replacement system can be built as a new vm in parallel with the existing firewall allowing for easy cutover.
  • The ability to easily try multiple distros and setups without having to “rebuild the world” every time.

When running a firewall as a vm with a cable modem.  The external interface of the firewall will not receive an IP address from the service provider.  The fundamental cause is that a cable modem will only allow and IP address to be handed out to the first physical system seen by the device.  This is why virtualized firewalls do not get an external IP address.

The hypervisor must not be allowed to send ARP packets to the cable modem so that the cable modem does not “see” the hypervisor, but only the virtualized firewall.  This can be achieved via the system firewall on the hypervisor.

In this example, the hypvervisor is KVM and the system firewall in nftables.  The hypervisor has 2 phsyical NICS – eno1 and eno2.  Each has a bridge associated with it – br1 and br2.  Br1/eno1 is the internal network.  All VMs use br1 as their NIC.  The bridge allows the VMs to reside on the same network as the hypervisor itself.  This would be the same network that the wireless access point is on as well as other devices such has phones, laptops, etc.  The firewall’s internal NIC is the hypervisor’s br1.  Br2 is the external interface for the firewall.  The firewall is the only VM which has br2.  The image below shows the VM info of the firewall.

Next, on the hypervisor, create an ARP filter for the NIC and bridge that is the device connected to the cable modem.

table arp filter {
        chain INPUT {
                type filter hook input priority filter; policy accept;
        }

        chain OUTPUT {
                type filter hook output priority filter; policy accept;
                oifname "br2" drop
                oifname "eno2" drop
        }
}

After getting the ARP packets dropped, reboot the cable modem.  Your firewall should then be able to get an IP address via DHCP.

Scroll to Top