OPNsense als Router auf Proxmox

CoMo

Commander
Registriert
Dez. 2015
Beiträge
2.937
Hallo,

folgender Plan:

Hetzner Dedicated Server mit Proxmox, darauf OPNSense als VM.

Der komplette Traffic außer SSH und PVE WebUI sollen an die OPNSense genatted werden.

Proxmox und OPNSense laufen und sind erreichbar.

PVE:

Code:
root@virt:~# ip r
default via 88.xx.xx.65 dev vmbr0 proto kernel onlink
10.0.0.0/31 dev vmbr1 proto kernel scope link src 10.0.0.1
10.0.0.2 dev vmbr1 scope link
88.XX.XX.XX/26 dev vmbr0 proto kernel scope link src 88.XX.XX.XX

Die Route ip route add 10.0.0.2/32 dev vmbr1 muss ich nach jedem PVE Reboot händisch hinzufügen.

Code:
root@virt:~# cat /etc/network/interfaces
# 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 enp0s31f6 inet manual

auto vmbr0
iface vmbr0 inet static
        address 88.xx.xx.xx/26
        gateway 88.xx.xx.xx
        bridge-ports enp0s31f6
        bridge-stp off
        bridge-fd 0
        post-up sysctl -w net.ipv4.ip_forward=1
        post-up sysctl -w net.ipv6.conf.all.forwarding=1
        post-up iptables -t nat -A PREROUTING -i vmbr0 -p tcp -m multiport ! --dport 22,8006 -j DNAT --to 10.0.0.2
        post-up iptables -t nat -A PREROUTING -i vmbr0 -p udp -j DNAT --to 10.0.0.2
        post-down iptables -t nat -D PREROUTING -i vmbr0 -p tcp -m multiport ! --dport 22,8006 -j DNAT --to 10.0.0.2
        post-down iptables -t nat -D PREROUTING -i vmbr0 -p udp -j DNAT --to 10.0.0.2

iface vmbr0 inet6 static
        address 2a01:xx:xx:xx::1337/64
        gateway fe80::1

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

auto vmbr1
iface vmbr1 inet6 static
        address 2a01:xx:xx:xx::1338/126
        up ip route 2a01:xx:xx:4255::/64 via 2a01:xx:xx:xx::1339

auto vmbr2
iface vmbr2 inet manual
        ovs_type OVSBridge

source /etc/network/interfaces.d/*

Das post-up scheint schon mal nicht zu funktionieren, jedes mal, wenn ich das Netzwerk neu starte, kommt eine iptables Regel dazu. Lösche ich dann von Hand.

Code:
root@virt:~# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
DNAT       tcp  --  anywhere             anywhere             multiport dports  !ssh,8006 to:10.0.0.2
DNAT       udp  --  anywhere             anywhere             to:10.0.0.2

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  10.0.0.2/31          anywhere

Nun habe ich erst mal das Problem, dass die OPNSense keine IP-Adressen per DHCP vergibt. Außerdem antwortet mir 127.0.0.1, wenn ich was im Internet anpingen will.

OPNSense:

Code:
root@OPNsense:~ # ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.224 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.150 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.140 ms

Code:
root@OPNsense:~ # netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            192.168.0.1        UGS      vtnet1
10.0.0.1           link#1             UHS      vtnet0
10.0.0.2           link#1             UHS         lo0
10.0.0.2/31        link#1             U        vtnet0
127.0.0.1          link#3             UH          lo0
192.168.0.0/24     link#2             U        vtnet1
192.168.0.1        link#2             UHS         lo0

Internet6:
Destination                       Gateway                       Flags     Netif Expire
default                           2a01:xx:xx:xx::1338       UGS      vtnet0
::1                               link#3                        UHS         lo0
2a01:xx:xx:xx::/80            link#2                        U        vtnet1
2a01:xx:xx:xx::1338           link#1                        UHS         lo0
2a01:xx:xx:xx::1339           link#2                        UHS         lo0
fe80::%vtnet0/64                  link#1                        U        vtnet0
fe80::be24:11ff:fec0:7580%vtnet0  link#1                        UHS         lo0
fe80::%vtnet1/64                  link#2                        U        vtnet1
fe80::be24:11ff:fe6d:e56c%vtnet1  link#2                        UHS         lo0
fe80::%lo0/64                     link#3                        U           lo0
fe80::1%lo0                       link#3                        UHS         lo0

Da fehlt jetzt sicher ganz viel an Info, bitte nicht hauen, ich habe mit PFSense / OPNSense bisher noch nicht gearbeitet. Bitte einfach sagen, welche Infos fehlen und wie ich da rankomme, dann liefere ich die nach :)
 
CoMo schrieb:
Die Route ip route add 10.0.0.2/32 dev vmbr1 muss ich nach jedem PVE Reboot händisch hinzufügen.
Die Route 10.0.0.0/31 macht ja auch keinen Sinn - das ist nur Network und Broadcast ohne Hosts.
Damit liegt 10.0.0.2 auch außerhalb des Subnetzes, nur so als Info. Willst du das wirklich? Wenn ja, warum?

CoMo schrieb:
Das post-up scheint schon mal nicht zu funktionieren, jedes mal, wenn ich das Netzwerk neu starte, kommt eine iptables Regel dazu. Lösche ich dann von Hand.
Welche denn? Und wo wir gerade dabei sind: Was sollten die Regeln genau bewirken? Schildere mal, was du dir dabei gedacht hast. Vor allem auch bei der MASQUERADE Regel, die ja nur den Router Host abdeckt, und sonst nichts. Wie hast du dir Trennung von WAN und LAN für die OPNSense vorgestellt? Warum liegt die Default-Route der OPNSense auf den 192er Netz, während doch offenbar das 10er Netz zum Host geht? Wen soll die OPNSense überhaupt mal versorgen? Die anderen VMs? Was genau machen vmbr0, 1 und 2?
 
  • Gefällt mir
Reaktionen: CoMo und Redundanz
riversource schrieb:
Die Route 10.0.0.0/31 macht ja auch keinen Sinn - das ist nur Network und Broadcast ohne Hosts.
Damit liegt 10.0.0.2 auch außerhalb des Subnetzes, nur so als Info. Willst du das wirklich? Wenn ja, warum?

Hm, eigentlich wollte ich ein Netzwerk mit nur 2 Hosts. Eben die 10.0.0.1 (Proxmox) und die 10.0.0.2 (OPNSense). vmbr1 hat die 10.0.0.1 am Proxmox und 10.0.0.2 an der OPNSense. An der OPNSense ist das die WAN-Schnittstelle (vtnet0).

riversource schrieb:
Was sollten die Regeln genau bewirken? Schildere mal, was du dir dabei gedacht hast. Vor allem auch bei der MASQUERADE Regel, die ja nur den Router Host abdeckt, und sonst nichts. Wie hast du dir Trennung von WAN und LAN für die OPNSense vorgestellt?

Jeglicher Traffic, der am Proxmox ankommt, soll per DNAT auf der OPNSense landen. Mit Ausnahme von Port 22 und Port 8006, damit ich den Proxmox selbst noch verwalten kann.

riversource schrieb:
Wen soll die OPNSense überhaupt mal versorgen? Die anderen VMs? Was genau machen vmbr0, 1 und 2?

Ja, alle anderen VMs und Container, die auf dem Proxmox laufen.

vmbr0 war schon nach der Installation vorhanden, da ist einfach nur die Netzwerkschnittstelle des Hosts drin. drin. Das habe ich nicht angefasst.

vmbr1 soll die Bridge zw. Proxmox und OPNSense sein. Das ist vtnet1 auf der OPNSense.

vmbr2 soll die Bridge zw. OPNSense und VMs/Containern sein. OPNSense soll auf der Schnittstelle DHCP zur Verfügung stellen und sich um DNS, NTP etc. kümmern. Dort will ich dann wie bei einem Heimrouter Portweiterleitungen zu den virtuellen Systemen konfigurieren.
 
CoMo schrieb:
Hm, eigentlich wollte ich ein Netzwerk mit nur 2 Hosts
Dafür brauchst du ein /30er Netz. Denk an Network und Broadcast Adresse. Bei /31 sind 10.0.0.0 und 10.0.0.1 in einem Netz, oder 10.0.0.2 und 10.0.0.3. Aber 10.0.0.1 und 10.0.0.2 kriegst du nicht zusammen in ein /31er Netz. Nimm /30, dann hast du Ruhe.


CoMo schrieb:
Jeglicher Traffic, der am Proxmox ankommt, soll per DNAT auf der OPNSense landen. Mit Ausnahme von Port 22 und Port 8006, damit ich den Proxmox selbst noch verwalten kann.
Die entsprechenden Regeln in der INPUT und FORWARD Chain (ohne "-t nat") gibt es auch?

Bleibt die Frage nach der Defaultroute der OPNSense. Und die Proxmox Ports würde ich nur über ein VPN Verfügbar machen, oder über einen SSH Porttunnel. SSH sollte auf einem anderen Port liegen.

Nun korrigiere zunächst mal die Subnetze und die Routen der OPNSense. Dann sehen wir weiter. Und wenn IPv4 dann läuft, ist IPv6 dran.
 
  • Gefällt mir
Reaktionen: CoMo
Also ich bin nun wohl etwas weiter gekommen.

/31 hatte ich mir extra rausgesucht, denn bei einer Punkt-zu-Punkt Verbindung brauche ich ja keine Netzadresse und auch kein Broadcast. https://shellboy.org/2018/05/28/routing-31-die-neue-art-der-transfernetze/

Aber 10.0.0.2 ist wohl in der Tat, wie du korrekt erkannt hast, keine gültige Adresse in dem Netz :)

Also hat der Proxmox jetzt die 10.0.0.0/31 und die OPNsense die 10.0.0.1/31.

Das scheint zu funktionieren. Ich kann in beide Richtungen pingen und auf der OPNSense funktioniert sogar Internet und DNS.

Code:
root@OPNsense:~ # ping computerbase.de
PING computerbase.de (212.83.33.137): 56 data bytes
64 bytes from 212.83.33.137: icmp_seq=0 ttl=58 time=5.970 ms
64 bytes from 212.83.33.137: icmp_seq=1 ttl=58 time=5.984 ms
64 bytes from 212.83.33.137: icmp_seq=2 ttl=58 time=5.920 ms

Code:
root@OPNsense:~ # traceroute computerbase.de
traceroute to computerbase.de (212.83.33.137), 64 hops max, 40 byte packets
 1  10.0.0.0 (10.0.0.0)  0.249 ms  0.141 ms  0.304 ms
 2  static.xx.xx.xx.88.clients.your-server.de (88.99.217.65)  0.509 ms  0.745 ms  0.574 ms
 3  core24.fsn1.hetzner.com (213.239.245.233)  0.692 ms
 [...]


Das NAT funktioniert wohl auch. Ich kann die OPNSense via SSH und HTTPS erreichen. Das muss ja durch das NAT gehen.
Ergänzung ()

Nun bräuchte ich halt noch ein Interface, an das ich meine virtuellen Maschinen hänge, so dass diese per DHCP eine Konfiguration bekommen.
Ergänzung ()

riversource schrieb:
Und die Proxmox Ports würde ich nur über ein VPN Verfügbar machen, oder über einen SSH Porttunnel. SSH sollte auf einem anderen Port liegen.

Also aktuell sind 4 Ports nach außen offen.

Proxmox WebUI
Proxmox SSH

OPNsense WebUI
OPNSense SSH

Letztere beide via NAT durch den Host.

Alles bis aufs Proxmox UI sind zufällige Ports, auf den WebUI's ist 2FA aktiv und SSH geht nur mit Key. Sollte doch erst mal ok so sein oder?
Ergänzung ()

Ok, IPv4 scheint zu funktionieren. Ich habe vmbr2 (Open vSwitch Bridge) an die PFSense attached und nen Debian Container erstellt, der ebenfalls an vmbr2 hängt.

Der Container hat eine IP bekommen, ist online und ich habe gerade erfolgreich eine Portfreigabe auf Port 22 des Containers eingerichtet :)

Dann fehlt jetzt wohl noch IPv6.
 
Zuletzt bearbeitet:
CoMo schrieb:
/31 hatte ich mir extra rausgesucht, denn bei einer Punkt-zu-Punkt Verbindung brauche ich ja keine Netzadresse und auch kein Broadcast. https://shellboy.org/2018/05/28/routing-31-die-neue-art-der-transfernetze/

Aber 10.0.0.2 ist wohl in der Tat, wie du korrekt erkannt hast, keine gültige Adresse in dem Netz :)

Also hat der Proxmox jetzt die 10.0.0.0/31 und die OPNsense die 10.0.0.1/31.
Ja, für solche Zwecke kann man /31er Subnetze verwenden, aber warum so unkreativ? Der in RFC1918 definierte Bereich der privaten IP-Adressen umfasst im 10er Bereich schlanke 16,7 Millionen IP-Adressen und du wählst davon die ersten beiden? Und auch im 192.168er Bereich nimmst du dir gleich das erste /24 Subnetz. Wenn deine OPNsense jemals Kontakt zu anderen Subnetzen haben sollte (zB VPN vom Hotel aus, o.ä.), ist ein Routingkonflikt fast schon garantiert.

Sei kreativ bei der Wahl deiner Subnetze. Es gibt keinen Grund, dich mit den beiden erstbesten IP-Adressen zu begnügen. 10.27.4.90/31 ist technisch nix anderes als 10.0.0.0/31 und auch beim zweiten Subnetz kann man zB 192.168.90.0/24 verwenden. Die Wahrscheinlichkeit eines Konflikts ist dabei verschwindend gering.
Kleiner Trick: Ich wähle meine Subnetze stets anhand von Geburtstagen wie in diesem fiktiven Beispiel eben der 27.4.1990. Alles ist besser als die wohl meistgenutzte IP-Adresse überhaupt, die 192.168.0.1, welche man in einem Großteil der Router als Standard-IP vorfindet und nie geändert wird. Und die 10.0.0.1 steht auf der Liste der meistverwendeten IPs auch ganz weit oben.

Selbst wenn gar kein VPN geplant ist und du nie in eine Konfliktsituation kommen solltest, würde ich diese Regel gründsätzlich immer befolgen, weil es nicht weh tut, einmalig 5 Sekunden über eine Subnetzadresse nachzudenken

Konfliktvermeidung ist besser als Konfliktlösung :schluck:
 
  • Gefällt mir
Reaktionen: h00bi und CoMo
CoMo schrieb:
Also aktuell sind 4 Ports nach außen offen.

Proxmox WebUI
Proxmox SSH

OPNsense WebUI
OPNSense SSH
Zumindest die WebUI Ports würde ich nicht direkt nach außen öffnen, und die SSH Ports nur auf exotischen Portnummern und nur mit Zertifikaten und/oder MFA Authentifizierung.

Bezüglich der IP-Adressen beachte die Hinweise von @Raijin .

CoMo schrieb:
Dann fehlt jetzt wohl noch IPv6.
Die Frage ist, was genau du per IPv6 vorhast. Sollen die Container öffentliche IPs aus dem /64er Subnetz des Servers bekommen?
 
  • Gefällt mir
Reaktionen: Raijin und CoMo
riversource schrieb:
Die Frage ist, was genau du per IPv6 vorhast. Sollen die Container öffentliche IPs aus dem /64er Subnetz des Servers bekommen?

Jap genau das. Ist ja eh alles hinter der OPNSense und ohne entsprechende Traffic Regel nicht von außen erreichbar. Eben dasselbe Konstrukt wie auch bei mir zu Hause mit meinem OpenWrt Router.
 
Ok. Wie handhabt Hetzner das IPv6 Subnetz? Hintergrund der Frage: Bei vielen Anbietern werden solche Netze nicht zum Host geroutet, sondern wie im LAN zur Verfügung gestellt. Sprich, damit die Infrastruktur bei Hetzner die Adresse findet, muss NDP etc. dafür funktionieren. Bei der Adresse auf dem Interface des Hosts ist das einfach, da antwortet der Hosts auf NDP Anfragen. Aber wenn Adressen aus dem Netz virtuellen Maschinen auf dem Host zugeordnet sind, dann antworten die nicht, und man braucht ggf. Klimmzüge wie einen NDP Proxy.

Hat die OPNSense schon eine IPv6? Kannst du die von außen erreichen?
 
Ich habe jetzt folgendes gemacht:

vmbr0 eine statische Adresse (::1337) aus meinem Subnetz gegeben. Funktioniert.
vmbr1 eine weitere Adresse (::1338) aus meinem Subnetz gegeben. Funktioniert.

Beide Adressen lassen sich anpingen und unter der 1337 komm ich auch aufs Proxmox UI.

Wirklich weiter weiß ich gerade noch nicht.
 
CoMo schrieb:
/31 hatte ich mir extra rausgesucht, denn bei einer Punkt-zu-Punkt Verbindung brauche ich ja keine Netzadresse und auch kein Broadcast.
Nimm /30. /31 geht bei mir nur mit pfSense zu pfSense aber schon nicht mehr zu OPNsense und auch nicht zu Proxmox.
Hier wird das nötige NAT für Proxmox (Debian) anschaulich erklärt.
Ergänzung ()

CoMo schrieb:
bitte nicht hauen, ich habe mit PFSense / OPNSense bisher noch nicht gearbeitet.:)
Sehr sportliches Unterfangen. GL
CoMo schrieb:
Das funktioniert doch bereits. Warum sollte ich das bei mir ändern, wenn es bei dir nicht funktioniert? Hä?
Okay, keine Ahnung, wie Du das hinbekommen haben willst, aber ich mach das auch nicht so oft. IPv6 hab ich mir tatsächlich erspart. Hier hat jemand ein Video dazu gemacht. Und sry, nicht alles gelesen.
 
Zuletzt bearbeitet:
Bob.Dig schrieb:
Hier hat jemand ein Video dazu gemacht.

Der hat aber offenbar ein Proxmox hinter einer virtualisierten pfSense. Bei mir ist es eine virtualisierte OPNSense hinter einem Proxmox. Also ein ganz anderer Aufbau.

Ich hab leider immer noch nicht gecheckt, wie ich nun hier routen muss. Ich kann zwar dem VM-Netz auf der OPNSense eine :1339 Adresse geben, die ist aber von nirgends erreichbar.
 
CoMo schrieb:
Ich kann zwar dem VM-Netz auf der OPNSense eine :1339 Adresse geben, die ist aber von nirgends erreichbar.
Ist die Adresse in einem eigenen Subnetz, also hast du das /64 weiter gesplittet? Bei einem Router dürfen WAN und LAN nicht im gleichen Subnetz sein. Entsprechend muss dann eine Route dafür auf dem Host sein, und die Firewall muss die Pakete durchlassen.
 
  • Gefällt mir
Reaktionen: CoMo
Puuh. Ich hab jetzt noch mal alles an IPv6 Config rausgeworfen. Das will nicht funktionieren.

Nehmen wir an, mein Provider hat mir das Netz 2a01:123:123:4255::/64 zugewiesen. Wie sähe eine valide Config aus?
 
riversource schrieb:
Ok. Wie handhabt Hetzner das IPv6 Subnetz? Hintergrund der Frage: Bei vielen Anbietern werden solche Netze nicht zum Host geroutet, sondern wie im LAN zur Verfügung gestellt.
Das habe ich dazu auf die Schnelle gefunden.
In addition to a primary IPv4 address, every servers is assigned an /64 IPv6 subnet. This subnet is routed to the link-local IPv6 address that is generated from the MAC address of the server. As opposed to the IPv4 configuration, no point-to-point configuration is needed for IPv6.
Das Auftrennen des /64 und eine Route setzen könnte demnach erfolgreich sein?
 
  • Gefällt mir
Reaktionen: CoMo
Bob.Dig schrieb:
Das Auftrennen des /64 und eine Route setzen könnte demnach erfolgreich sein?
Ja. Das ist gut und sehr viel einfacher zu handhaben, als die andere Variante.

CoMo schrieb:
Nehmen wir an, mein Provider hat mir das Netz 2a01:123:123:4255::/64 zugewiesen. Wie sähe eine valide Config aus?
Auf dem WAN Interface solltest du eine Adresse aus dem Subnetz einrichten mit Subnetzmaske /64 (z.B. 2a01:123:123:4255::1/64). Eventuell geht auch Subnetzmaske /80, müsste man testen. Dann splittest du das Netz weiter auf, z.B. in /80er Netze, also z.B. 2a01:123:123:4255:1::/80, 2a01:123:123:4255:2::/80, 2a01:123:123:4255:3::/80 usw.

Ein Subnetz nutzt du für die Verbindung zwischen Host und OPNSense. Weise also eine Adresse vmbr1 zu (2a01:123:123:4255:1::1/80) und eine zweite dem WAN Port der OPNSense (z.B. 2a01:123:123:4255:1::2/80). Auf der OPNSense muss außerdem die Default-Route richtig gesetzt werden (via 2a01:123:123:4255:1::1).

Das nächste Subnetz nutzt du fürs LAN der OPNSense (2a01:123:123:4255:2::1/80). Leider kannst du bei Subnetzmasken größer als 64 nicht mehr mit Router Advertisements arbeiten, das geht nur bei /64. Du musst also DHCPv6 nutzen. Der DHCP Pool reicht dann z.B. von 2a01:123:123:4255:2::2/80 bis 2a01:123:123:4255:2::FFFF/80. Das sollte reichen. Für dieses Subnetz muss auch eine statische Route auf dem Host eingerichtet werden (via 2a01:123:123:4255:1::2).

Beachte: Alle Container haben öffentlich erreichbare IPv6 Adressen. Also muss die Firewall entsprechend eingerichtet werden, und zwar schon auf dem Host, nicht erst in der OPNSense! Das geht nicht von allein und muss von Hand gemacht werden.

Wenn du mit RAs arbeiten willst, solltest du dir ein zweites /64 Netz gönnen, fürs LAN der OPNSense.
 
  • Gefällt mir
Reaktionen: CoMo
Danke für die ausführliche Antwort. Ich werde vermutlich erst morgen dazu kommen, das auszuprobieren.

riversource schrieb:
Beachte: Alle Container haben öffentlich erreichbare IPv6 Adressen. Also muss die Firewall entsprechend eingerichtet werden, und zwar schon auf dem Host, nicht erst in der OPNSense! Das geht nicht von allein und muss von Hand gemacht werden.

Das kann ich ja auf dem Proxmox pro Container machen. Aber wäre es nicht sinnvoller, wenn auch das durch die OPNSense geht? Oder ist das nicht machbar?

riversource schrieb:
Wenn du mit RAs arbeiten willst, solltest du dir ein zweites /64 Netz gönnen, fürs LAN der OPNSense.

Hetzner schaltet für einen einmaligen Betrag ein zusätzliches /56 Subnetz auf. Das klingt so, als wäre das sinnvoll und ich sollte das tun?
Ergänzung ()

Ach Router Advertisements sind nötig, damit die Clients sich mittels SLAAC konfigurieren können? So wollte ich das sowieso haben, dann komme ich wohl nicht um das zusätzliche Subnetz herum?
 
riversource schrieb:
Ein Subnetz nutzt du für die Verbindung zwischen Host und OPNSense. Weise also eine Adresse vmbr1 zu (2a01:123:123:4255:1::1/80) und eine zweite dem WAN Port der OPNSense (z.B. 2a01:123:123:4255:1::2/80). Auf der OPNSense muss außerdem die Default-Route richtig gesetzt werden (via 2a01:123:123:4255:1::1).
Mich würde mal interessieren, wie die Regeln/Routen dafür auf dem Proxmox Host aussehen müssen. Wobei mein Anbieter das nicht routet, es wäre also nur aus Neugierde.
Ergänzung ()

CoMo schrieb:
Ach Router Advertisements sind nötig, damit die Clients sich mittels SLAAC konfigurieren können? So wollte ich das sowieso haben, dann komme ich wohl nicht um das zusätzliche Subnetz herum?
SLAAC ist ja nicht unbedingt nötig, aber wenn es tatsächlich günstig zu haben ist, dann auf jeden Fall.
 
So, Hetzner hat mir ein zusätzliches /56 Netz aktiviert und an die Link-Local-Adresse meines vmbr0 geroutet.

Bevor es an die Konfiguration geht (ich habe noch null Ahnung, was zu tun ist), stellt sich die Frage, wie das ganze am Ende aussehen soll. Ich hab sowas mit IPv6 noch nie gemacht.

Ich kann ja jetzt theoretisch 256 /64 Netze bauen.

Ich dachte zunächst an 3 Netze: Eines für den Host (Da tut aber auch eine /128, oder), eines für die vmbr1/vtnet0 (Proxmox <> OPNSense) und eines für die VMs, also vmbr2/vtnet1 (OPNSense).

Die VMs / Container sollen sich via SLAAC selbst eine Adresse konfigurieren. IPv6-Traffic soll aber durch die OPNSense laufen, die sollen also nicht mit nacktem Arsch im Internet hängen.

Oder soll ich gleich jeder VM ein komplettes /64 zuweisen?

Geht das so und macht das Sinn?
 
Zurück
Oben