read
Extending the on site lab network to an Azure VNET.
VMWare Lab Network: 10.0.0.0/24
New Azure VNET: IP Range: 192.168.2.0/24
New Server Subnet: IP Range: 192.168.2.0/26
After creating the new Azure VNET:
1 - Add a Gateway Subnet
- Select the Network, then Subnets in Azure portal.
- Click “Gateway Subnet”
- Address range: 192.168.2.240/28 (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 192.168.2.4 > 10.0.0.100: 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).
