Messages

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?