Azure private endpoint doesn't work with Azure firewall

Question

Azure private endpoint doesn't work with Azure firewall

Van Huy Tuyen 40

Dear team

I have network topology

Hub vnet: 10.150.0.0/20
- Azure firewall subnet with private IP: 10.150.0/4
- Azure firewall management subnet
- Gateway subnet
- Peering with DB vnet
- UDR with route table 1 (RT1): 10.160.18.0/23 via next hop 10.150.0/4, associate to Gateway subnet, Propagate gateway routes = YES
2.Spoke VNet (DB vnet): 10.160.18.0/23
- Azure SQL private endpoint subnet: 10.160.18.0/26
- Network Policy for Private Endpoints: Route table
- Peering with Hub vnet
- UDR with route table 2 (RT2): 0.0.0.0/0 via next hop 10.150.0/4, associate to Azure SQL private endpoint subnet, Propagate gateway routes = NO
  1. On-premises subnet: 10.147.0.0/16

On Firewall, I create allowed rule from On-premises to Azure SQL private endpoint subnet, allowed port = 3389/TCP

On Azure SQL private endpoint subnet, I create:

Azure VM
Private endpoint NIC for Azure SQL

The result.

I can connect to VM via 3389/TCP -> It's correct
I still can connect to Private endpoint NIC for Azure SQL via 1433 -> I think it's incorrect, because I don't allow it via Firewall.

-> So I think in this case, traffic from on-premises to Azure SQL private endpoint doesn't go through Azure firewall.

Please support me what I wrong.

Thanks!

Van Huy Tuyen 40 Reputation points

2025-10-06T14:31:14.89+00:00

Hi @Priya ranjan Jena ,

Thanks for your information. I think my UDR overrides the default route. But I don't know what I wrong.
Priya ranjan Jena 1,990 Reputation points Microsoft External Staff Moderator

2025-10-06T16:04:01.0066667+00:00

Hi Van Huy Tuyen,

Thanks for the reply,

Unless we know the exact miss, we have to go through hit & trailing the steps mentioned by us previously but as above comment if you are suspecting UDR overrides the default route, then we have some suggestion on the same , you can try & check.

To prevent a user-defined route (UDR) from overriding a default route in Azure, you should not create a UDR that targets the same destination prefix as the default route, as UDRs always take precedence. Instead, apply the UDR to specific subnets that should have different routing, and ensure the UDR's next hop is the intended appliance or destination, rather than attempting to force traffic through your appliances when it should be on the default path.

Target Specific Subnets:

Instead of creating a broad UDR that would apply to all subnets, associate your custom route table only with the subnets that require traffic inspection or a different next hop.

Use a More Specific UDR:

If you need to send traffic to a firewall, for instance, create a UDR with a more specific destination prefix . This allows you to send specific traffic through the firewall, while other traffic can still use the default route to reach the internet or other destinations.

Avoid Conflicting UDRs:

When adding routes to a route table, ensure that there are no conflicting UDRs with the same destination prefix. For example, if you already have a UDR sending 0.0.0.0/0 traffic to a firewall, do not add another 0.0.0.0/0 route that directs to the internet.

Disable Route Propagation:

If you are using VPN gateways or Route Server and want to prevent them from injecting default routes into spoke VNets, you can use a UDR on the spoke subnets to direct traffic to an NVA, or you can disable BGP route propagation from the gateway.

Thanks
Priya ranjan Jena 1,990 Reputation points Microsoft External Staff Moderator

2025-10-08T18:18:10.74+00:00

Hi Van,

Before moving ahead with logs from our end , could you please confirm about below.

whether you have tried to force private endpoint traffic from on-premises, if not, please visit the reference link :https://learn.microsoft.com/en-us/azure/private-link/inspect-traffic-with-azure-firewall#scenario-4-on-premises-traffic-to-private-endpoints

Whether you have configured a DNS Forwarder or Azure Private Resolver for the Private DNS integration with On-premises?, if not , please visit the reference link & try:

https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-dns-integration#on-premises-w…

https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-dns-integration#on-premises-w…

Kindly let us know if you have any questions.

Thanks
Van Huy Tuyen 40 Reputation points

2025-10-09T15:01:22.7666667+00:00

Hi @Priya ranjan Jena

I think that Private endpoints with HTTPS don't go through Azure firewall. I don't see the logs over firewall.

Beside that, private endpoints with non-HTTP traffic seem OK
Priya ranjan Jena 1,990 Reputation points Microsoft External Staff Moderator

2025-10-09T16:49:02.61+00:00

Hi Van,

As we discussed , we will be collecting logs from your additional subscriptions & update you on this with next call scheduled for Friday.

Thanks

1 answer

Your answer

Van Huy Tuyen 40 Reputation points

2025-10-06T14:31:14.89+00:00

Hi @Priya ranjan Jena ,

Thanks for your information. I think my UDR overrides the default route. But I don't know what I wrong.
Priya ranjan Jena 1,990 Reputation points Microsoft External Staff Moderator

2025-10-06T16:04:01.0066667+00:00

Hi Van Huy Tuyen,

Thanks for the reply,

Unless we know the exact miss, we have to go through hit & trailing the steps mentioned by us previously but as above comment if you are suspecting UDR overrides the default route, then we have some suggestion on the same , you can try & check.

To prevent a user-defined route (UDR) from overriding a default route in Azure, you should not create a UDR that targets the same destination prefix as the default route, as UDRs always take precedence. Instead, apply the UDR to specific subnets that should have different routing, and ensure the UDR's next hop is the intended appliance or destination, rather than attempting to force traffic through your appliances when it should be on the default path.

Target Specific Subnets:

Instead of creating a broad UDR that would apply to all subnets, associate your custom route table only with the subnets that require traffic inspection or a different next hop.

Use a More Specific UDR:

If you need to send traffic to a firewall, for instance, create a UDR with a more specific destination prefix . This allows you to send specific traffic through the firewall, while other traffic can still use the default route to reach the internet or other destinations.

Avoid Conflicting UDRs:

When adding routes to a route table, ensure that there are no conflicting UDRs with the same destination prefix. For example, if you already have a UDR sending 0.0.0.0/0 traffic to a firewall, do not add another 0.0.0.0/0 route that directs to the internet.

Disable Route Propagation:

If you are using VPN gateways or Route Server and want to prevent them from injecting default routes into spoke VNets, you can use a UDR on the spoke subnets to direct traffic to an NVA, or you can disable BGP route propagation from the gateway.

Thanks
Priya ranjan Jena 1,990 Reputation points Microsoft External Staff Moderator

2025-10-08T18:18:10.74+00:00

Hi Van,

Before moving ahead with logs from our end , could you please confirm about below.

whether you have tried to force private endpoint traffic from on-premises, if not, please visit the reference link :https://learn.microsoft.com/en-us/azure/private-link/inspect-traffic-with-azure-firewall#scenario-4-on-premises-traffic-to-private-endpoints

Whether you have configured a DNS Forwarder or Azure Private Resolver for the Private DNS integration with On-premises?, if not , please visit the reference link & try:

https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-dns-integration#on-premises-w…

https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-dns-integration#on-premises-w…

Kindly let us know if you have any questions.

Thanks
Van Huy Tuyen 40 Reputation points

2025-10-09T15:01:22.7666667+00:00

Hi @Priya ranjan Jena

I think that Private endpoints with HTTPS don't go through Azure firewall. I don't see the logs over firewall.

Beside that, private endpoints with non-HTTP traffic seem OK
Priya ranjan Jena 1,990 Reputation points Microsoft External Staff Moderator

2025-10-09T16:49:02.61+00:00

Hi Van,

As we discussed , we will be collecting logs from your additional subscriptions & update you on this with next call scheduled for Friday.

Thanks

Answer 1

Hi Van Huy Tuyen,

Thank you for reaching out to the Microsoft Q&A forum.

You are suspecting that the traffic to the Azure SQL Private Endpoint is not traversing the Azure Firewall.

This might happens because of

Private Endpoint behavior

A Private Endpoint creates a direct network interface in your VNet for the PaaS resource (Azure SQL in this case).
When you connect to the SQL Database using its private IP, the traffic stays within the VNet and uses Azure’s backbone. It does not route through the firewall unless explicitly forced.

Peering and system routes

VNet peering allows direct communication between VNets without passing through the firewall unless you configure forced tunneling or disable default system routes.

To block the Azure SQL private endpoint NIC on port 1433, which you expected to be , you can ensure some of the below steps:

Network Security Group (NSG) Rules: Make sure that there are no overlapping NSG rules that might be allowing traffic to reach the Azure SQL private endpoint. Sometimes NSG rules can override firewall rules.

Private Endpoint Configuration: Verify that the private endpoint for the Azure SQL Database is correctly configured and that the DNS settings for the private link are resolving to the private IP address.

Firewall Rules: Please check the rules in the Azure Firewall because its possible that there may be an explicit allow rule for traffic to your Azure SQL instance that is overriding the rules you set. Make sure that you have logging enabled on the Azure Firewall to see what traffic is being allowed or denied.

Routing: Since you're using User-Defined Routes (UDRs), ensure that the routes are correctly directing the traffic through the Azure Firewall.

Endpoint Type:Private endpoints always associates with a private IP address in your VNet. Make sure that any default connections to the public IP of your SQL Database are not inadvertently enabled, which could leads the connectivity on port 1433.

Testing Connectivity: Use tools like telnet or Test-NetConnection in PowerShell from your on-premises environment to see if you can explicitly reach the IP address of the private endpoint on port 1433 and check what the firewall logging says at that time.

Hope you find this comment helpful, if yes, please “up-vote” for the information provided , this can be beneficial to community members.

Kindly let us know if you have any additional questions.

Thanks

Share via

Azure private endpoint doesn't work with Azure firewall

1 answer

Your answer