I've done a fair bit of searching and reading on this forum and cannot find answers to the behavior I'm seeing. Here's the overview followed by my questions.
I have an XG Firewall deployed in Azure. Setup is pretty much spot on the documentation for this and nothing particularly fancy. XG is the gateway for all internet traffic.
Azure VNET is simple - one 'external' on PortB (10.5.0.0/24)
Another 'internal' on PortA (10.5.1.0/24) - No resources reside in this 'DMZ' network - again per the documentation.
Two more subnets are present for resources:
'APP' - 10.5.2.0/24 - Currently a file server and an active Directory server are in this subnet
'WEB' - 10.5.255.0/24 - a front end web server is present here and needs to securely communicate with the AD server and the App server
A static route is set on the XG as per the documentation to supposedly route the subnet traffic through the LAN port. Routing tables have been properly added in Azure, again as per the sophos documentation. All servers can currently communicate with the internet and each other.
Here's the issue - I need to filter and lock down the specific traffic between the 10.5.2 and the 10.5.255 subnet and also log the traffic. I set up a firewall rule for the traffic between these subnets. To test I create a FW rule at the top to drop all traffic between those subnets. They should now no longer be able to communicate at all with each other. But that isn't the case - I can ping all day across the subnets. I see no traffic at all hitting the FW rule. Secondly, I delete the static routes in XG - no effect. Traffic still flows. So this tells me that Azure is routing the packets and NOT the XG. I genuinely don't understand what I'm missing here. This is set up according to the documentation and when I modify the Route Table in Azure everything breaks and still no traffic goes across the XG.
Has anyone successfully configured something similar or come up with a solution? Any assistance would be greatly appreciated.
This thread was automatically locked due to age.
