Azure mit dem Homelab verbinden

Voraussetzungen

Du brauchst feste “Startpunkte”, damit Azure weiß, wohin es deinen Traffic schicken soll, und dein Homelab weiß, wohin Azure gehört.

• Homelab: pfSense routet deine VLANs (z.B. VLAN10 192.168.10.0/24), DC01/DC02 laufen.

• Azure: Du hast eine Ressourcengruppe und darfst Netzwerke/Gateways erstellen.

Azure: Virtuelles Netzwerk (VNet) erstellen

Das ist dein “Azure-LAN”. Alle Azure-VMs bekommen IPs daraus.

Azure Portal → Virtuelle Netzwerke → Erstellen

• VNet: VNET-HOMELAB

• Adressraum: 10.50.0.0/16

Subnetze anlegen

Subnetze trennen Rollen. Ein Subnetz ist für Server, eins ist zwingend fürs VPN-Gateway.

Im VNet → Subnetze

• Servers: 10.50.10.0/24
  (Hier kommen deine Azure-Server rein.)

• GatewaySubnet: 10.50.255.0/27
  (Azure braucht dieses Subnetz exklusiv fürs VPN-Gateway. Der Name muss exakt so heißen.)

Azure: Local Network Gateway erstellen

Azure muss wissen, wie dein Zuhause-Netz aussieht und über welche öffentliche IP es erreichbar ist.

Azure Portal → Local network gateways → Erstellen

• Name: lng-home-pfsense

• IP-Adresse: deine öffentliche Home-IP (z.B. 203.0.113.10)

• Adressräume: 192.168.10.0/24
  (Optional später mehr Netze, wenn du sie über VPN erreichen willst.)

Azure: Virtual Network Gateway (VPN Gateway) erstellen

Das ist das Azure-Gegenstück zu pfSense-IPsec. Ohne Gateway kein Tunnel.

Azure Portal → Virtual network gateways → Erstellen

• Name: vng-homelab

• Gatewaytyp: VPN

• VPN-Typ: Routenbasiert (Route-based)
  (Route-based ist Standard und funktioniert sauber mit mehreren Netzen.)

• Virtuelles Netzwerk: VNET-HOMELAB

• Öffentliche IP: neu erstellen (z.B. pip-vng-homelab)

Warten bis fertig.

Azure: Connection (Verbindung) erstellen

Erst die Connection “verheiratet” das Azure-Gateway mit deinem Home-Gateway (Local Network Gateway).

Azure Portal → vng-homelab → Verbindungen → Hinzufügen

• Name: conn-vng-homelab-to-pfsense

• Typ: Site-to-site (IPsec)

• Local network gateway: lng-home-pfsense

• Shared Key (PSK): [DEIN_PSK]
  (Das ist das gemeinsame Passwort für den Tunnel. Muss später 1:1 in pfSense identisch sein.)

Status am Ende: Verbunden.

FritzBox: Portweiterleitung zur pfSense

Azure muss deinen IPsec-Endpunkt (pfSense) aus dem Internet erreichen. Ohne Portfreigabe kommt nie was an.

FritzBox → Portfreigaben auf pfSense-WAN-IP (z.B. 192.168.178.52)

• UDP 500 → 192.168.178.52 (IKE)

• UDP 4500 → 192.168.178.52 (NAT-T)

pfSense: IPsec Site-to-Site einrichten

Jetzt baust du den Tunnel auf der Home-Seite.

pfSense → VPN → IPsec

Phase 1 (IKE)

Phase 1 ist die “gesicherte Verbindung” zwischen den Gateways (Schlüsseltausch, Auth).

• IKE Version: IKEv2

• Remote Gateway: Azure Gateway Public IP

• Auth: Mutual PSK

• PSK: [DEIN_PSK]

Phase 2 (Child SA / P2)

Phase 2 definiert, welche Netze wirklich durch den Tunnel dürfen (dein LAN ↔ Azure LAN).

• Local: 192.168.10.0/24

• Remote: 10.50.0.0/16

Speichern / Apply.

pfSense: Firewall-Regeln setzen

Tunnel kann stehen, aber pfSense blockt Traffic, wenn du es nicht erlaubst.

WAN-Regeln (falls nötig)

Damit IKE/ESP überhaupt in pfSense ankommen.

Firewall → Rules → WAN

• UDP 500 erlauben (von Azure Gateway IP)

• UDP 4500 erlauben (von Azure Gateway IP)

IPsec-Regeln (wichtig)

Das sind die Regeln für den Traffic im Tunnel.

Firewall → Rules → IPsec

1. Pass IPv4 any
   Source: 192.168.10.0/24 → Destination: 10.50.0.0/16

2. Pass IPv4 any
   Source: 10.50.0.0/16 → Destination: 192.168.10.0/24

Apply.

Azure: DC03 VM erstellen und Netzwerk festlegen

Die VM ist dein Azure-Server. Er muss im richtigen Subnetz sein und eine feste IP haben (DCs brauchen Stabilität).

Azure → Virtuelle Computer → Erstellen

• VNet: VNET-HOMELAB

• Subnetz: Servers (10.50.10.0/24)

Danach: DC03 NIC → IP-Konfiguration

• Private IP: statisch (z.B. 10.50.10.4)

DC03: DNS korrekt setzen

Für Domain Join und Replikation muss DC03 deine AD-DNS-Server erreichen und benutzen.

Auf DC03:

• DNS Server:

  • 192.168.10.10 (DC01)

  • 192.168.10.11 (DC02)

Verbindung prüfen (Azure)

1. Virtuelles Netzwerk-Gateway öffnen
   → Verbindungen → deine Verbindung auswählen
   → Status muss „Verbunden“ sein.

Verbindung prüfen (pfSense)

1. Status → IPsec öffnen
   → Phase 1 muss „Hergestellt“ sein
   → Phase 2 muss „Installiert“ sein
   → Pakete und Datenmengen sollten steigen, wenn du Daten sendest (zum Beispiel Ping).

2. Firewall → Regeln → IPsec prüfen
   → Es müssen Regeln existieren, die den Datenverkehr erlauben zwischen:

   • 192.168.10.0/24 (dein Servernetz zuhause)

   • 10.50.0.0/16 (dein Netzwerk in Azure)

3. Optional: Diagnose → Ping in pfSense
   → Ziel: 10.50.10.4 (dein Server in Azure)
   → Wenn Antworten kommen, läuft der Verkehr wirklich durch den Tunnel.

Verbindung testen (DC03)

Bevor AD ins Spiel kommt, muss Routing/DNS sauber funktionieren.

Auf DC03:

• ping 192.168.10.1 (pfSense VLAN10 GW)

• ping 192.168.10.10 (DC01)

• nslookup ad.rubinhood.de 192.168.10.10

DC03 als zusätzlicher Domain Controller (Replikation)

Ein zusätzlicher DC repliziert AD/DNS mit DC01/DC02 und bringt dir Azure-seitig einen DC.

1. Rollen installieren:

• AD DS + DNS

1. Promote:
   Server Manager → Flagge → Promote this server to a domain controller

• Add a domain controller to an existing domain

• Domain: ad.rubinhood.de

• Credentials: Domain Admin (z.B. AD\Administrator)

• Optionen:

  • DNS Server ✅

  • Global Catalog ✅

  • RODC ❌

• DSRM Passwort setzen

• Install → Neustart

Nachkontrolle Replikation

Du willst sicher sein, dass DC03 wirklich repliziert und nicht nur “irgendwie DC ist”.

Auf DC03:

• repadmin /replsummary

• nltest /dsgetdc:ad.rubinhood.de

Benutzer von lokalem Active Directory nach Microsoft Entra ID synchronisieren

20.12.2025

Bevor irgendetwas synchronisiert werden kann, muss Microsoft Entra Connect Sync installiert und mit dem Azure-Konto verbunden werden.