Extending the on site lab network to an Azure VNET.


VMWare Lab Network:

New Azure VNET: IP Range:

New Server Subnet: IP Range:

After creating the new Azure VNET:

1 - Add a Gateway Subnet

  • Select the Network, then Subnets in Azure portal.
  • Click “Gateway Subnet”
  • Address range: (11 IP’s + the 5 Azure reserves)

2 - Update DNS for VNET clients

  • Since they’ll want to join the on-prem AD
  • Click on the new virtual network, then DNS Servers
  • Add the on-prem DNS server addresses

3 - Create Virtual Network Gateway

  • Go back to the resource group level
  • Click Add
  • Search for Virtual Network Gateway (click create)
  • Gateway Type is VPN for this adventure
  • VPN type is ‘route based’
  • Select the virtual network it will connect
  • Select the gateway subnet we just created
  • Click create - it’ll warn, but this can take 15 - 45 minutes.

4 - Create Local Network Gateway Object

  • You need an object that Azure will reference as the other side of the VPN tunnel.
  • Go back to the resource group level
  • Click Add
  • Search for Local network gateway (click create)
  • Name: something that makes it obvious what thi sobject is for
  • IP address: your edge router (firewall) IP address
  • Address space: the internal subnets on the other site that azure will build as routes.
  • Location: same location as before

5 - Create site-to-site VPN

  • Click on the virtual gateway that was created in part 3
  • Choose connections - Add connection
  • Choose ‘site to site ipsec’
  • Configure a pre shared key

6 - Connect it up.

  • Make sure the IPSEC traffic is being forwarded through to the VMWARE gateway.
  • Locate the IP address of the gateway (it’ll be needed by the firewall on the other side)
  • Create a new Site to Site - IPSEC tunnel
  • Create a new route for the Azure network on the other side of the tunnel
  • Configure firewall exceptions on the gateway.

7 - What went wrong?

  • Azure to On-Prem traffic was being filtered on the pfsense firewall.
  • (Other direction is fine, ping, SMB etc, all good)
  • Pfsense has built in packet capture that showed the packets arriving 18:04:17.666589 (authentic,confidential): SPI 0xc5e2e529: IP > ICMP echo request, id 1, seq 625, length 40
  • Hair pulling out
  • Block bogon networks - once unchecked on the WAN interface in pfsense, no more dropping packets. Solved (but not yet understood).
Blog Logo

Chad Duffey



Chad Duffey

Blue Team -> Exploit Development & things in-between

Back to Overview