Technical Assistance Required – Existing Azure VPN Connectivity Production Environment

Santhosh S 0 Reputation points
2026-10-26T17:24:29.1133333+00:00

Subject: Technical Assistance Required – Existing Azure VPN Connectivity for Riayati Production Environment

We are using Microsoft Azure cloud infrastructure for our Medimate 247 EMR Software.

We have already configured an Azure VPN Gateway and established connectivity with Riayati (UAE Health Information Exchange).

Currently, our demo environment is successfully communicating with Riayati, and we have already shared demo patient data.

Riayati has now requested that we start sharing patient data from our production environment.

We need technical assistance to understand the required Azure network configuration.

Our questions are:

Can we use the existing Azure VPN Gateway and VPN connection for both demo and production environments?

If the production server is hosted in a separate Virtual Network, can we establish connectivity through the existing VPN Gateway?

Do we need VNet peering, additional routing configurations or firewall changes?

Does this requirement necessitate a new VPN Gateway or only an additional VPN connection?

What is the recommended architecture for maintaining separate demo and production environments while sharing data with Riayati?

Our objective: To enable production data sharing with Riayati while reusing the existing Azure VPN infrastructure wherever technically possible.

We request your technical team to review our existing VPN configuration and guide us on the necessary changes without affecting the current demo connectivity.

Azure VPN Gateway
Azure VPN Gateway

An Azure service that enables the connection of on-premises networks to Azure through site-to-site virtual private networks.

0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Jose Benjamin Solis Nolasco 12,941 Reputation points Volunteer Moderator
    2026-10-27T00:02:37.23+00:00

    Welcome to Microsoft Q&A

    Hello @Santhosh S I hope you are doing well,

    In most cases, you can reuse the existing Azure VPN Gateway and Riayati VPN connection for both demo and production environments, provided the network design and routing requirements are approved by the Riayati team.

    A few general considerations:

    • If the production environment is in the same VNet as the demo environment, you can usually add the production subnet address ranges to the existing routing configuration and security rules.
    • If the production environment is in a separate VNet, the common approach is to use VNet peering and configure the production VNet to use the existing VPN Gateway (gateway transit). This allows the production workloads to reach Riayati through the existing Site-to-Site VPN without deploying another gateway.
    • You may need to update:
      • VPN route definitions
        • Network security groups (NSGs)
          • Azure Firewall or third-party firewall rules (if used)
            • The address prefixes configured on the Riayati side

    A new VPN Gateway is not always required. Whether you need an additional VPN connection or route updates depends on:

    • The existing network topology
    • Whether the production VNet uses overlapping address spaces
    • Riayati's accepted network ranges and connectivity requirements

    For a production healthcare environment, the typical recommendation is:

    • Separate Demo and Production workloads into different VNets.
    • Use VNet peering with gateway transit (if appropriate).
    • Keep security boundaries between environments.
    • Reuse the existing VPN Gateway where possible to reduce cost and operational complexity.

    To provide more specific guidance, could you share:

    • Whether the production environment is in the same VNet or a different VNet.
    • Whether the VPN is configured as Site-to-Site VPN Gateway or ExpressRoute.
    • The VNet address spaces used for Demo and Production.

    References

    If my answer helped you resolve your issue, please consider marking it as the correct answer. This helps others in the community find similar solutions.

    Was this answer helpful?

    0 comments

  2. AI answer

    2026-10-26T17:26:46.2066667+00:00

    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.

    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
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

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