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
- 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.
- 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
- 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.
- 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.