VRF can be shared by different VNET's, each one using its VRF?

Jan Devos 1 Reputation point
2020-10-23T15:50:30.67+00:00

I have deployed VSRX, with its management interface in the hub VNET. However, is it possible to have a VRF on this VSRX using an interface belonging to a subnet of a spoke VNET, hence, making this VRF part of the spoke? This is shown in the upper part of the attached diagram.

If instead, the VRF's interface needs to connect to a subnet of the hub VNET, how can a spoke VNET route exclusively to this VRF (and a second spoke VNET exclusively to another VRF)? Can this without tunneling between the spoke VNET and the VSRX VRF?
This is shown in the lower part of the attached diagram, where the double sided arrows shall represent a 1:1 VSRX_VRF:VNET 'peering'.

The goal is end-to-end segregation between the two environments : each one has its own VNET - Tunnel to prem - on-prem VRF forwarding path.

Azure Virtual Network
Azure Virtual Network
An Azure networking service that is used to provision private networks and optionally to connect to on-premises datacenters.
2,427 questions
0 comments

3 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. SaiKishor-MSFT 17,231 Reputation points
    2020-10-27T01:23:52.06+00:00

    @Jan Devos You can have multiple NICs for a single VM and they can belong to different subnets but they should all belong to a single VNET. Therefore, you cannot have the VSRX have a VRF/interface in the spoke VNET. In order to segregate traffic between both the subnets of the Hub VNET and their respective spoke VNETs, you can use different route tables for the subnets. You can then connect the Vnets using either VNET peering or setting up a VPN between them. I hope this helps. If you have any further questions/concerns, please do let us know. Thank you!

  2. SaiKishor-MSFT 17,231 Reputation points
    2020-11-04T23:52:06.733+00:00

    @Jan Devos

    • Assign the different vSRX interfaces into two different subnets in the HUB vnet, each of the subnet will have its own route table in Azure (along with different VRFs internally inside the VSRX), does this make sense?
    • Then peer the Hub VNET to the Spoke vnets. Now, the subnet1 only has route to the spoke vnet1 in its routetable1.
    • The subnet2 of the hub vnet has a route to the spoke vnet2 in the route table2.
    • Since the Hub and Spoke have peering and routing in place, they should be able to communicate with each other and eventually communicate with the on-=premise via the VSRx. You don;t need any additional VPN tunnelling since you will have peering between the Hub and Spoke vnets.

    Hope this makes sense. Let me know if you have further questions. Thank you!

    0 comments
  3. SaiKishor-MSFT 17,231 Reputation points
    2020-11-09T22:03:02.68+00:00

    @Jan Devos
    Please let me know if you have any further questions regarding this issue and we will be glad to assist further. Thank you!

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