can not connect server on premises via Azure Firewall in KC vHUB

2025-07-31T01:21:25.52+00:00

Tenant: lge.com (5069cde4-642a-45c0-8094-d0c2dec10be3) Subscription: LGE-MGMT (96ec6c81-b0fe-4eaf-8cce-c93374f4da83)

VNet: vnet-kc-thinq10-dev, 10.123.24.0/25  Subnet: sbn-kc-thinq10-dev-pri, 10.123.24.64/26  NSG: nsg-vnet-kc-thinq10-dev

Virtual WAN: vwan-kc-lge-mgmt vHub: hub-kc-lge-mgmt-vwan Azure KC Firewall: AzureFirewall_hub-kc-lge-mgmt-vwan Azure KC Firewall Policy: fwpolicy-kc-hub-lge-mgmt


Issue Description

  1. Environment Overview:

In the VWAN, the KC vHub has been created with routing intent configured and an Azure Firewall deployed.

In the default route table of the vHub, a route to the IDC summary address is configured with Next-Hop: Azure Firewall.

The vHub has a deployed VPN Gateway, and is connected to the Seoul IDC via a Site-to-Site VPN, with static routes configured. The vHub is also associated with the default route table.

The VNet is connected to the vHub, and is associated with the vHub's default route table. Therefore, the VNet receives propagation of the IDC summary address.

  1. Issue Symptoms:

Communication is needed from the VNet connected to the vHub to the IDC server.

The required security rules on the KC Azure Firewall and IDC VPN device have been configured to allow traffic.

Source IP: 10.123.24.73 (vm-kc-thinq10-dev-was-1-az3)

  **Destination IP**: 165.186.128.33 (accessed via `https://165.186.128.33:24500`)
  
     **Port**: TCP 24500
     
     However, when trying to communicate from the VM within the VNet:
     
        **No traffic logs appear** on the IDC VPN device.
        
           **Packet dump on the VM** shows repeated retransmission of **SYN packets** but **no SYN+ACK responses**.
           
              **Traceroute** from the VM using `traceroute -T -p 24500 165.186.128.33` suggests that packets are **not being forwarded beyond the Azure Firewall**.
              

Sample traceroute output:

bash
복사
[sysadmin@vm-kc-thinq10-dev-was-1-az3 ~]$ sudo traceroute -T -p 24500 165.186.128.33
traceroute to 165.186.128.33 (165.186.128.33), 30 hops max, 60 byt
1  10.123.4.168 (10.123.4.168)  2.244 ms  2.238 ms  2.188 ms
2  * * *
3  * * *
4  * * *
...

Request

Please investigate the root cause of this issue and suggest how it can be resolved. Thank you.Tenant: lge.com (5069cde4-642a-45c0-8094-d0c2dec10be3)

Subscription: LGE-MGMT (96ec6c81-b0fe-4eaf-8cce-c93374f4da83)

VNet: vnet-kc-thinq10-dev, 10.123.24.0/25
 Subnet: sbn-kc-thinq10-dev-pri, 10.123.24.64/26
 NSG: nsg-vnet-kc-thinq10-dev

Virtual WAN: vwan-kc-lge-mgmt
vHub: hub-kc-lge-mgmt-vwan
Azure KC Firewall: AzureFirewall_hub-kc-lge-mgmt-vwan
Azure KC Firewall Policy: fwpolicy-kc-hub-lge-mgmt


Issue Description

  1. Environment Overview:

In the VWAN, the KC vHub has been created with routing intent configured and an Azure Firewall deployed.

In the default route table of the vHub, a route to the IDC summary address is configured with Next-Hop: Azure Firewall.

The vHub has a deployed VPN Gateway,
and is connected to the Seoul IDC via a Site-to-Site VPN,
with static routes configured.
The vHub is also associated with the default route table.

The VNet is connected to the vHub,
and is associated with the vHub's default route table.
Therefore, the VNet receives propagation of the IDC summary address.

  1. Issue Symptoms:

Communication is needed from the VNet connected to the vHub to the IDC server.

The required security rules on the KC Azure Firewall and IDC VPN device have been configured to allow traffic.

Source IP: 10.123.24.73 (vm-kc-thinq10-dev-was-1-az3)

  **Destination IP**: 165.186.128.33 (accessed via `https://165.186.128.33:24500`)
  
     **Port**: TCP 24500
     
     However, when trying to communicate from the VM within the VNet:
     
        **No traffic logs appear** on the IDC VPN device.
        
           **Packet dump on the VM** shows repeated retransmission of **SYN packets** but **no SYN+ACK responses**.
           
              **Traceroute** from the VM using `traceroute -T -p 24500 165.186.128.33` suggests that packets are **not being forwarded beyond the Azure Firewall**.
              

Sample traceroute output:

bash
복사
[sysadmin@vm-kc-thinq10-dev-was-1-az3 ~]$ sudo traceroute -T -p 24500 165.186.128.33
traceroute to 165.186.128.33 (165.186.128.33), 30 hops max, 60 byt
1  10.123.4.168 (10.123.4.168)  2.244 ms  2.238 ms  2.188 ms
2  * * *
3  * * *
4  * * *
...

Request

Please investigate the root cause of this issue and suggest how it can be resolved.
Thank you.

Azure Virtual WAN
Azure Virtual WAN
An Azure virtual networking service that provides optimized and automated branch-to-branch connectivity.
{count} votes

1 answer

Sort by: Most helpful
  1. G Sree Vidya 4,080 Reputation points Microsoft External Staff Moderator
    2025-07-31T18:28:39.0333333+00:00

    Hi 김철용/(협력사) 책임/플랫폼인프라팀

    It looks like you're having trouble connecting to an on-premises server through an Azure Firewall in your Virtual WAN setup.

    We recommend checking the following details:

    1. Ensure Routing Configuration on the default route points to the Azure Firewall and verify that no custom routes in the vHub are bypassing the firewall.
    2. Confirm Firewall Rule there are no deny rules blocking traffic from the VM (10.123.24.73) to the destination IP (165.186.128.33) on TCP port 24500.
      • Sometimes, explicit deny rules can silently block required traffic.
    3. Verify the VPN Gateway Configuration that the static route to 165.186.128.33 is correctly configured on the VPN Gateway and confirm that return traffic from IDC to Azure is allowed and correctly routed.
    4. Even if no logs are visible, verify whether the IDC firewall might be silently dropping traffic, it allows traffic from the Azure VM’s translated IP (if SNAT is used).
    5. Use the Effective Routes view on the VM’s NIC to confirm that traffic to 165.186.128.33 is routed through the Azure Firewall.
    6. If your application uses FQDNs or private endpoints, ensure the VNet’s DNS settings are correctly configured—especially if DNS resolution is expected to go through the Azure Firewall.
    7. Since you're using a Site-to-Site VPN, verify that the tunnel is correctly configured, including shared keys and IPsec/IKE settings on both ends.

    Refer: https://techcommunity.microsoft.com/blog/azurenetworksecurityblog/monitoring-traffic-flows-in-azure-firewall-using-virtual-network-flow-logs/4233245

    https://learn.microsoft.com/en-us/azure/firewall/monitor-firewall

    Kindly verify the above steps and do let me know if you need further assistance, we will be happy to assist.

    0 comments No comments

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.