Versatile Network Devices

Niche Solutions

We often describe the FireBrick as a 'Swiss army knife' for networking.

The very first FireBrick was designed to solve a problem that could not be solved by anything else on the market - that was back in the year 2000. Today, The FireBrick is still solving niche requirements that we and our customers have.

This page describes a few of the lesser-known features of the FireBrick that have been developed for our own use or after discussions with other FireBrick users.

High Availability L2TP

Packet duplication and de-duplication to achieve 'High availability tunnel' networking

FireBrick High Availability L2TP

There are various Tunnel protocols built in to FireBrick routers.

One such tunnelling protocol is L2TP, and a feature of L2TP Tunnels is called HAL, or High Availability L2TP.

This can be described as RAID 1 for packets.

If you have two (or more) Internet connections that are lossy the FireBrick can duplicate and send all packets across all connections simultaneously. The FireBrick at the far end will accept the first packet to arrive and discard the any other duplicate packets. This way, if packets are lost when sent over one connection but the duplicated packet arrives over the second - there is no overall packet loss.

Ideal when using wireless, mobile or satellite communications.

Propper HTTPS

Easy HTTPS certificate management with ACME & Let's Encrypt

Many routers and network devices support https for their web interfaces, but how often do you have to fumble your way past browser warnings due to self-signed certificates?

FireBrick has built in ACME support, and can self-manage its certificates from compatible certificate providers such as Let's Encrypt. All set up with a couple of settings in the configuration.

Packet obfuscation

Packet Scrambling/Obfuscation

Any packets between two FireBricks can have obfuscation applied to the payload - this is applied via firewall rules so can apply to any traffic, even L2TP tunnels between two FireBricks. This will make it hard for third-party DPI systems to detect what type of traffic is being passed.

Obfuscation means that the packet contents are obscured from casual inspection, but this is not encryption and should not be considered secur

The obfuscation attribute causes all traffic in the session to be simply scrambled using a hexadecimal key of up to 64 bits (up to 16 hex digits). To receive the traffic, the far end must also be configured with the same obfuscation value.

There is more information regarding this in the manual.


Toggle parts of the configuration based on profiles - eg pings, time, mqtt and a lot more

Almost every part of a FireBrick's configuration can be enabled or disabled by a profile. A profile is an on/off control that can have its logic set by all sorts of things.

A simple example is to change the gateway based on a failed ping response. Profiles can be a lot more advanced and involve a lot more other 'inputs'.


An MQTT Broker


Many IoT devices communicate via the MQTT protocol, and this is usaully done via a local broker - a server.

The FireBrick operates three separate brokers:

  • An internal insecure MQTT broker (typically for local IoT)
  • An internal secure MQTTS broker
  • A connection to an external broker (MQTT or MQTTS).

Messages received on these can be kept separate, or relayed to any of the other two. Internal operations of the FireBrick that generate messages can be configured to sent to one or more of these three brokers.

Many aspects of the FireBrick's configuration can also be triggered by MQTT messages.

DC Power

48v or 12v DC power for 'out and about' connectivity


The FB2900 has three power supply options:

  • Automotive 12-24V DC
  • 48V DV
  • The usual AC.

This makes it possible to combine the features of the Firebrick such as bonding and High Availability Tunnels, along with a number of separate mobile data rate routers to create a portable-and-resilient-internet solution in a bag (or flight case!)

Fast boot and upgrade times

Reboots and software upgrades take seconds


FireBricks boot up, reboot and software upgrade in a matter of seconds.

The example in the image is pinging a FireBrick whilst it reboots.

FireBricks which are configured with features such as BGP, VRRP, L2TP etc will take longer to shutdown and boot up, as these services are terminated cleanly before the actual reboot process happens. Once a FireBrick is ready to reboot, it comes back very quickly!

This also applies to software updates, there's no waiting for minutes for firmware to be unpacked and applied. It's simply uploaded, automatically verified, and then a reboot happens to boot and load the new version.

Sales & Dealer Enquiries

phone 01344 400 500
Mon - Fri, 9am-5pm,
calls are recorded
sms 01344 400 500

Support Contact

phone 01344 400 500
Mon-Fri 9am-5pm,
calls are recorded
sms 01344 400 500