Azure Question posted in
The official documentation to get you started can be found here.

Azure routing between different subscriptions – force one, common outbound IP and share Site-to-site (IPSec) defined in Virtual network gateway

So I have 3 Azure subscriptions: Staging, Dev1 and Dev2.

In the Staging I have:

  1. Virtual network with:
  • defaultSubnet 10.0.0.0/24
  • GatewaySubnet 10.0.1.0/24
  1. Virtual network gateway with connection Site-to-site (IPsec) (BGP disabled) connected to GatewaySubnet
  2. NAT gateway with static outbound IP connected to defaultSubnet
  3. WebApp integrated with Virtual network/defaultSubnet

And everything is working fine:

  1. WebApp can connect to resources via priver IPs over Site-to-site (IPsec)
  2. If accessing public IPs over Iternet WebApp traffic is directed over static outbound IP

It’s necessary as 3rd party services which WebApp is using are either whitelisting IPs (so static outbound) or require IPsec connection.

The problem is, that I want to use the same outbound IP and IPsec connection for WebApp1 and WebApp2 located in Dev1 and Dev2 subscriptions respectively.

The connections to the 3rd party services includes REST, SOAP, FTP(s) so ideally I’d like to have it resolved on the transport layer.

I’ve tried many different things:

  1. Created virtual network (with gateway and without) in Dev1
  2. Assigned WebApp1 to the virtual network
  3. Created peering from the vnet to the vnet from Staging
  4. Created connectivity configuration in Network Manager
  5. Created routes

Unfortunately the only result I’ve got is the ability to ping WebApp (Staging) from WebApp1 (Dev1) and vice versa. But I cannot access 3rd party resources over IPsec from WebApp1 and also I cannot force WebApp1 to use static outbound IP from Staging subscription.

I’ve followed a couple responses from SO (including this which was quite promising) but apparently I’m doing something wrong. Can you please direct me to the right solution, as Azure provides so many settings in aforementioned components, that I probably configured something wrong…

I’m also willing to use some 3rd party solutions available in the Azure, if necessary.

EDIT:
Following the solution from the response I encountered a problem to provide settings as described. When creating a peering from dev to staging and trying to setup: Enable ‘dev1-virtual-net’ to use ‘staging-test’s’ remote gateway or route server I’m getting "
‘dev1-virtual-net’ cannot use ‘staging-test’s’ remote gateway or route server because it already has a gateway or route server in the virtual network." as I have Route Server, on the other hand if I remove Route Server I cannot select "Allow gateway or route server in ‘dev1-virtual-net’ to forward traffic to the peered virtual network". If I understood your description, both should be checked which seems impossible…

Azure Peering issue

Tags:

2

Answers


  1. Chosen as BEST ANSWER
    0

    OK, I figured it out, finally. In general Suresh's answer is the proper one (thus I marked it as such), but I had some problems on the way:

    1. My spoke address range was outside of the range agreed with site-to-site VPN other end (3rd party), so I had to remodel addresses on my side.
    2. All traffic from the Spoke has to be directed to the firewall, no matter if it needs to use static IP or site-to-site VPN.
    3. Initially I used Azure Firewall (more about it later) and I had problems with the Spoke traffic returning from the site-to-site VPN (it was stuck between virtual gateway and spoke service, what is weir ICMP was OK, only SSL handshake failed, Wireshark logs indicated ACK phase), I had to add routing for the Spoke traffic to the gateway subnet.
    4. Azure firewall is very expensive, and, providing that I'm not using it at all beside routing, I finally used Ubuntu VM configured as in https://learn.microsoft.com/en-us/azure/nat-gateway/tutorial-hub-spoke-route-nat, although I used only one interface with both internal and external IP.
    5. With Ubuntu VM this extra routing to the Spoke mentioned before was not needed ¯(ツ)/¯

    Maybe it helps someone.


  2. 0

    I want to use the same outbound IP and IPsec connection for WebApp1 and WebApp2 located in Dev1 and Dev2 subscriptions respectively.

    Since native Azure networking doesn’t fully support above requirements

    Firstly, Fix virtual network Peering and Gateway Settings

    • In the Staging Virtual Network Peering, Check Allow gateway transit is enabled.
    • In the Dev1 and Dev2 VNets, check Use remote gateway is enabled, Allow forwarded traffic is enabled.

    Set up User-Defined Routes (UDRs) in Dev1 and Dev2 to direct traffic appropriately

    For Internet traffic (0.0.0.0/0):

    • Next hop: Virtual Network Gateway (Staging VNet).

    For On-premises IPs via IPsec:

    • Next hop: Virtual Network Gateway (Staging VNet).

    Azure Firewall supports SNAT (Source NAT) for peered networks. Deploying it in the Staging subscription allows to centralize outbound traffic and enforce the use of a single static IP.

    • Deploy Azure Firewall in the Staging VNet.

    • Configure DNAT/SNAT rules for internet-bound traffic. Default route in the Staging VNet to direct 0.0.0.0/0 to Azure Firewall.

    • Update UDRs in Dev1 and Dev2 to route all internet-bound traffic (0.0.0.0/0) to the Staging Azure Firewall.

    By this setup you can be able to share the outbound static IP and IPsec connection configured in the Staging subscription to WebApps in Dev1 and Dev2.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search