I'm having issues with some Azure Virtual Machines that are situated behind a virtual firewall appliance which manages our routing. We need to integrate with a third-party vendor that requires our public IP to whitelist inbound connections from this Azure VM. I verified the public IP using ifconfig.net on the VM and it corresponds to the static WAN IP on our firewall appliance, so I advised the vendor to add it to their allow list. However, we're still encountering connection denial as if our IP isn't whitelisted. The vendor provided a screenshot showing that they added the rule correctly. Interestingly, when they included the WAN IP from one of our branch office's physical firewalls and tested the connection, it worked without issue. The logs from the virtual firewall don't indicate any blocked attempts directed toward the vendor's domain or IP, which makes me suspect there could be some sort of proxying or NAT issue that is masking the outbound connections from our Azure VM. Yet, I don't see why tools like ifconfig.net wouldn't reflect that. We dealt with a similar issue previously but found a workaround, so I didn't think it would be a problem this time. I'm also unable to spot any proxy or NAT settings in the Azure Vnet that would contribute to this issue.
1 Answer
I’m experiencing a similar issue where none of our traffic between Azure environments appears in the virtual firewall (Palo). We've had failures when trying to limit a vendor's access to our public IP, despite checking multiple IP verification sites and finding them correct. It’s definitely frustrating!
When this happened to us, we were dealing with Azure to Azure traffic, so I thought there was some kind of Azure-specific routing magic taking place. However, we found that the Azure service allowed us to whitelist our Azure Vnet instead of using a public IP, and that resolved the problem for us. Maybe that's an option for you?