@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!
VRF can be shared by different VNET's, each one using its VRF?
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.
3 answers
Sort by: Most helpful
-
-
SaiKishor-MSFT 17,231 Reputation points
2020-11-04T23:52:06.733+00:00 - 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!
-
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!