This week we have been deploying a new environment in Azure for a client. With a secured vWAN Hub with Azure Firewall. The vWAN Hub is connected to a Cisco SD-WAN appliance that connects all of the clients physical location. We configured 2 new Domain Controllers, opened up the traffic between the Azure DC and on-premises DC. We could reach the Azure DC’s but not the other way arround.
When doing a traceroute we could see it reach the IP of the SD-WAN appliance. But we could not see any connections in the Cisco Fireall in the datacenter.
What we did not think about at once was that the IP address range in the datacenter was a public IP range. After a while of digging we went trough the logs on the SD-WAN and could not see the packages there. We could see the FW rules allowing the traffic. So we started to dig trough the Azure Firewall Settings and the Policy settings.
There is a setting called Private IP ranges (SNAT) where the default behavior of the Azure Firewall is to source nat any traffic going to a public IP with the public IP of the firewall. Well that’s not good.
The setting was set to Perform SNAT For all IP addresses except IANA RFC 1918 ranges(default). IANA ranges are the 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 100.64.0.0/10 ranges. And the public IP was not apart of that.
So the solution was to set on the root Azure Firewall Policy, For all IP addresses except those specified below and specify the IANA ranges and the public IP range that was in the clients datacenter. The range is not used as a public range and is not routed out on the internet at all.
That solved it instant