In a recent Azure Hub and Spoke network deployment, we aimed to use WatchGuard Firebox Cloud for controlling and filtering traffic between the network spokes. However, we noticed an unusual behavior: despite our configurations, all inter-spoke traffic was bypassing the set policies, flowing unfiltered through the firewall.

The heart of the problem was the deployment structure of the Firebox Cloud instance. It was set up with a single WAN nic and an internal nic, leading to a scenario where all traffic used the same interface, effectively skipping the usual security inspections.

It turned out that because of the way the Firebox Cloud instance is deployed, using a single WAN nic and an internal nic, all traffic is going through the same interface and the Firebox will not inspect the traffic. However, intra-interface inspection can be turned on using the CLI.

The key to resolving this issue was to enable intra-interface traffic inspection. This setting was not active by default in our configuration. By accessing the Command Line Interface (CLI) of WatchGuard, we activated intra-interface inspection, allowing the Firebox Cloud to inspect and apply policies to the traffic passing through the same interface.

This adjustment made a significant difference. With intra-interface inspection enabled, the Firebox Cloud began to properly inspect and filter traffic between the spokes, aligning with our initial security objectives for the network.

This experience highlights a crucial aspect of cloud networking: understanding the intricacies of how security appliances function within a cloud infrastructure is vital. In this case, a simple yet crucial setting change in the WatchGuard Firebox Cloud enabled us to achieve the desired security posture in our Azure Hub and Spoke network.

For more information, see this article from WatchGuard: Intra-Interface Traffic Inspection

Do you need help with deploying or setting up a hub and spoke network infrastructure within Azure, contact us for a free inquiry.