Firewall-Regel persistieren

[raelianer]

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?

[meyergru]

Der Trick besteht darin, der OpnSense die "offizielle" MAC zuzuweisen und dem Proxmox eine andere, künstliche zu geben.

Dann kann man den Proxmox per IPv6 erreichen (dazu am besten einen - noch für einmalig 15€ bestellbaren - /56er IPv6-Range beantragen), was auch sicherer ist, weil per IPv6 keine Ports-Scans stattfinden.

Ich habe für den "2-IP-Setup" mal eine Anleitung geschrieben, diese basiert auf dem grundsätzlichen Proxmox-Setup - schon das ist nicht trivial.

Trotzdem eine Warnung: Das ist alles andere als einfach, ich kann da außer den bereits beschriebenen Hinweisen kaum konkret helfen. Du hast garantiert mehrere Tage Spaß vor Dir, soviel kann ich Dir aus eigener Erfahrung sagen. Es ist um Größenordnungen einfacher, es mit 2 IPv4 zu machen.

Du hast die komplexeste Variante gewählt, die mir bekannt ist:

1. OpnSense mit Dual-Stack (eh nicht einfach).
2. Wahrscheinlich brauchst Du auch noch einen Reverse Proxy wie HAProxy oder Caddy (dazu gibt es auch Tutorials)..
3. OpnSense unter Proxmox.
4. Betrieb in einem Datacenter, wo zusätzliche Einschränkungen greifen.
5. "Sparversion" mit nur einer gemieteten IPv4, die vorzugsweise der OpnSense-VM gehören sollte, was etliche Trickserei erfordert. Ich mache das zwar auch so - es ist aber, wie gesagt, extrem komplex. Plan schon mal mehrere Stunden Lara ein, wenn Du Dir den Zugang verkonfiguriert hast...

[raelianer]

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.

[Patrick M. Hausen]

Eigentlich hat man bei IPv6 doch einen ganzen /64-Block um diverse Geräte damit betreiben zu können?

Was wir mit FreeBSD (ohne OPNsense) mit dedizierten Servern bei Hetzner tun, ist folgendes:

- 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.
- 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!

[meyergru]

Mieten muss Du nur zusätzliche IPv4, wenn Du nicht spoofen willst. 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.

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

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

Das Skript macht dies:

Code Select Expand

#!/usr/bin/env bash

# check given action

if [[ "${1}" != "start" && "${1}" != "stop" ]]
then
  echo -e "Please call:\n\n\t$(basename ${0}) <start | stop> <device> <target to ping>\n"
  exit 1
fi

ACTION=${1}

# check given network device

if [[ "${2}" == "" ]]
then
  echo "You have to define a network device for watchdog!"
  exit 1
fi

ifconfig ${2} >/dev/null 2>&1

if [[ "$?" != "0" ]]
then
  echo "Device ${2} ist not configured!"
  exit 1
fi

DEVICE=${2}

# define a pid file

NOHUP_PID_FILE="/var/run/$(basename ${0}).${DEVICE}.pid"

# check target address

if [[ "${ACTION}" == "start" && "${3}" == "" ]]
then
  echo "You have to define an IPv6 target to re-open the communication"
  exit 1
fi

NEXTHOP=${3}

# on any action stop existing watchdog

LAST_NOHUP_PID=$(cat "${NOHUP_PID_FILE}" 2>/dev/null)

if [[ "${LAST_NOHUP_PID}" != "" ]]
then
  kill -9 ${LAST_NOHUP_PID} >/dev/null 2>&1
fi

# handle action start

if [[ "${ACTION}" == "start" ]]
then
#  ip -6 neigh change fe80::1 lladdr xx:5a:yy:zz:6a:d2 nud permanent router dev vmbr1
  nohup bash -c 'while true; do sleep 30; ip -family inet6 neigh flush fe80::1; ping6 -c 5 '${NEXTHOP}'; done' &>/dev/null 2>&1 &
  NOHUP_PID=$!

  if [[ "${NOHUP_PID}" == "" || ${NOHUP_PID} -lt 100 ]]
  then
    echo "Failed! Could not start the watchdog!"
    exit 1
  fi

  echo -e "$NOHUP_PID\c" > "$NOHUP_PID_FILE"
fi

exit 0


[meyergru]

Geroutet sind die Interfaces immer, auch bei IPv6. Hetzner reagiert auch komisch, wenn sie mehrere MACs sehen:

https://lowendtalk.com/discussion/173677/mac-address-abuse-message-from-hetzner

[raelianer]

- 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

[raelianer]

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.

[Patrick M. Hausen]

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.

Zu Proxmox kann ich leider nichts sagen, ich virtualisiere OPNsense nicht.

[meyergru]

Ich kann Dir nur raten, die Anleitung genau durchzulesen. Was ich nicht leisten kann, ist, Dein Verständnis Schritt für Schritt mit der Anleitung abzugleichen, oder alle potentiellen Freiheitsgrade durchzugehen. Ich beschreibe, wie ich es mache und warum. Den Rest musst Du selbst tun.

Deswegen schrieb ich: Das ist hochkomplex und Du wirst ein paar Tage Spaß damit haben.

Zur Erläuterung hier meine /etc/network/interfaces, wo die Fake-MAC eingetragen wird:

Code Select Expand

# network interface settings; autogenerated
# Please do NOT modify this file directly, unless you know what
# you're doing.
#
# If you want to manage parts of the network configuration manually,
# please utilize the 'source' or 'source-directory' directives to do
# so.
# PVE will preserve these directives, but will NOT read its network
# configuration from sourced files, so do not attempt to move any of
# the PVE managed interfaces into external files!

auto lo
iface lo inet loopback
iface lo inet6 loopback

# WAN NIC
# ----------
# The default ether of the physical NIC is melted / dongled
# to the provider switch. For bridge mode, the NIC will get
# a generated MAC address. The physical MAC address can be
# used in the OpnSense firewall VM.
#
iface eth0 inet manual
        # Physical NIC gets a faked MAC. It can only be used for IPv6.
        pre-up ip link set dev eth0 address 02:11:22:33:44:55


# LAN IPv4 - internal network
# ----------
# Bind and access the management interface. This will be accessed via Wireguard.
#
auto vmbr2
iface vmbr2 inet static
        # LAN IPv4 address
        address 192.168.193.2/24
        gateway 192.168.193.1
        dns-nameservers 192.168.193.1
        bridge-ports none
        bridge-stp off
        bridge-fd 0
        bridge-wait 0
        bridge-mcsnoop 0
        post-up ip route add 192.168.0.0/16 via 192.168.193.1 dev vmbr2

iface vmbr2 inet6 static
        address 2aaa:bbbb:cccc:f600::815/64
        # No gateway, this will only be done via Wireguard!
        #gateway fe80::1



# WAN bridge
# ----------
# This interface belongs to the OpnSense Firewall VM ONLY!
# It has to set the physical MAC of the machine, but it has to do it by itself!
#
auto vmbr1
iface vmbr1 inet manual
        # WAN bridge physical interface
        bridge-ports eth0
        bridge-stp off
        bridge-fd 0
        bridge-wait 0
        bridge-mcsnoop 0
        ##post-up ip link set dev vmbr1 address 11:77:66:44:33:ee


# WAN IPv6 RESCUE
# ----------
# Should be ONLY ENABLED for RESCUE or INSTALLATION.
# Local firewall rules to accept ICMPv6 and SSH only.
# ATTENTION - disable `vmbr0 inet6` when using `vmbr1 inet6`
#
iface vmbr1 inet6 static
        # WAN IPv6 rescue address
        address 2aaa:bbbb:cccc:4e8c:4e8c::815/80
        gateway fe80::1
        post-up ip -6 route add 2aaa:bbbb:cccc:4e8c:193::/80 via 2aaa:bbbb:cccc:4e8c:192::1
        post-up /usr/local/sbin/watchdog_ipv6_spoofed_mac_interface start vmbr1 2001:4860:4860::8888
        # This is the gateway MAC!
        post-up ip -6 neigh change fe80::1 lladdr d4:5a:3f:73:6a:d2 nud permanent router dev vmbr1


auto vlanbridge
iface vlanbridge inet manual
        bridge-ports none
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094
        bridge-mcsnoop 0
        bridge-wait 0
#VLAN bridge


source /etc/network/interfaces.d/*

Tipp: Sichere Dir vorher eine "normale" /etc/network/interfaces, die Du benutzen kannst, wenn Du diese vergurkst. Um die Lara kommst Du trotzdem nicht rum - ich habe es jedenfalls nicht geschafft.

vmbr1 ist die WAN-Bridge, die nur eth0 mit der Fake-MAC für IPv6 auf Proxmox und dem WAN-Interface der OpnSense mit der "echten" MAC beinhaltet.
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. 2aaa:bbbb:cccc:f600::/56 ist der andere Präfix. In der OpnSense ist das dann so:

You cannot view this attachment.

vmbr2 ist eine virtuelle Bridge, die zum Zugriff auf die VMs dient. Diese ist VLAN-aware, damit man die einzelnen VMs trennen kann. Ich mache das so mit eine Segmentierung auf IPv4 in lauter /30er Netze und entsprechenden VLANs. Per IPv6 mache ich das logisch genauso, mit /56 ist das halt bequemer:

You cannot view this attachment.

Den /64er Range zerteile ich in /80er, aber nochmal: Nicht für SLAAC, das setzt zwingend /64 voraus, sondern per statischer Konfiguration. Diesen benutze ich für die Adressierung des Proxmox und der OpnSense für Routing und zum Notfall-Zugriff. Wie Du das machst, ist Geschmackssache. Den eigentlichen für die VMs genutzten /56er Range nutze ich nur dort - die OpnSense und der Proxmox sind in einem anderen Range und werden damit so gut wie möglich verborgen. Ich kann auch nur dazu raten, insbesondere die Proxmox-IPv6 auch DNS-technisch und ggf. für Zertifikate nicht aus Versehen offenzulegen, mehr dazu hier:
https://forum.opnsense.org/index.php?topic=45822.msg229299, Punkt 5c.

Am Rande: 192.68.193.0/24 ist die Parent-VLAN-Bridge, tatsächlich werden aber die einzelnen VLANs unter 192.168.194.xxx/30 hergenommen. Bei einem etwaigen Einbruch sind die VMs also alle voneinander durch die OpnSense abgeschottet, sonst kann man sich die Firewall ja gleich schenken. In den VMs trage ich dann also nur die vmbr2 mit einem dedizierten VLAN ein, der Zugriff von außen erfolgt nur per HAproxy. Dies ist auch der Grund für die eventuell "seltsam" anmutendende IPv6 des Proxmox mit 2aaa:bbbb:cccc:4e8c:4e8c::815 - Du kannst jeden beliebigen 64-Bit-Suffix wählen, ich wollte ihn nur nicht so leicht zu erraten machen.

Und hier die VM-Definition (dort und nirgends sonst wird die physische MAC der Maschine eingetragen):

You cannot view this attachment.



Wie gesagt, um das Konzept rund zu machen, brauchst Du dann noch Wireguard, um von zu Hause auf das 192.168.194.0/24 zu kommen und HAproxy (es gibt ein exzellentes Tutorial von TheHellSite dazu) für den Zugriff von außen. Auch hier hast Du Freiheitsgrade, z.B. OpenVPN, IPsec oder Nginx bzw. Caddy.

[raelianer]

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?

[meyergru]

Was die Grafik angeht: Die VLAN-Interfaces der OpnSense müssen jeweils einzelne IPv4 aus dem jeweiligen VLAN-Subnetz bekommen, die VM dann die andere. Beispielsweise: 192.168.194.40/30 wäre die OpnSense die .41 und die VM die .42. Insofern ist in jedem VLAN nur eine VM, nicht drei (ginge mangels IPv4 bei /30 auch gar nicht, denn die erste und letzte IP jedes Subnetz verwendet man nicht).

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.

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?

Ja und ja.

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?

Das kannst Du halten wie ein Dachdecker. Ich nehme als Gateway zusätzlich immer fe80::1, auf den verschiedenen VLAN-Interfaces.
Wie gesagt, ich will die IPv6 möglichst nicht offen handeln, was sich nicht immer vermeiden lässt (beispielsweise bei Routern und Webservern).

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.

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.

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.

Normalerweise ja, aber siehe:

Code Select Expand

        # WAN IPv6 rescue address
        address 2aaa:bbbb:cccc:4e8c:4e8c::815/80

Ich schrieb ja auch schon, dass man insbesondere diese IPv6 nicht offenlegen will. Zusätzlich kann man noch die Firewall des Proxmox dazu nutzen, nur den SSH-Port zu öffnen, weil die Web-UI eher anfällig für Angriffe ist.

Du willst ja nicht davon abhängig sein, dass Deine OpnSense auch läuft und funktioniert. So kann ich immer noch auf den Proxmox und nötigenfalls eine Backup-OpnSense starten. Ich habe ein Skript, dass die Produktions-OpnSense auf die Backup-OpnSense klont. Die kann ich dann im Notfall per SSH starten, ohne eine Lara zu benötigen.

Code Select Expand

#! /bin/sh

SRC=102
DST=103
STORAGE=storagebox
NAME=sense-fallback
TMP=/tmp/xxx$$

vzdump $SRC --storage $STORAGE --compress zstd --notes-template $NAME | tee $TMP

FILE=$(sed -E "s/.*?INFO: creating vzdump archive '(.+?)'.*/\\1/g" $TMP | grep -v '^INFO:')

rm -f $TMP

qm set $DST --protection 0
qmrestore $FILE $DST --force 1
qm set $DST --name $NAME --onboot 0 --tags donotstart,lan,vlan,wan


[raelianer]

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.