07-11-2021 12:31 PM
I've become stuck on an issue getting inbound traffic working to a resource in a subscriber VNET behind a transit VNET where firewalls are configured.
I think I'm missing something obvious, and thought I would bounce ideas off of the community here.
Here's a summary of the configurations relevant.
Public Load Balancer listens on public IP 220.127.116.11.
Health probes use tcp 22 to the firewall's untrusted private IP 10.10.101.4/10.10.101.5.
The untrusted private IPs also have a separate public IP bound to them in the firewall VM configuration (for outbound traffic).
Health probes are happy, and see both firewalls as up.
Web request comes in to the public load balancer on example.fqdn.com:443 which resolves via public DNS to 18.104.22.168.
Several NAT configurations have been attempted, all failing.
Firewall does source and destination NAT, using the public IP 22.214.171.124, the fqdn example.fqdn.com, and the firewall's untrusted IP address 10.10.101.4/5 as the original destination (each in separate configuration attempts), public as the source zone, service as service-https. Source NAT to the firewall's private ip 10.10.0.4/5, destination to the actual resource in the subscriber VNET (no internal load balancer for the resource) 10.50.0.20. No port translation was used in these attempts.
Firewall does destination NAT only, using the same three destinations listed above (public IP, fqdn, firewall's public-private IP) directly to the internal resource.
I see hits coming in in packet captures from my test source, but never a translation or any return traffic.
On the way back out - and here's where I may be missing something - the resource has a route in a UDR to point to the internal load balancer that has the firewall's private IPs as a backend. Frontend IP for examples sake is 10.10.0.21.
I'm not sure if I should be using the 'floating ip' option or leave that disabled, and I'm wondering if the Azure public IPs should be associated with the untrusted interfaces of the firewalls in the VM configuration, or if they should not have public IPs attached.
I'd be fine with using the public load balancer for all inbound/outbound traffic if that would correct the problem, or if I need to make any additional configuration changes anywhere to get the floating IP option working.
It looked easier to do NAT with a floating IP, as you could skip source NAT, but I'm not sure where to assign the public IP in the firewall's configuration.
Do I assign the public IPs directly to the firewall's untrusted interface? A loopback? What should NAT look like with the floating IP option?
Thanks in advance for any input.
07-12-2021 08:23 AM
So the Azure public load balancer needs to point to the backend using NIC configuration and probes on whatever service the interface management profile will allow that is convenient for you. Example uses TCP 22.
I'm not sure if it's needed, but I have loopback addresses configured with the public IP of the load balancer frontend.
The NAT rule needs to be source zone public, destination zone public, destination service <frontend listening port>, destination address public IP of the frontend, source translation dynamic-ip-and-port interface private, destination translation <private ip of secured resource>.
The security policy is source zone public destination zone private destination address <ip of the public load balancer frontend>, application/service depending on what you're allowing inbound.
Then you also need to allow the private interface to talk to the secured resource in the subscriber VNET, and make sure all the routes are good.
You don't need to configure any outbound rules on the load balancer, you can keep the public IP addresses that are associated with the public interfaces of the firewalls associated for outbound traffic and return traffic will work because of the source NAT.
I was not able to get things working with FQDNs. It may be because the FQDN associated with the public load balancer IP is not the same as the URL that's being used to resolve it.
There's a question - do you have to associate the FQDN that you'd use in NAT policy with the load balancer frontend public IP azure object?
Would it work with external (not in Azure) DNS resolving names to the IP?
11-02-2021 04:39 PM
Do you have to change the static routes in the trust and untrust VR to point to the LB?
Can you please share a screenshot of your PA NAT and security rules?
The ELB only has a public IP which points and checks the untrust interface of the PA.
I don't believe the ELB requires an internal IP which the PA NATs to.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!