From WSL to Azure: A Full Infrastructure Deployment, VPN & SIEM Pipeline in One Day

TL;DR: Using nothing more than a Windows machine running WSL2, VSCode, and Terraform — we provisioned an entire Azure cloud environment, stood up a VPN gateway, and built a fully operational SIEM pipeline ingesting logs from both Unifi network hardware and SentinelOne EDR. Here's exactly how we did it.

The Challenge

Modern security operations don't live in one place. Your network logs are in your router. Your endpoint telemetry is in your EDR. Your cloud infrastructure is in Azure. Stitching all of this together into a single, queryable, alertable SIEM — while keeping the entire workflow reproducible and code-driven — is what separates a reactive IT team from a proactive security operation.

This post walks through exactly how we tackled that for a client environment: end-to-end, from a Windows laptop running WSL2 to a production-ready Azure SIEM pipeline.

The Stack

| Layer | Technology | |---|---| | Local Dev Environment | Windows 11 + WSL2 (Ubuntu 22.04) + VSCode | | IaC Tooling | Terraform (Azure Provider ~> 3.90) | | Cloud Platform | Microsoft Azure | | Connectivity | Azure VPN Gateway — IPsec Site-to-Site | | SIEM | Microsoft Sentinel (Log Analytics Workspace) | | Log Sources | Unifi UDM-Pro + SentinelOne EDR |

Part 1 — The Dev Environment: WSL2 + VSCode

Everything starts local. Rather than spinning up a dedicated Linux jumpbox, we used WSL2 directly on the Windows workstation — full Linux tooling, one machine, one screen.

The Terraform project lives inside the WSL2 filesystem and opens in VSCode via the Remote-WSL extension. The green WSL: Ubuntu-22.04 indicator in the status bar confirms you're operating natively in the Linux context.

WSL2 Setup

# PowerShell (Administrator)
wsl --install -d Ubuntu-22.04
wsl --set-default-version 2
wsl -l -v   # confirm VERSION 2

Tune WSL memory limits so it doesn't consume the host during a large terraform apply:

# C:\Users\YourName\.wslconfig
[wsl2]
memory=6GB
processors=4
swap=2GB
localhostForwarding=true

Terraform Install (WSL)

wget -O- https://apt.releases.hashicorp.com/gpg | \
  gpg --dearmor | \
  sudo tee /usr/share/keyrings/hashicorp-archive-keyring.gpg > /dev/null

echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] \
  https://apt.releases.hashicorp.com $(lsb_release -cs) main" | \
  sudo tee /etc/apt/sources.list.d/hashicorp.list

sudo apt update && sudo apt install terraform -y
terraform version

Azure CLI Auth

curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash
az login
az account set --subscription "<your-subscription-id>"

Part 2 — Terraform: Deploying the Azure Foundation

A single terraform apply provisions the complete environment — VNet, subnets, NSG, NIC, forwarder VM, Log Analytics Workspace, Sentinel onboarding, and Data Collection Rule.

Project Structure

sentinel-syslog/
├── cloud-init.yaml      ← VM bootstrap (rsyslog + OMS agent)
├── main.tf
├── outputs.tf
├── variables.tf
└── terraform.tfvars     ← gitignored

Core Resources

The Terraform config provisions a resource group, VNet with a GatewaySubnet (/27 minimum enforced by Azure) and a workloads subnet, plus an NSG allowing syslog inbound from the on-prem CIDR. A Log Analytics Workspace with 90-day retention and Sentinel onboarding complete the foundation.

Deploy

terraform init
terraform plan -out=tfplan
terraform apply tfplan

After apply, the resource group contains everything needed — VNet, NSG, NIC, VM, Log Analytics workspace, the SecurityInsights Sentinel solution, and a Data Collection Rule, all tagged ManagedBy: Terraform.

Part 3 — VPN Gateway

The VPN connects the on-premises Unifi network to the Azure VNet over an encrypted IPsec tunnel. All log traffic flows privately — no public internet exposure for syslog or CEF data.

The Terraform config provisions a Standard SKU public IP, a VpnGw1 route-based gateway on the GatewaySubnet, a local network gateway representing the on-prem site, and the IPsec connection with a shared key.

Note: VPN Gateway provisioning takes 25–45 minutes. Terraform will appear to hang on this resource — this is normal.

Unifi IPsec Settings

Configure the Unifi UDM-Pro under Settings → VPN → Site-to-Site VPN with IKEv1 key exchange, AES-128 encryption, SHA1 hash, DH Group 14, and PFS enabled. Point the remote IP at the Azure VPN Gateway public IP from terraform output.

Part 4 — Log Forwarder VM

The vm-syslog VM sits at a private IP in the workloads subnet. Because the VPN tunnel is live, SSH access is entirely over the private tunnel — no public IP, no Bastion needed.

The VM is bootstrapped via cloud-init with rsyslog and the OMS agent. Rsyslog config routes Unifi syslog (UDP 514) to the OMS agent on port 25224, and SentinelOne CEF events to port 25226.

Part 5 — Microsoft Sentinel

With logs flowing from both sources, Microsoft Sentinel provides a unified view for querying, correlation, and alerting.

Validating Both Log Sources

// Unifi syslog events
Syslog
| where ProcessName contains "unifi"
| project TimeGenerated, Computer, ProcessName, SyslogMessage
| order by TimeGenerated desc
| take 20

// SentinelOne CEF events
CommonSecurityLog
| where DeviceVendor == "SentinelOne"
| summarize EventCount = count() by Activity, bin(TimeGenerated, 1h)

// Both sources combined
union Syslog, CommonSecurityLog
| summarize Events = count() by Type, bin(TimeGenerated, 1h)
| render timechart

The Result

A fully code-driven, VPN-secured, multi-source SIEM — deployed in a single day from a Windows laptop. Every resource is defined in Terraform, tagged, and reproducible. On-premises network telemetry and endpoint detections flow privately over the VPN into Microsoft Sentinel, where a single KQL query correlates both sources simultaneously.

Nothing was clicked into existence. Everything is in code.

---

Want this built for your environment? Get in touch →