1

I have two virtual networks that each have their own virtual network gateway (VNET1 and VNET2). I have connected them with VNET to VNET connections. All resources in each VNET can see each other via PING as well as RDP so I know the VNET to VNET connection is working properly.

I also have a Point to Site configuration setup on VNET1 which allows me to VPN from my onsite premise. When I start up the VPN connection, I can see everything in VNET1, but I cannot see anything in the other VNET (VNET2).

Shouldn't I be able to see resources from both VNETs regardless of which VNET I've established my VPN connection with since they are connected to each other?

Charles Xu
  • 29,862
  • 2
  • 22
  • 39
Geekn
  • 2,650
  • 5
  • 40
  • 80

1 Answers1

1

For your issue, you can use connect VNET1 to on-premise with VPN, and connect VNET1 to VNET2 with peering, but if you want to connet VNET2 from on-premise through VPN, you have to set up gateway transit in both VNET.

You can finish you work following the document Configure VPN gateway transit for virtual network peering and you will get what you want.

Charles Xu
  • 29,862
  • 2
  • 22
  • 39
  • Before I setup peering, should I remove the existing vnet to vnet connections that presently exists between the two VNETs or do both methods of connecting VNETs have to be present? I've set it up using both. Only one of the VNETS where I setup the peer shows it as connected. Should both VNETS show the peer relationship or just one of the two? Also, the use remote gateway option is not available but the other two are checked. – Geekn Jun 08 '18 at 02:59
  • I know peering can be work, you can make a try of other methods. If you use peering, both VNET should be in it. VNET1 with VPN and **Gateway Subnet** in it selects **Allow gateway transit**, and VNET2 selects **Use remote gateway**. So that you can connect VNET2 from on-premise. – Charles Xu Jun 08 '18 at 03:12
  • Really appreciate the help. VNET2 also had it's own gateway to allow VPN into that specific VNET. I removed that gateway and was able to configure as you suggested after the gateway was dropped. Still no dice but thanks again for attempting to help me out. Probably something on my end. – Geekn Jun 08 '18 at 03:31
  • What you actually want to do? Do you mind telling more? – Charles Xu Jun 08 '18 at 05:27
  • I followed the document you specified to setup a peered vnet to vnet environment. Peering is working and vnet1 can talk to vnet2 (and vice versa). vnet1 peering has "Allow gateway transit" checked. vnet2 peering has "Use remote gateway" checked. I've also allowed forwarded traffic in each. I then setup a VPN gateway on vnet1 which I can successfully connect and allows me to manage all VMs in vnet1. It does NOT, however, allow me to manage VMs in vnet2. So I cannot access any resources from my VPN client that are outside of vnet1 (even the ones in peered vnet2). Do I need route table? – Geekn Jun 08 '18 at 16:55
  • 1
    Actually...we found why the configuration was not working. We had to re-download the VPN client. The new installer put an additional entry in the route table that allowed traffic bound to the peered vnet to use the VPN gateway. All good. Thanks for you help. – Geekn Jun 08 '18 at 21:43
  • I's sorry that I see this so late, but I am glad the answer is helpful to you. – Charles Xu Jun 11 '18 at 01:02
  • No worries Charles...any chance I could have to take a look at the next step in this process. Locking the backend VMs in the VNET down? Now that everything is connected properly, I'm trying to limit traffic to only the internal load balancer. https://stackoverflow.com/questions/50865566/security-for-peered-vnets-with-internal-load-balancer – Geekn Jun 15 '18 at 00:07
  • What do mean lock the backend VMs down? You want to limit the access from internet? Can you give me more details? – Charles Xu Jun 15 '18 at 06:02
  • Public access to the backend boxes is not supported. We are essentially setting up a private exchange where partners all connect via VPN (site-to-site or point-to-site) to VNET1. Once they are connected, we would like to expose a single point where all requests are made (internal load balancer) which will forward requests to any VM in the backend pool of VNET2. The problem seems to be related to the requirement that an internal load balancer can only target VMs in the same VNET where the load balancer resides (public load balancers don't seem to have this limitation). – Geekn Jun 15 '18 at 10:17
  • It appears that I cannot achieve what I'm looking for with the internal load balancer if I'm interpreting what Nancy is saying correctly..https://serverfault.com/questions/916764/security-for-peered-vnets-with-internal-load-balancer/916854#916854 – Geekn Jun 16 '18 at 16:30