Azure Firewall Custom UDR

Question

Hello,

During the implementation of a routing change in the Azure Landing Zone hub-and-spoke environment, a custom User Defined Route (UDR) table was associated with the AzureFirewallSubnet to route the prefix 10.111.0.0/16 through a specific virtual appliance.

Shortly after the change, connectivity to on-premises networks learned through ExpressRoute, including 10.151.0.0/16, was lost, and additional connectivity issues were reported by workloads hosted in the hub, such as the SFTP server and PRTG monitoring system.

The route table had BGP route propagation disabled, preventing the Azure Firewall subnet from receiving propagated routes from the ExpressRoute Gateway. Once the route table association was removed from the AzureFirewallSubnet, connectivity was immediately restored.

This behavior indicates that the custom UDR modified the effective routing table used by Azure Firewall, impacting its ability to correctly route traffic to networks learned through gateway route propagation.

Do you recommend to enable route propagation on custom udr associated with azure firewall subnet ?
Should i notice an disconnections related to traffic going to internet ?

Regards

Answer 1

Yes. In most Azure Firewall hub-and-spoke deployments that use ExpressRoute or VPN gateways, BGP route propagation should remain enabled on any route table associated with the AzureFirewallSubnet, unless you have a very specific design that intentionally replaces propagated routes.

In your case, the behavior is expected:

• When you associated a UDR with BGP route propagation disabled, the Azure Firewall subnet stopped learning routes advertised by the ExpressRoute gateway.
• As a result, the firewall no longer had routes for your on-premises prefixes (for example, 10.151.0.0/16), so traffic destined for those networks could not be forwarded correctly.
• Removing the route table restored gateway-propagated routes, which is why connectivity returned immediately.

If you need to use a custom UDR on the AzureFirewallSubnet:

• Enable BGP route propagation so the firewall continues to receive routes from the ExpressRoute or VPN gateway.
• Add only the specific UDRs that are required for your design (for example, steering selected prefixes to a virtual appliance).
• Verify the effective routes on the AzureFirewallSubnet after making changes to ensure both propagated and user-defined routes are present and that route precedence produces the expected result.

Will enabling route propagation affect Internet traffic?

Generally, no.

Enabling route propagation simply allows the subnet to learn routes from the virtual network gateway. It does not automatically change Internet-bound traffic. Internet traffic will continue to follow the most specific matching route:

• A more specific UDR takes precedence over propagated routes.
• If no more specific route exists, the default Internet system route (or a configured default route such as 0.0.0.0/0) continues to be used.

You should only expect Internet connectivity changes if:

• a propagated route overlaps or is more specific than the intended Internet path,
• a default route (0.0.0.0/0) is advertised over ExpressRoute (forced tunneling),
• or your custom UDRs override the expected routing behavior.

Therefore, the recommended approach is to keep BGP route propagation enabled on the AzureFirewallSubnet when Azure Firewall needs connectivity to networks learned via ExpressRoute or VPN Gateway, and use UDRs only for the specific traffic that requires custom routing.Yes. In most Azure Firewall hub-and-spoke deployments that use ExpressRoute or VPN gateways, BGP route propagation should remain enabled on any route table associated with the AzureFirewallSubnet, unless you have a very specific design that intentionally replaces propagated routes.

In your case, the behavior is expected:

• When you associated a UDR with BGP route propagation disabled, the Azure Firewall subnet stopped learning routes advertised by the ExpressRoute gateway.
• As a result, the firewall no longer had routes for your on-premises prefixes (for example, 10.151.0.0/16), so traffic destined for those networks could not be forwarded correctly.
• Removing the route table restored gateway-propagated routes, which is why connectivity returned immediately.

If you need to use a custom UDR on the AzureFirewallSubnet:

• Enable BGP route propagation so the firewall continues to receive routes from the ExpressRoute or VPN gateway.
• Add only the specific UDRs that are required for your design (for example, steering selected prefixes to a virtual appliance).
• Verify the effective routes on the AzureFirewallSubnet after making changes to ensure both propagated and user-defined routes are present and that route precedence produces the expected result.

Will enabling route propagation affect Internet traffic?

Generally, no.

Enabling route propagation simply allows the subnet to learn routes from the virtual network gateway. It does not automatically change Internet-bound traffic. Internet traffic will continue to follow the most specific matching route:

• A more specific UDR takes precedence over propagated routes.
• If no more specific route exists, the default Internet system route (or a configured default route such as 0.0.0.0/0) continues to be used.

You should only expect Internet connectivity changes if:

• a propagated route overlaps or is more specific than the intended Internet path,
• a default route (0.0.0.0/0) is advertised over ExpressRoute (forced tunneling),
• or your custom UDRs override the expected routing behavior.

Therefore, the recommended approach is to keep BGP route propagation enabled on the AzureFirewallSubnet when Azure Firewall needs connectivity to networks learned via ExpressRoute or VPN Gateway, and use UDRs only for the specific traffic that requires custom routing.

Answer 2

Hello,

A custom route table was associated with AzureFirewallSubnet while gateway route propagation was disabled. As a result, Azure Firewall stopped learning routes propagated from the ExpressRoute gateway, causing loss of connectivity to on-premises prefixes such as 10.111.0.0/16. Connectivity was restored immediately after removing the route table association. Reports of Internet connectivity issues on hub workloads were observed during the same period but require further validation to determine whether they were directly related to the routing change.

Regards