Messages

[Die VM bekommt keine IP zugewiesen.]

Ich habe jetzt versucht ein VLAN einzurichten.

In Proxmox habe ich die Network Devices konfiguriert:

net0 - vmbr0
net1 - vmbr1
net2 - vmbr2

Dann habe ich in der OPNsense unter "Interfaces > Devices > VLAN" ein neues Device mit Parent vtnet2 und VLAN tag 10 hinzugefügt: Device vlan01 [OPT2]

Interfaces > OPT2:
- IPv4 Configuration Type: Static IPv4
- IPv4 address: 192.168.10.1/24

Services > Kea DHCP > Kea DHCPv4:
- Settings
    - Service
        - Enabled: yes
    - General Settings
        - Interfaces: OPT2
- Subnets:
    - Subnet: 192.168.10.0/24
    - Pools: 192.168.10.100-192.168.10.200
    - DHCP option data
        - Domain name: lan
        - Domain search: lan
        - Time servers: 192.168.10.1

Firewall > Rules > OPT2
Add:
- Interface: OPT2
- Source: OPT2 net
- Description: ALLOW all traffic to Internet


Wieder in Proxmox:
VM erstellen:
- Network:
    - Bridge: vmbr2
    - VLAN Tag: 10
    - Firewall: no

beim Starten in Grub den Eintrag bearbeiten und "nomodeset" ergänzen, F10

Hier das Problem: Die VM bekommt keine IP zugewiesen.


In der OPNsense Konsole:

Code Select Expand

sockstat -l | grep 67
nobody dnsmasq 22258 4 udp4 *:67 *:*
mit

Code Select Expand

killall dnsmasq kann ich das beenden und wenn ich bei Services > Kea DHCP > Kea DHCPv4 > Settings den Kea Service deaktiviere und wieder aktiviere, bekomme ich:

Code Select Expand

sockstat -l | grep 67
root kea-dhcp4 57322 15 udp4 192.168.10.1:67 *:*
Damit habe ich die IP 192.168.10.100 auf der Ubuntu-VM und auch der Zugang zum Internet funktioniert!

Aber beim Reboot der OPNsense wird ja zuerst dnsmasq auf dem Port 67 gestartet. Wie kann ich das denn so konfigurieren, dass der Kea DHCPv4 den Port bekommt?

Ich habe mir jetzt das /56-Subnetz sowie eine weitere IP-Adresse bestellt.
Hier die Übersicht der Adressen:

203.0.113.108    (zweite MAC "02:11:22:33:44:55")
203.0.113.112  (original MAC)

2001:db8:6b:28e7:: / 64    original MAC      (203.0.113.112)
2001:db8:6b:f300:: / 56    02:11:22:33:44:55 (203.0.113.108)


Die OPNsense bekommt:
02:11:22:33:44:55 (die zweite MAC)
203.0.113.108/32
Gateway: 203.0.113.65
2001:db8:6b:28e7::1/64
Gateway: fe80::1 (Far Gateway)

Ich probiere also folgendes Setup nach https://forum.opnsense.org/index.php?topic=44159.msg220167#msg220167:

Code Select Expand

auto lo
iface lo inet loopback
iface lo inet6 loopback

auto enp9s0
iface enp9s0 inet manual
iface enp9s0 inet6 manual

auto vmbr0
iface vmbr0 inet static
        address 203.0.113.112/32
        gateway 203.0.113.65
        bridge-ports enp9s0
        bridge-stp off
        bridge-fd 0
        bridge-mcsnoop 0
        post-up echo 1 > /proc/sys/net/ipv4/ip_forward
        post-up echo 1 > /proc/sys/net/ipv4/conf/enp9s0/proxy_arp
        post-up echo 1 > /proc/sys/net/ipv6/conf/enp9s0/forwarding
#Proxmox WAN Bridge

iface vmbr0 inet6 static
        address 2001:db8:6b:28e7:1::2/80
        gateway fe80::1
        post-up ip -6 route add 2001:db8:6b:f300::/64 via 2001:db8:6b:28e7:1::1

auto vmbr1
iface vmbr1 inet static
        address 192.168.1.2/24
        bridge-ports none
        bridge-stp off
        bridge-fd 0
        bridge-mcsnoop 0
        post-up ip route add 192.168.0.0/16 via 192.168.1.1 dev vmbr1
#LAN bridge

source /etc/network/interfaces.d/*
Die originale MAC liegt weiter auf enp9s0 und die zweite MAC ist in Proxmox bei der OPNsense auf dem Network Device (net0).

Mit ssh -i ~/.ssh/hetzner_key -L 8443:192.168.1.1:443 root@2001:db8:6b:28e7:1::2 komme ich jetzt via https://localhost:8443/ auf die OPNsense. Auch die Verbindung über die 203.0.113.108 funktioniert, wenn ich IPv4 von any to any testweise in der Firewall erlaube.

Damit ich https://192.168.1.2:8006/ aufrufen kann, musste ich noch in der OPNsense unter VPN > WireGuard > Instances den MTU auf 1380 setzen.

Hier die WireGuard-Client-Konfiguration:

Code Select Expand

[Interface]
PrivateKey = [...]
Address = 10.0.0.10/32
DNS = 1.1.1.1
MTU = 1380

[Peer]
PublicKey = [...]
AllowedIPs = 192.168.1.0/24
Endpoint = 203.0.113.108:51820

Ich habe jetzt also die 2001:db8:6b:28e7:1::2/80 auf Proxmox (vmbr0) und die 2001:db8:6b:28e7:1::1/80 auf dem WAN der OPNsense.

Unter Services > Router Advertisments > LAN:
Router Advertisements: Unmanaged
Advertise Routes: 2001:db8:6b:f300::/64

Firewall > Rules > VPN:
IPv4, Description "Tunnel_To_Any", sonst ist alles auf "any"

Firewall > Rules > WAN:
Da ist vermutlich zu viel erlaubt, aber jetzt sieht es so bei mir aus und damit funktioniert es zumindest:
You cannot view this attachment.

System > Gateways > Configuration:
Interface: WAN
Address Family: IPv6
IP Address: fe80::1
Upstream Gateway: enabled
Far Gateway: enabled

Interface: WAN
Address Family: IPv4
IP Address: 203.0.113.65
Upstream Gateway: enabled
Far Gateway: enabled
Disable Gateway Monitoring: enabled


Interfaces > [WAN]:
IPv4 Configuration Type: Static IPv4
IPv6 Configuration Type: Static IPv6

IPv4 address: 203.0.113.108/32
IPv4 gateway rules: 203.0.113.65

IPv6 address: 2001:db8:6b:28e7:1::1/80
IPv6 gateway rules: fe80::1


Interfaces > [LAN]:
IPv4 Configuration Type: Static IPv4
IPv6 Configuration Type: Static IPv6

IPv4 address: 192.168.1.1/24
IPv4 gateway rules: Disabled

IPv6 address: 2001:db8:6b:f300::1/64
IPv6 gateway rules: Disabled


Interfaces > [VPN]:
Identifier: opt1
Device: wg0
Description: VPN


Interfaces > Assignments:
[LAN] - lan - vtnet1
[VPN] - opt1 - wg0
[WAN] - wan - vtnet0

Das dürfte die vollständige Konfiguration sein.

Dann bleibt als nächster Schritt wohl nur noch die Verwendung von VLANs und dann kann ich versuchen die Einrichtung zu automatisieren.

[Basiskonfiguration]

Basiskonfiguration

Gut, dann muss ich das jetzt Schritt für Schritt aufbauen.
Ich nehme vmbr0 für das WAN und vmbr1 für das LAN:

Code Select Expand

auto lo
iface lo inet loopback
iface lo inet6 loopback

auto enp9s0
iface enp9s0 inet manual
        hwaddress ether 02:11:22:33:44:55

# WAN
auto vmbr0
iface vmbr0 inet manual
        bridge-ports enp9s0
        bridge-stp off
        bridge-fd 0
        bridge-wait 0
        bridge-mcsnoop 0

iface vmbr0 inet6 static
        # WAN IPv6 rescue address
        address 2001:db8:6b:28e7:0001::2/128
        gateway fe80::1

# LAN
auto vmbr1
iface vmbr1 inet manual
        bridge-ports none
        bridge-stp off
        bridge-fd 0
        bridge-wait 0
        bridge-mcsnoop 0

source /etc/network/interfaces.d/*

(laut Gemini ist
hwaddress ether 02:11:22:33:44:55 die bevorzugte Methode gegenüber
pre-up ip link set dev enp9s0 address 02:11:22:33:44:55

Die OPNsense soll nachher die IPv6 2001:db8:6b:28e7::1/64 erhalten.

Für Proxmox verwende ich die IPv6 2001:db8:6b:28e7:0001::2/128,
da die OPNsense immer die ::1 bekommt, nehme ich immer die ::2 für Proxmox.
Die 0001 kommt dazu, damit sich das Proxmox-Subnetz 2001:db8:6b:28e7:0001::/80 vom OPNsense-Subnetz 2001:db8:6b:28e7:0000::/80 unterscheidet.
Die /128 soll anzeigen, dass es sich hier um die feste Rescue-IP handelt.
)

So lange ich in Proxmox bei den VMs keine Network Devices angelegt habe, ist ausschließlich die statische IPv6 definiert.
Die statische IPv6-Adresse ist an die vmbr0 gebunden.
Die vmbr0 verwendet die physische Schnittstelle enp9s0 mit der gespooften MAC.
Also kommt der gesamte Netzwerkverkehr dieser IP über die gespoofte MAC.

Warum akzeptiert Hetzner an dieser Stelle die gespoofte MAC-Adresse?
Oder dauert es einfach nur, bis sie sich beschweren?


Splitten der Netzwerkkonfiguration
(Zur Vermeidung von MAC-Abuse)

In Proxmox bekommt die OPNsense-VM folgende Network Devices:
Network Device (net0): virtio=(reale MAC),bridge=vmbr0
Network Device (net1): virtio=(random MAC),bridge=vmbr1

Sobald ich das Network Device (net0) mit der realen MAC anlege und mit der vmbr0 verbinde (und nachdem ich das WAN-Interface in der OPNsense konfiguriert habe), sendet die OPNsense die IPv4-Pakete doch mit der realen MAC, während Proxmox für IPv6 die gespoofte MAC verwendet.
Ich gebe dem WAN (vtnet0), also net0,vmbr0 - die IP 203.0.113.112/32.

An dieser Stelle habe ich nun das MAC-Abuse Problem.


Das bedeutet: Ich muss die OPNsense korrekt konfigurieren, bevor ich sie mit dem WAN verbinde.

Ich habe also erstmal die hwaddress ether 02:11:22:33:44:55 auskommentiert und in der OPNsense das WAN-Interface deaktiviert.

Doch bleibt hier für mich die Frage, wenn ich für die Rescue-Konfiguration sowieso die /etc/network/interfaces anpassen muss, dann kann ich ja auch gleich eine richtige Trennung vornehmen. Dabei geht nur die IPv6 auf Proxmox, denn die IPv4 würde damit kollidieren, dass sie ja auf der OPNsense definiert ist. Die Bridges vmbr0 und vmbr1 würden vom Netz getrennt sein (bridge-ports: none), so dass keine MAC-Adresse an das Hetzner-Gateway leaken:

Code Select Expand

auto lo
iface lo inet loopback
iface lo inet6 loopback

auto enp9s0
iface enp9s0 inet6 static
        address 2001:db8:6b:28e7:1::2/128
        gateway fe80::1

# WAN
auto vmbr0
iface vmbr0 inet manual
        bridge-ports none
        bridge-stp off
        bridge-fd 0
        bridge-wait 0
        bridge-mcsnoop 0

# LAN
auto vmbr1
iface vmbr1 inet manual
        bridge-ports none
        bridge-stp off
        bridge-fd 0
        bridge-wait 0
        bridge-mcsnoop 0

source /etc/network/interfaces.d/*

Um die OPNsense scharf zu schalten, wäre es dann die folgende Konfiguration (ohne die IPv6-Rescue Adresse):

Code Select Expand

auto lo
iface lo inet loopback
iface lo inet6 loopback

auto enp9s0
iface enp9s0 inet manual
        hwaddress ether 02:11:22:33:44:55

# WAN
auto vmbr0
iface vmbr0 inet manual
        bridge-ports enp9s0
        bridge-stp off
        bridge-fd 0
        bridge-wait 0
        bridge-mcsnoop 0

# LAN
auto vmbr1
iface vmbr1 inet manual
        bridge-ports none
        bridge-stp off
        bridge-fd 0
        bridge-wait 0
        bridge-mcsnoop 0

source /etc/network/interfaces.d/*


In der MAC-Abuse Konfiguration habe ich nach einiger Zeit die Verbindung zum Proxmox verloren. Hat Hetzner hier den Traffic gestoppt?


SSH-Tunnel zur OPNsense GUI

Um die OPNsense GUI von meinem PC aus erreichen zu können, setze ich:

Code Select Expand

iface vmbr1 inet static
        address 192.168.1.2/24
Hier die vollständige /etc/network/interfaces (Setup/Rescue-Konfiguration) nach diesem Schritt:

Code Select Expand

auto lo
iface lo inet loopback
iface lo inet6 loopback

auto enp9s0
iface enp9s0 inet6 static
        address 2001:db8:6b:28e7:1::2/128
        gateway fe80::1

# WAN
auto vmbr0
iface vmbr0 inet manual
        bridge-ports none
        bridge-stp off
        bridge-fd 0
        bridge-wait 0
        bridge-mcsnoop 0

# LAN
auto vmbr1
iface vmbr1 inet static
        address 192.168.1.2/24
        bridge-ports none
        bridge-stp off
        bridge-fd 0
        bridge-wait 0
        bridge-mcsnoop 0

source /etc/network/interfaces.d/*


Mit ssh -i ~/.ssh/hetzner_key -L 8443:192.168.1.1:443 root@2001:db8:6b:28e7:1::2 bekomme ich die Fehlermeldung:

Code Select Expand

root@proxmox:~# channel 2: open failed: connect failed: No route to host
Das Problem tritt auf, sobald ich die /etc/network/interfaces anpasse und mit

Code Select Expand

root@proxmox:~# systemctl restart sshd neu starte.

Ich muss dann über die Proxmox GUI bei den VMs (100 OPNsense und 101 Ubuntu) die Network Devices, die mit der Bridge vmbr1 verbunden sind, entfernen und neu hinzufügen. Danach funktioniert der Tunnel und ich kann im Browser unter https://localhost:8443/ auf die OPNsense GUI zugreifen.
Das hilft mir bei der Einrichtung des Wireguard-Tunnels, da ich so die Keys mittels copy & paste zwischen OPNsense und dem Wireguard Client übertragen kann.



Aber: Manuelle Schritte wie das Anpassen der Network Devices über die GUI verhindern die Automatisierung. Wie kann ich die Network Devices automatisiert entfernen und wieder hinzufügen?

Laut Gemini wird durch den Neustart des Netzwerkdienstes die virtuelle Bridge vmbr1 kurzzeitig deaktiviert und dann reaktiviert und somit die Verbindung zwischen der virtuellen Bridge (vmbr1) und den virtuellen Netzwerkadaptern der laufenden VMs (die Hot-Plug/Hot-Unplug benötigen) unterbrochen.

Beim Reaktivieren der Bridge wird die Verbindung zu den virtuellen Interfaces der laufenden VMs (wie net1) nicht immer korrekt wiederhergestellt oder das Gastsystem bemerkt die Änderung nicht zuverlässig. Das Hot-Plug/Hot-Unplug zwingt das QEMU-System, die Verbindung aktiv zu trennen und neu aufzubauen, wodurch das Gastsystem die Schnittstelle als neues Gerät erkennt und sie korrekt neu initialisiert.

Auf der OPNsense ist net0 mit vmbr0 verbunden und net1 mit vmbr1:

Code Select Expand

qm set 100 -delete net1
qm set 100 -net1 virtio,bridge=vmbr1
Die MAC-Adresse könnte ich auch festlegen:

Code Select Expand

qm set 100 -net1 virtio=00:11:22:33:44:55,bridge=vmbr1Gemini rät dazu bei der selben MAC-Adresse zu bleiben, da die OPNsense die Schnittstelle sonst als neues Gerät behandeln könnte, wodurch die Netzwerkeinstellungen verloren gingen. Das konnte ich für net1 jedoch nicht beobachten, was aber auch daran liegen kann, dass die 192.168.1.1/24 die Standardeinstellung auf dem LAN-Interface ist.


WireGuard einrichten
Da das physische Netzwerkinterface nicht an die WAN Bridge vmbr0 angeschlossen ist, kann ich WireGuard damit verbinden und für die live-Konfiguration vorbereiten. Ich muss nur sicherstellen, dass die Network-Devices neu hinzugefügt werden, sobald ich die /etc/network/interfaces austausche.

VPN > Wireguard > Instances
Neue Wireguard Instanz mit Port 51820, Tunnel 10.0.0.1/24
Save
Apply

Interfaces > Assignments
Assign a new interface - Device: wg0 (WireGuard - VPN), Description: VPN
Save

Interfaces > [VPN]
Enable Interface
Save


Dann bei Firewall > Rules > WAN eine neue Regel:
IPv4, UDP, Destination: WAN address, Destination port range: (other) - 51820, Description: Wireguard incoming
Dann bei Firewall > Rules > VPN eine neue Regel:
Description: Tunnel_To_Any
Dann bei VPN > WireGuard > Instances den öffentlichen Schlüssel kopieren
Dann bei VPN > WireGuard > Peers den öffentlichen Schlüssel vom WireGuard Client einfügen, Zugelassene IPs: 10.0.0.10/24, Instances: VPN
Unter VPN > WireGuard > Instances > VPN bei Peers den WireGuard_Client auswählen. Save.

Im WireGuard Client bei AllowedIPs trage ich das Subnetz vom LAN ein:

[Interface]
PrivateKey = Wird beim Anlegen des Tunnels im WireGuard Client generiert und steht hier schon
Address = 10.0.0.10/32  (IP vom Client, wird hier definiert)
DNS = 1.1.1.1 (hier könnte die IP der OPNsense stehen, aber ich bin mir nicht sicher, ob ich das korrekt eingerichtet habe)

[Peer]
PublicKey = Public Key der WireGuard Instanz der OPNsense
AllowedIPs = 192.168.1.0/24  (IPs der Subnetze der OPNsense)
Endpoint = [2001:db8:6b:28e7:1::2]:51820

Fertige Setup/Rescue-Konfiguration
Das hier ist erstmal die einfachere Konfiguration ohne VLANs und ich hoffe das so korrekt verstanden zu haben. Der Tunnel vom WireGuard Client läuft über das Hetzner Gateway zur physischen Netzwerkschnittstelle. Dort geht es allerdings nicht weiter, da in der Setup/Rescue-Konfiguration die WAN Bridge vmbr0 noch nicht mit der physischen Netzwerkschnittstelle verbunden ist.

You cannot view this attachment.
Nach dem Wechsel auf die Produktivkonfiguration müsste der Tunnel innerhalb der OPNsense von net0 auf wg0 geleitet werden.

Sind meine Überlegungen soweit korrekt?

Dann müsste ich nur noch schauen, wie ich nach dem Wechsel der /etc/network/interfaces die Netzwerkschnittstellen entfernen und neu hinzufügen kann.

Ich habe die /etc/network/interfaces ausgetauscht mit dieser Variante:

Code Select Expand

auto lo
iface lo inet loopback
iface lo inet6 loopback

auto enp9s0
iface enp9s0 inet manual
        hwaddress ether 02:11:22:33:44:55

# WAN
auto vmbr0
iface vmbr0 inet manual
        bridge-ports enp9s0
        bridge-stp off
        bridge-fd 0
        bridge-wait 0
        bridge-mcsnoop 0

# LAN
auto vmbr1
iface vmbr1 inet static
        address 192.168.1.2/24
        bridge-ports none
        bridge-stp off
        bridge-fd 0
        bridge-wait 0
        bridge-mcsnoop 0

source /etc/network/interfaces.d/*
Dann habe ich das komplette System rebootet und hatte danach keinen Zugriff mehr.
Um da wieder drauf zu kommen, habe ich folgendes gemacht:

Code Select Expand

wsl auf meinem Rechner:
ssh -i ~/.ssh/hetzner_key root@2001:db8:6b:28e7::2

ab hier auf dem Rescue-System:
zfs
mkdir -p /mnt/proxmox
zpool import -f -R /mnt/proxmox rpool
nano /mnt/proxmox/etc/network/interfaces
zpool export rpool
reboot
Wie finde ich raus, was schief gelaufen ist?


PS:
Meinst Du mit Lara die KVM-Konsole?

Ist das Netzdiagramm dann so korrekt?
You cannot view this attachment.

Dito für IPv6, nur dass die Netzmaske dort /64 ist und IPs für die VM per SLAAC verteilt werden. Die OpnSense hat auch heine IPv6 aus dem Subnetz, bekommt aber zusätzlich eine VIP mit fe80::1 auf jedem VLAN-Interface, was ich auch als Gateway für das VLAN verwende.

Die OPNsense hat keine IPv6 aus dem Subnetz? Heißt das "vmbr2 inet6 static" hat keine IPv6? Oder bezieht sich das auf die rot markierten VLAN-Schnittstellen?
Die VIP ist eine virtuelle IP für den Betrieb einer zweiten OPNsense als Backup? Bevor ich das einrichte, bräuchte ich da nicht erstmal EINE funktionierende OPNsense? Im Zweifel könnte ich ja einen ZFS-Snapshot erstellen und das komplette System auf diesen Punkt zurückrollen. Das wäre für den Anfang doch die einfachste Lösung.



Um Wireguard einzurichten (nach https://www.youtube.com/watch?v=XE_xfcCLHUw), würde ich doch erst unter VPN > Wireguard > Instances eine Wireguard Instanz anlegen (z.B. Port 51820, Tunnel 10.0.0.0/24). Dann bei Interfaces > Assignments Wireguard als neues Interface hinzufügen und dann bei Interfaces > [VPN] aktivieren. Dann bei Firewall > Rules > WAN eine neue Regel:
IPv4, UDP, Destination: WAN address, Destination port range: (other) - 51820, Description: Wireguard incoming
Dann bei Firewall > Rules > VPN eine neue Regel:
Description: Tunnel_To_Any
Dann bei VPN > WireGuard > Interfaces den öffentlichen Schlüssel kopieren
Dann bei VPN > WireGuard > Peers den öffentlichen Schlüssel vom WireGuard Client einfügen, Zugelassene IPs: 10.0.0.11/24, Instances: VPN
Im WireGuard Client bei AllowedIPs würde ich dann das ehemalige LAN-Netzwerk eintragen, welches jetzt nur noch für den Zugriff per WireGuard existiert?

Korrekt. Ich kann damit aus den (V)LANs der VMs heraus IPv6-Konnektivität herstellen.

Ich hatte ursprünglich mal nur ein LAN für alle VMs installiert, das ist nur der Rest davon. Es hatte 192.168.193.1/24 und folglich das entsprechende IPv6-Subnetz. Jetzt verwende ich aber lauter Subnetze von 192.168.194.0/24.

Das hier ist mir noch unklar, ich dachte die VLANs laufen jetzt über die vlanbridge. Ist das LAN-Interface jetzt noch in Gebrauch? Wenn ich Zugriff auf die VMs haben will, müsste ich dann nicht alle IPs im WireGuard Client bei AllowedIPs eintragen?
Die alte Konfiguration wäre dann alle VMs direkt an vmbr2 anzuschließen? Das wäre ja das, was ich ursprünglich geplant hatte, weil es zunächst mal eine einfachere Konfiguration für einen funktionierenden Startpunkt wäre.

Das ursprüngliche Problem bliebe ja noch bestehen, nämlich der Zugriff über IPv4. Dafür würde ich in diesem Szenario dann NAT auf der OPNsense konfigurieren?

Es sei denn, ich gehe über die Proxmox-Konsole der OPNsense in die Shell und konfiguriere den Paketfilter wie folgt:
Code Select Expand

Code Select Expand

pfctl -f - <<EOF
pass in on vtnet0 proto tcp from 10.0.0.1 to (vtnet0) port 443
EOF

Hier war ja mein Problem, dass der Verkehr von WireGuard auf vmbr0 (oder zurück) nicht weitergeleitet wurde, es sei denn ich habe die obige Regel über die Konsole in der OPNsense hinzugefügt, was jedoch nur bis zum nächsten Reboot funktioniert hat.
War der Fehler jetzt das über das WAN-Interface zu probieren und WireGuard sollte lieber über ein dediziertes LAN-Interface laufen? Da ich mit der Regel den Zugriff hatte, hatte ich vermutet, dass es ich es in diese Richtung konfigurieren müsste - nur halt permanent.

Erstmal vielen, vielen Dank für Deine ausführlichen Erläuterungen!

Anhand Deiner Konfiguration habe ich zunächst ein Netzwerkdiagramm erstellt:
You cannot view this attachment.

Beim Routing / bei den IP-Adressen bin ich noch etwas verwirrt.

2aaa:bbbb:cccc:4e8c:4e8c::815/80 ist übrigens die IPv6 des Proxmox, unter der man ihn auch ohne Wireguard/OpnSense erreichen kann. Diese IPv6 ist aus dem /64er Range.

Im Beispiel müsste das Netz von Hetzner die 2aaa:bbbb:cccc:4e8c::/64 sein.
Ich nehme an, dadurch, dass sich das Rescue-Subnetz 2aaa:bbbb:cccc:4e8c:4e8c::/80 vom WAN-Subnetz 2aaa:bbbb:cccc:4e8c:0192::/80 unterscheidet, gibt es keinen IP-Konflikt mit der Konfiguration der OPNsense, obwohl sich alles im selben /64-Block befindet.

2aaa:bbbb:cccc:f600::/56 ist der andere Präfix.

Ist dies das /56-Subnetz, welches für einmalig 17,85 € bei Hetzner eingerichtet wird?
Adressen aus dem Subnetz sehe ich einmal für vmbr2: 2aaa:bbbb:cccc:f600::815/64 und einmal für die VLANs: 2aaa:bbbb:cccc:f640::41/64. D.h. hier werden also öffentlich routbare IPv6 /64 Subnetze an die VMs und an Wireguard verteilt?
Soll hier wirklich ::41 stehen? Ich dachte als Gateway nimmt man bevorzugt die ::1?


Wozu dient eigentlich diese Route?

Code Select Expand

        post-up ip -6 route add 2aaa:bbbb:cccc:4e8c:193::/80 via 2aaa:bbbb:cccc:4e8c:192::1

Das Subnetz ist hier gar nicht definiert, also muss diese Adresse auf der LAN-Schnittstelle der OPNsense definiert werden?

Code Select Expand

iface vmbr2 inet6 static
        address 2aaa:bbbb:cccc:f600::815/64

Hier verstehe ich nicht, warum dann vmbr2 die 2aaa:bbbb:cccc:f600::815/64 bekommt. Ich hätte vermutet, dass die OPNsense eine IPv6 im gleichen Subnetz (2aaa:bbbb:cccc:4e8c:193::/80) bekommen sollte.


Nach der Installation:
Die Rescue-IP wird deaktiviert. (in /etc/network/interfaces auskommentieren)
Jetzt ist die OPNsense mit dem Hetzner Gateway quasi direkt verbunden und der Zugriff auf Proxmox muss über Wireguard erfolgen.

Ich meine mit "das /64" und "dieses Netz" jedesmal dasselbe öffentliche Prefix von Hetzner. Und ob du nun die ::1 auf WAN und die ::2 auf LAN legst, ist doch schnurz, du kannst auch beliebige andere Adressen aus dem /64 benutzen. Entscheidend ist die /128 auf WAN, damit das klappt.

Danke für die Klarstellung!
Im Beispiel könnte die 2aaa:bbbb:cccc:4e8c:4e8c::815/80 also auch eine 2aaa:bbbb:cccc:4e8c:4e8c::815/128 bzw. jede beliebige Präfixlänge > 64 sein?

Mieten muss Du nur zusätzliche IPv4, wenn Du nicht spoofen willst.

Wenn ich keine zusätzliche IPv4 verwenden will, dann muss ich also die MAC-Adresse der physischen Schnittstelle der WAN-Brücke zuweisen und der physischen Schnittstelle eine neue MAC-Adresse zuweisen? Etwa so?

Code Select Expand

auto lo
iface lo inet loopback

iface enp9s0 inet manual
    hwaddress ether 00:11:22:33:44:55

auto vmbr0
iface vmbr0 inet manual
    bridge-ports enp9s0
    bridge-stp off
    bridge-fd 0
    bridge-hwaddr {{ enp9s0.macaddress }}

Du musst keine IPv6 mieten - da ist es nur eine einmalige Gebühr von 15€ zur Bearbeitung. Wenn Du die verschiedenen VMs mit VLANs abtrennen willst, werden diese auch eigene IPv6-Subnetze brauchen. Und SLAAC hat eben immer /64 Bit, anders geht es nicht. Du müsstest sonst alles mit statischen Reservierungen machen - dann kannst Du natürlich dann auch weniger als /64 machen, bei SLAAC geht das aber nicht.

Ich weiß gerade nicht, warum ich die VMs mittels VLANs abtrennen sollte. Die VMs könnten sich doch per SLAAC eigene Adressen aus dem /64 Block generieren. Ansonsten eben zentral per DHCPv6.

Wenn Du Dir die Mühe machst und die Tutorials liest, wirst Du "bridge-mcsnoop 0" ja dort bereits erklärt finden.

Das deaktiviert das Multicast-Snooping, so dass die Brücke alle Multicast-Pakete an alle angeschlossenen Ports weiterleitet, was bei der Fehlerbehebung helfen kann und den Overhead des Snooping-Protokolls einspart - in kleinen Netzwerken wie auf Proxmox kann das effizienter sein und es kann unerwartete Komplikationen bei komplexen Netzwerkkonfigurationen vermeiden.

Bei Hetzner brauchte ich dazu auch noch so etwas, um auch mit IPv6 die MAC spoofen zu können - sonst verliert er nach kurzer Zeit den Neighbor Cache:

Code Select Expand

iface vmbr1 inet6 static
        # WAN IPv6 rescue address
        address 2a01:4f9:xxxx:yyyy:4e8c::815/80
        gateway fe80::1
        post-up ip -6 route add 2a01:4f9:xxxx:yyyy:177::/80 via 2a01:4f9:xxxx:yyyy:176::1
        #post-up ip -6 route add 2a01:4f9:xxxx:yyyy::/64 via 2a01:4f9:xxxx:yyyy:176::1
        post-up /usr/local/sbin/watchdog_ipv6_spoofed_mac_interface start vmbr1 2001:xxxx:xxxx::zzzz
        post-up ip -6 neigh change fe80::1 lladdr xx:5a:yy:zz:6a:d2 nud permanent router dev vmbr1


Ist vmbr1 bei Dir eine WAN-Schnittstelle?
Wie ist dieses Netzwerk denn mit der physischen Schnittstelle verbunden? Ist das Teil der inet-Konfiguration und taucht darum bei inet6 nicht auf?
Dann bekommt die Bridge eine statische IPv6-Adresse, über die der Verkehr von und zum Hetzner-Gateway fe80::1 läuft?
Pakete an das Gateways werden an die manuell festgelegte MAC-Adresse geschickt, um damit die Verbindungsabbrüche zu verhindern? Hier ist also die MAC-Adresse des Hetzner-Gateways einzutragen?

Das Beispiel soll mir darüber hinaus zeigen, dass man ohne SLAAC den /64-Block in kleinere Subnetze aufteilen kann? Ist die IP der vmbr1 einfach irgendeine öffentliche IP aus dem /64 Block?

Ich kann die Aufteilung des /64-Blocks nicht nachvollziehen. Wie ergibt sich das Gateway 2a01:4f9:xxxx:yyyy:176::1 für den Block 2a01:4f9:xxxx:yyyy:177::/80?
Logisch wäre für mich, dass man z.B. die 2a01:4f9:xxxx:yyyy::1 für den /64-Block nimmt.
Oder die 2a01:4f9:xxxx:yyyy:177::1 für den 2a01:4f9:xxxx:yyyy:177::/80-Block.
Ich bin aber verwirrt, warum hier 2a01:4f9:xxxx:yyyy:176::1 das Gateway ist. Kannst Du mir das Prinzip dahinter erklären?

Ich blicke bei dem Thema noch nicht so ganz durch.

[Es sei denn]

- Das /64 kommt auf ein privates Interface. Bei Deiner OPNsense also z.B. LAN. Wie haben eine private Bridge und hängen da FreeBSD-Jails rein - macht aber keinen Unterschied.
- Dazu weist du dem privaten Interface eine Adresse daraus mit der /64 Prefixlänge zu. Z.B. dead:beef:dead:beef::2/64.

Meinst Du mit "Das /64" den /64-Block von Hetzner?
Das LAN-Interface (vtnet1) ist bei mir verbunden mit der vmbr1.
dead:beef:dead:beef::2/64 wäre bei mir dann also die 2001:db8:6b:28e7::2/64.


Wenn ich die 2001:db8:6b:28e7::2/64 über die OPNsense-GUI beim LAN-Interface zuweise, müsste es doch reichen in der /etc/network/interfaces die vmbr1 wie folgt zu definieren:

Code Select Expand

auto vmbr1
iface vmbr1 inet manual
        bridge-ports none
        bridge-stp off
        bridge-fd 0

- Für WAN nimmst du eine einzelne Adresse aus diesem Netz mit einer /128 Prefixlänge. Ja, das geht. Man darf bei IP nicht dasselbe Netz an zwei verschiedene Interfaces konfigurieren. Es sei denn, man nimmt bei IPv4 /32 und bei IPv6 /128 dazu. Das entspricht einem "ip unnumbered" in Cisco IOS.
- Also auf WAN z.B. dead:beef:dead:beef::1/128.
- Der Defaultgateway ist bei Hetzner immer fe80::1.

Viel Erfolg!

Vielen Dank!
Meinst Du mit "diesem Netz" ebenfalls den /64-Block von Hetzner?
Das WAN-Interface (vtnet0) ist bei mir verbunden mit der vmbr0.
Würdest Du bei der OPNsense auf dem WAN-Interface dann also die 2001:db8:6b:28e7::1/128 verwenden?


Wie sieht es mit der physischen Schnittstelle aus?
Mr_Tom (https://lowendtalk.com/discussion/comment/3272903/#Comment_3272903) hat die 2. Adresse aus dem Subnetz von Hetzner verwendet:

Code Select Expand

iface enp9s0 inet6 static
        address 2001:db8:6b:28e7::2/64
        gateway fe80::1

Den Trick die MAC zu tauschen hatte ich vorher probiert, das sah dann so ähnlich aus wie hier:

Code Select Expand

auto lo
iface lo inet loopback

iface enp9s0 inet manual
    hwaddress ether 00:11:22:33:44:55

# Brücke für die externe Verbindung (WAN)
auto vmbr0
iface vmbr0 inet manual
    bridge-ports enp9s0    # ist das nicht problematisch?
    bridge-stp off
    bridge-fd 0
#    bridge-hwaddr 55:44:33:22:11:00  # (richtige MAC-Adresse via GUI beim Device hinterlegt)

iface vmbr0 inet6 static
    address 2001:db8:6b:28e7::2/64
    gateway fe80::1
    up ip -6 route add 2001:db8:6b:28e7::/64 dev vmbr0

# Brücke für das interne VM-Netzwerk (LAN)
auto vmbr1
iface vmbr1 inet static
    address 192.168.1.2/24
    gateway 192.168.1.1
    bridge-ports none
    bridge-stp off
    bridge-fd 0

source /etc/network/interfaces.d/*
Nach einem Reboot schien jeweils anfangs alles so zu laufen wie gewünscht, allerdings hatte ich dann stets innerhalb von 20 Minuten die Verbindung zum Server verloren. Über KVM Zugriff habe ich dann gesehen, dass der fröhlich weiter lief und sogar ein Ping nach draußen ging.
Ich hatte dann gelesen, dass Hetzner den Zugriff wegen MAC-Abuse sperren würde, wenn mehrere MAC-Adressen auf deren Gateway sichtbar werden (eine entsprechende Mail hatte ich allerdings nicht erhalten) und gedacht, dass ich es vielleicht doch mit dem gerouteten Setup probieren sollte.

Hier habe ich danach noch den Hinweis gefunden, dass auch ein Problem mit NDP vorliegen könnte:
https://forum.proxmox.com/threads/ipv6-neighbor-solicitation-not-forwarded-to-vm.96758/post-461440

Mit mehreren Tagen Spaß habe ich kein Problem, ich hoffe nur dabei auch eine Lösung zu finden. Da das Ganze auf ZFS läuft, kann ich den Server über die Recovery-Konsole zur Not jederzeit zurücksetzen.
Mit den Ansible-Skripten kann ich es dann ja auch relativ schnell wieder auf den alten Stand bringen.
Ich müsste mal schauen, wie man die am besten teilt, dann wäre es vielleicht einfacher gemeinschaftlich so eine Konfiguration hinzubekommen, nur bisher sind da noch meine ganzen Daten drin.


Nginx oder Traeffik als Reverse Proxy wollte ich danach noch installieren, aber so lange ich es nicht mal hinbekomme OPNsense zu verwenden, hilft mir das ja auch nicht weiter. Sollte das Setup bis zu diesem Punkt laufen, könnte ich ja alle Proxys durchprobieren.

Davon abgesehen verstehe ich noch nicht so ganz, warum ein /64-Block bei IPv6 nicht ausreicht.
Angenommen die OPNsense würde per DHCPv6 IPv6-Adressen an alle Geräte im Netz verteilen oder die könnten sich per SLAAC selbst konfigurieren, dann würde doch ein Präfix ausreichen?
Könnte die OPNsense dabei für IPv6 im Bridge-Modus betrieben werden oder lässt Hetzner das wegen MAC-Abuse nicht zu?
Eigentlich hat man bei IPv6 doch einen ganzen /64-Block um diverse Geräte damit betreiben zu können?

Zur Not müsste ich mir tatsächlich noch IPs kaufen. Ich würde es nur gerne erstmal ohne zusätzliche IPs probieren. Vielleicht lerne ich ja etwas dabei.


Mein Problem war jetzt aber eher, dass ich zwar über den Tunnel auf die OPNsense komme, meine dafür notwendige Konfiguration aber nach einem Reboot verloren geht.


Ich wollte IPv6 im Bridged-Modus einrichten und habe dazu zunächst die IPv6 von der OPNsense entfernt und festgestellt, dass der Ping vom Proxmox auf 10.0.0.2 dann nicht mehr funktioniert. Die Konfiguration für IPv4 funktioniert so also gar nicht. Immerhin komme ich noch über eine Ubuntu-VM auf die GUI der OPNsense.

[Action:]

Hallo!


Ich habe mir einen dedizierten Hetzner Server gemietet, per KVM Proxmox (9.0.10) auf zfs-RAID1 installiert und versuche verschiedene VMs zu privaten Zwecken darauf laufen zu lassen und etwas darüber zu lernen. Dabei möchte ich auf den Erwerb zusätzlicher IPs verzichten.

Ich habe gelesen, dass es als MAC-Abuse gilt, wenn andere MAC-Adressen zum Gateway gelangen, ohne dafür eigene IPs zu erwerben. Daher würde ich gerne alles über das Interface vom Proxmox-Server routen.

Die Pakete aus dem Internet sollen über Proxmox an ein virtualisiertes OPNsense geleitet werden und von da aus an die VMs dahinter. Port 22 und 8006 bleiben vorerst auf Proxmox, damit ich auch via IPv4 auf die GUI zugreifen kann.
Für den Fall einer Fehlkonfiguration möchte ich sowohl per IPv4, als auch per IPv6 zugreifen können. Wenn alles funktioniert, würde ich gerne alle Ports auf die OPNsense weiterleiten und via IPv6 auf Proxmox zugreifen.

Wenn das läuft, wären die nächsten Schritte Nginx und AdGuardHome in LXC-Container zu packen und mit dem OPNsense zu verbinden.
Ziel soll es sein, dass die VMs ihre Konfiguration per DHCP bekommen und via Subdomain von außen erreichbar sind. Also sowas wie nextcloud und Bookstack.

(Ich versuche dabei alle Schritte mit ansible zu automatisieren, um ein reproduzierbares Ergebnis zu erhalten.)


Netzdiagramm:

Code Select Expand

                                                                                                 
                              fe80::1                                                            
                                                                                                 
                       Hetzner Gateway                                                           
                        .65 |                                                                    
                            |                                                                    
                            |  203.0.113.0/26           2001:db8:6b:28e7::/64                    
                            |                                                                    
                       .112 |                                                                    
                 +----------|---------+                                                          
                 |                    |                                                          
                 |      Proxmox       |     2001:db8:6b:28e7::2/64                               
                 |                    |                                                          
                 +----------|---------+                                                          
                        .1  |                                                                    
                            |  vmbr0 (WAN/vtnet0)   10.0.0.0/24                                  
                            |                                                                    
                            |                                                                    
                        .2  |                                                                    
               +-------------------------+                                                       
               |                         |                                                       
               |  OPNsense-VM            |                                                       
               |  OPNsense 25.7-amd64    |  2001:db8:6b:28e7::1/64                               
               |                         |                                                       
               +------------|------------+                                                       
                        .1  |                                                                    
                            |                                                                    
                            |  vmbr1 (LAN/vtnet1)  192.168.0.0/24                                
                            |                                                                    
                            |                                                                    
----------|-----------------------------------------------------------------                     
          |                                                                                      
      .2  |                                                                                      
     +----|----+                                                                                 
     |         |                                                                                 
     | VM 101  |                                                                                 
     +---------+    

Ich habe versucht nach der Anleitung https://community.hetzner.com/tutorials/install-and-configure-proxmox_ve/de#25-masquerading-nat von Hetzner vorzugehen. /etc/network/interfaces auf Proxmox:

Code Select Expand

# /etc/network/interfaces
auto lo
iface lo inet loopback

iface lo inet6 loopback

auto enp9s0
iface enp9s0 inet static
        address 203.0.113.112/26
        gateway 203.0.113.65
        post-up  echo 1 > /proc/sys/net/ipv4/ip_forward

        post-up iptables -t nat -A PREROUTING -i enp9s0 -p tcp -m multiport ! --dports 22,8006 -j DNAT --to 10.0.0.2
        post-down iptables -t nat -D PREROUTING -i enp9s0 -p tcp -m multiport ! --dports 22,8006 -j DNAT --to 10.0.0.2

iface enp9s0 inet6 static
        address 2001:db8:6b:28e7::2/64
        gateway fe80::1
        post-up echo 1 > /proc/sys/net/ipv6/conf/all/forwarding

auto vmbr0
iface vmbr0 inet static
        address 10.0.0.1/24
        bridge-ports none
        bridge-stp off
        bridge-fd 0
        post-up   iptables -t nat -A POSTROUTING -s '10.0.0.0/24' -o enp9s0 -j MASQUERADE
        post-down iptables -t nat -D POSTROUTING -s '10.0.0.0/24' -o enp9s0 -j MASQUERADE

#NAT/Masq

auto vmbr1
iface vmbr1 inet manual
        bridge-ports none
        bridge-stp off
        bridge-fd 0

source /etc/network/interfaces.d/*
Port-Forwarding auf Proxmox ist aktiviert:

Code Select Expand

# /etc/sysctl.conf
net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1
Um auf die virtualisierte OPNsense zugreifen zu können (https://localhost:8443), gehe ich über den Tunnel 

Code Select Expand

ssh -i ~/.ssh/hetzner_key -L 8443:10.0.0.2:443 root@203.0.113.112
Bekomme dabei jedoch die Fehlermeldung:

Code Select Expand

channel 3: open failed: connect failed: Connection timed out

Es sei denn, ich gehe über die Proxmox-Konsole der OPNsense in die Shell und konfiguriere den Paketfilter wie folgt:

Code Select Expand

pfctl -f - <<EOF
pass in on vtnet0 proto tcp from 10.0.0.1 to (vtnet0) port 443
EOF
Diese Regel funktioniert aber nur bis zum Neustart der OPNsense, daher habe ich auf Anraten einer KI die folgende Regel über die GUI hinzugefügt:

• Action: Pass
• Interface: WAN
• TCP/IP Version: IPv4
• Protocol: TCP
• Source:
  
  • Type: Single host or network
  • Address: 10.0.0.1/32 (die IP Ihres Proxmox-Hosts auf der vmbr0-Schnittstelle)
• Destination:
  
  • Type: WAN address
• Destination port range:
  
  • from: HTTPS (oder 443)
  • to: HTTPS (oder 443)

Das hat allerdings nicht geholfen und somit muss ich nach jedem Neustart wieder in die Proxmox-Konsole zur OPNsense, um den Paketfilter neu zu konfigurieren.


Wie kann ich es erreichen die OPNsense über meinen Tunnel zu erreichen, ohne den Paketfilter nach jedem Neustart neu zu konfigurieren?