At work, we’re a Sophos partner, primarily focusing on the network protection products, including their next-gen firewall range – Sophos XG/XGS Firewall. They tend to work well for most of our smaller clientele, who tend to have 1-5 sites and less than 20 users.

Sophos XG supports a Remote Ethernet Device – essentially a self-provisioning layer 2 bridge device that appears as an interface on your your main firewall. The RED devices themselves aren’t configurable directly, they must be adopted and provisioned through Sophos’ provisioning service, where they’ll download their configuration based on how you’ve set them up in the firewall.

The problem

We have a reasonably-sized customer who has has 30+ RED devices deployed, but we’re finding they’re not quite flexible enough, and having to resort to complex topologies for what would be a simple tweak in a standalone VPN router. The RED is – by design – simple, ironically the simplicity around the product cause everything else around it to be overly complex.

I’ve been tasked with coming up with an alternative stack that duplicates a set of features used by the customer of the RED, while also meeting the design goals of the customer:

1. Centrally monitored and managed – allow their network team to manage the devices from a central location.
2. Reset and start again – the solution should allow a reset of the device while deployed, while still maintaining remote management and automatic provisioning.
3. Connect back to corporate firewall – the deployed device should be able to route traffic back to head office, then out to the internet.
4. Multi-WAN options – the device should allow for different WAN types with failover, including using cellular.

Additional features the customer requires:

1. Guest network – The RED does not support multiple zones on a single device. A guest network would be isolated and queued appropriately.
2. QoS – The customer’s hosted PBX requires VoIP traffic to be prioritized over other traffic.
3. Failover – A RED won’t work without it’s connection to head office. With the customer’s applications moving to cloud, having head office unreachable should not mean internet access is also down.
4. Rack mountable – the RED devices are not rack-mountable and are desktop only.
5. Reduced device count and complexity – The existing solution requires multiple non-rack-mountable items, using complex configurations that cause their helpdesk headaches.
6. Support for VDSL – In Australia, much of the country has been upgraded to fibre, yet there’s still plenty of locations relegated to using old copper VDSL technology.

The solution

After a bit of research, I’ve come up with a stack that should fulfil all of the customer’s requirements:

1. Mikrotik L009 Router – This is a very capable router, with 9 ethernet interfaces: 1x SFP 2.5G, and 8x Gigabit ethernet (1x with PoE in, and 1x with PoE out). It supports TR-069 management, a myriad of site-to-site VPN technologies and supports setting the default configuration using NetInstall, while supporting multiple WAN links, QoS, and is rack-mountable. To top it all off, the device itself is a fiery red colour – aptly to replace the RED device, which sadly is not red, but white.
2. Mikrotik CHR – Cloud Hosted Router, allows the same Mikrotik RouterOS software that powers their hardware routers to run as a VM, on-prem or hosted. This will serve as the VPN concentrator and will use OSPF to announce to the firewall routes to the remote sites using the new stack.
3. GenieACS – The TR-069 server that will allow us to centrally manage and monitor the deployed routers, while providing a base configuration when the device is factory reset.

We deployed our first new stack to a remote site last week, check back soon for part two where we look at some of the configuration of the stack.

• Fun with the Dude
  2024-01-02 0
• Preserving IP space with scarce addresses
  2023-12-31 0