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.
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.
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.
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.
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'.
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:
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.
The FB2900 has three power supply options:
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!)
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.
