Technical Assistance Required – Existing Azure VPN Connectivity Production Environment

Reuse the existing Azure VPN Gateway by peering the production VNet directly with the gateway VNet and enabling gateway transit, provided the gateway is not Basic, the VNet address spaces do not overlap, and Riayati accepts and routes the production prefixes.

Recommended architecture

Use a hub-and-spoke layout:

                         Site-to-site IPsec VPN
Riayati network  <================================>  Hub VNet
                                                    - Existing VPN Gateway
                                                    - Optional Azure Firewall
                                                       /             \
                                                      / VNet peering  \ VNet peering
                                             Demo workload         Production VNet
                                                                     - Production servers

The production VNet remains isolated as a separate spoke but shares the hub gateway. This is the documented gateway-transit model; a separate gateway or second VPN connection is not normally required merely because production is in another VNet.^1^

If the demo workload already resides in the gateway VNet, the demo peering in this diagram is only illustrative—create new peering only for the production VNet. Azure also recommends separate spokes for environments such as production and nonproduction.^2^

Prerequisites to verify

Before changing the working connection:

1. Gateway SKU: Gateway transit does not support the Basic SKU.
2. Address spaces: The production, hub/demo, and Riayati prefixes must not overlap.
3. Production gateway: The production VNet must not already contain a VPN or ExpressRoute gateway, and it can use a remote gateway on only one peering.
4. Permissions: The change account needs Network Contributor or equivalent peering permissions on both VNets.
5. VPN characteristics: Record whether the existing connection is:
   • Route-based or policy-based.
   • BGP-enabled or static-route based.
   • Configured with explicit IPsec traffic selectors/encryption domains.
6. Capacity: Confirm the existing SKU has sufficient aggregate throughput and tunnel capacity. All tunnels share the gateway’s available bandwidth.^3^

Gateway transit supports same-region and global VNet peering, so the production VNet can also be in a different Azure region.^4^

Azure configuration

In Azure portal → Hub VNet → Peerings → Add:

1. Select the production VNet.
2. On the hub-to-production peering:
   • Allow virtual network access.
   • Enable Allow forwarded traffic.
   • Enable Allow gateway transit.
   • Do not enable Use remote gateways.
3. On the production-to-hub peering:
   • Allow virtual network access.
   • Enable Allow forwarded traffic.
   • Enable Use remote gateways.
   • Do not enable Allow gateway transit.
4. Create the peering and confirm that both directions show Connected.^1^

Then inspect Production VM NIC → Effective routes. The Riayati prefix should appear through VNetPeering or VNetGlobalPeering. Ensure no user-defined route (UDR) overrides the propagated route. If gateway-route propagation was disabled on a production subnet’s route table, enable it unless an intentional firewall-routing design replaces it.

Riayati-side changes

Riayati’s VPN/network administrator must approve and implement:

• A return route for the production Azure prefix.
• Firewall rules permitting only the required production source addresses, destination addresses, protocols, and ports.
• BGP acceptance of the production prefix, if BGP is used.
• Updates to encryption domains or traffic selectors only if Riayati’s VPN device or policy-based configuration requires explicit selectors.
• Any organizational policy requiring physically separate demo and production tunnels.

With BGP, routes can update dynamically. Without BGP, Riayati normally needs a static return-route or prefix update. BGP is supported only with route-based gateways and can propagate reachability across multiple networks.^5^

Do not change Azure’s Local Network Gateway merely to add the Azure production prefix: that resource describes prefixes located on the remote/Riayati side. If Riayati adds or changes its own network prefixes, update the complete prefix list carefully; modifying it on an active connection can cause downtime.^6^

Firewall and isolation controls

• Add production allow rules to the production subnet NSG and any Azure Firewall/NVA in the path.
• Keep demo-to-production traffic denied unless explicitly required.
• Use Azure Firewall/NVA plus UDRs only when centralized inspection is required; plain gateway transit does not inherently require custom UDRs.
• Permit return traffic symmetrically through the same inspected path.
• Restrict the flow to Riayati’s exact prefixes and application ports.

A separate gateway alone does not solve overlapping IP prefixes. That requires address-space redesign or a supported NAT design coordinated with Riayati.

Safe validation and escalation

Perform these changes in an approved maintenance window with an authorized Azure network engineer. Static routing or traffic-selector changes can reset or briefly interrupt the working demo tunnel.

Test from one production host first:

1. Confirm both peerings are Connected.
2. Check effective routes in both directions.
3. Use Network Watcher Next hop, IP flow verify, and Connection troubleshoot.
4. Confirm Riayati sees the production source prefix and return traffic.
5. Review NSG/firewall logs before enabling the full production workload.^7^

For an authorized review of the actual environment, open Azure portal → Help + support → Create a support request, select VPN Gateway/Virtual Network connectivity, and attach a sanitized topology, gateway SKU, VPN type, BGP status, connection configuration, effective routes, and Network Watcher results.^8^

References

1. Configure VPN gateway transit for virtual network peering
2. Hub-spoke network topology in Azure
3. VPN Gateway FAQ
4. Use a VPN or ExpressRoute gateway in a different region
5. About BGP and VPN Gateway
6. Modify local network gateway settings using the Azure CLI
7. Troubleshoot virtual network peering route propagation and sync problems
8. Troubleshoot connectivity problems between Azure virtual machines