- Between your on-premises site <=> VNet in Azure via IPsec tunnel.
- Resources on local network can communicate with resources on Azure VNet
- No need for separate connection for each client computer in local network.
- Requires VPN device.
- E.g.:
- IT Pros and Developer in-office have their own gateway and connect to Azure.
- Q&A offshore team has its own gateway and connect to Azure
- Configured on each client computer that you want to connect to the VNet in Azure.
- No need for VPN device
- Instead you use VPN client you install on each client computer.
- Requires manually starting connection from client, can have auto reset.
- Q&A offshore team connects via VPN gateway (site-to-site VPN)
- Developers & IT Pros at office connects via VPN gateway (site-to-site VPN)
- Developers working from home connect via direct VPN (point-to-site VPN)
- Reasons
- Multiple branch offices, it's costly to purchase peering for every location.
- Multiple networks within the enterprise
- Connect one to Azure using Express route for higher-risk traffic.
- For lower-risk traffic, use site-to-site VPN
- Use site-to-site VPN as a failover link if ExpressRoute connection fails.
- Utilizes Azure VPN gateways to connect VNets in Azure over IPSec/IKE tunnels.
- E.g.: you have following topology (topology=nodes connect to other network via links)
- IT-pros/developers in office has VPN-to-VPN to Azure East Asia
- Offshore QA team has VPN-to-VPN to Azure West US
- You set VNet-to-VNet between Azure East Asia and Azure West US
- Then both team can access Azure East Asia and Azure West US
- For failover, backup or migration between providers.
- Amazon Web Services (AWS) =>
- Create EC2 VM with Openswan (VPN software)
- Create gateway on the Azure VNet side using static routing.
- Use gateway IP from Azure to configure Openswan for tunnel connection