relation between Cloudguard for Azure and the MS IP 168.63.129.16

[flachance]

Hi

Would anyone know what is the relation with Cloudguard for Azure and the MS IP 168.63.129.16?

What is IP address 168.63.129.16? | Microsoft Docs

When deploying Cloudguard in Azure from the Marketplace, routes for this IP are automatically created on the gateways so I assume Checkpoint knows about it.

Now here is the behavior that I don’t understand. If I have VM (10.11.11.11) deployed behind the Cloudguard gateway in Azure. I can, from that VM, make DNS queries using 168.63.129.16 as the DNS server but there are no rules to allow that. And I don’t see any traffic from 10.11.11.11 (blocked or allowed) to 168.63.129.16.

From the VM if I use 168.63.129.16 as the DNS server and I do a query on tsn.ca and on the gateway I run  tcpdump -nni any port 53 | grep tsn, the query will work but I don’t see anything with tcpdump.

If I do the same thing but using some other DNS server, I can see the query with tcpdump.

How does the traffic gets to 168.63.129.16 if we can’t even see it. If it’s an Azure behind the scene thing what other traffic are we not seeing?

thanks

Francis

[PhoneBoy]

Generally, traffic sourced from the gateway is permitted by default using Implied Rules.
You can enable logging of Implied Rules if you want to see what is being allowed.
Not familiar with the precise communication mechanism used to get this traffic to Azure.

Note that AWS uses a similar address (169.254.169.254) for similar reasons.

[flachance]

The logging of Implied rules is already enabled in Global Properties unless there is another location where it needs to be enabled. I had a look at the implied rules and I can't really see one of them that would allow that. I've also been through my ruleset several times to make sure logging was on for every rule. Still I don't see the traffic from any vm behind the gateway to that IP. I was really curious to know if someone with a Cloudguard gateway in Azure could observe that same behavior.

[PhoneBoy]

So the traffic is coming from a different VM (not the Security Gateway) to this address?
I have to assume it is getting routed with a mechanism similar to UDR by Azure, thus the gateway wouldn't see it (and thus Implied Rules wouldn't apply).

[flachance]

yes from a vm behind the gateway to this adress. I tried with a few VM and it's always the same.

Wether it's traffic like DNS (udp/53) that is reaching that IP or traffic like ping that doesn't. I see absolutely nothing with tcpdump. I made sure to do fwaccel off just in case.

It does seem to be routed by some other mechanism but what? I kind of stumbled upon that by accident but now I'm wondering what other traffic there could be that we don't see or know about.

Or maybe we have something misconfigured. It would have been interesting to see if someone else could observe the same behavior.

[Noy_Azulay]

That IP is Azure public IP. This IP is mandatory when you working in Azure (AWS holds also its public IP).

The public IP address 168.63.129.16 is used in all Azure public regions and all national clouds. This special public IP address is owned by Microsoft and will not change. It is allowed by the default network security group rule. We recommend that you allow this IP address in any local firewall policies in both inbound and outbound directions. The communication between this special IP address and the resources is safe because only the internal Azure platform can source a message from this IP address. If this address is blocked, unexpected behavior can occur in a variety of scenarios.

Azure Load Balancer probes originates from this IP address. If customer's block this IP address, their probes will fail leading to the above situation. The customer is convinced with the above explanation. After allowing this IP in their local firewall policies, they are able to reach the backend instances via Azure NLB and the problem is solved

#References

https://docs.microsoft.com/en-us/azure/virtual-network/what-is-ip-address-168-63-129-16?WT.mc_id=doc...

and in your specific case if you will run 'route -n' on your host that locates behind the GW I'm guessing you will found this IP either.
that means that when you pinging to Azure public address (168.63.129.16) you get replays from your direct connects routes.

[flachance]

Thanks for this, So the recommendation would be to have these rules on the gateway?

any->168.63.129.16 all Allow

168.63.129.16->any Allow

[Richard_Amos]

The mechanism is a local host route on your VM.  Its next hop will be the first IP address in your VNet.  This address is always reserved for an Azure "Default Gateway".  It is an Azure router that will know how to get to 168.63.129.16.  Therefore, your Security Gateway will not see this traffic.

[Noy_Azulay]

exactly! 🙂