Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - JoeB

#1
Tja, Alter schützt vor Dummheiten nicht.
:-\ :-[ ::)
Ich denke, die Diskussion hat in der Tiefe dem Forum etwas gebracht.

Wiewohl man gern mal etwas schnippisch hier ist. So als "Newbie", mhe.
Das bringt aber keine Karma - Punkte....., gell.

Interessant zum Thema "Virtualisierung OPNsense" finde ich noch das Thema "Serielle Konsole".

Es ist ja so, OPNsense wird wohl über die GUI administriert. Aber wie mach ich das, wenn
OPNsense "entfernt" als eine VM installiert wird und dort das routing sofort übernimmt?

Ich habe von Proxmox aus eine Verbindung aus der Konsole ( Pveproxy ist ja erst einmal nicht erreichbar )
mit "qm terminal <VMID>" eine Konsolenzugang zu OPN hergestellt.

Dazu ist es aber notwendig, dass man nach der "Erstinstallation" vor dem boot, in OPN
die Verbindung über <serialspeed> und <primaryconsole>serial <secondaryconsole>video
einträgt.

Ich habe es versucht, mit dem serial - image OPNsense zu installieren; aber image lässt sich nicht auf eine
proxmox als bootmedium darstellen. Mein Versuch, das image in iso zu verwandeln, schlug aber fehl.

War mir dann auch erst einmal zu aufwendig. Deshalb der Umweg, die serielle Konsole selbst einzutragen.

JoB




#2
Danke.
Prost.
Habe auch nur auszugsweise aus dem Wiki von Proxmox zitiert. Weiß ich.

Ich habe "alle" Wikis gelesen in den 2 Wochen.
Und ganz zu Anfang bin ich auf eine komplette russische Anleitung und Howto gestossen.
Da gab es ganz viele tolle Parameter für grub:
pci=noaer
pci=nomsi


damit auch alle Kompatibiltätssorgen gelöst wären.

Was war bei mir letztendlich der Fehler: genau die 2 Parameter - die braucht bei mir mal kein Mensch.
lediglich intel_iommu=on.

Da hab ich mir mal gedacht: siehste, hättest dir einfach keinen Kopf gemacht und das erst beste Wiki genommen.

Aber nein, Gut gemeint, ist halt nicht gut gemacht. !

Jetzt geht der Teil ja.


mfg

JoB
#3
Verwendst Du die Hetzner Firewall ? ( evtl. mal ausschalten : robot.your-server.com, Server -> Firewall )

Kannst Du einen externen NameServer anpingen ?
-> am besten auf der Konsole von OPN

( Bsp. 8.8.8.8, 213.133.100.100 )

Hast Du auf der Konsole von OPNsense mit nslookup geprüft ?



#4
Hallo MicNeu,

ich administriere Linux  / Unix Systeme schon seit 25 Jahren.
Alles was es gibt und gab. SuSe / SCO Unix / RedHat / Ubuntu / FreeBsd / Next  etc.
Bis vor 5 Jahren hauptberruflich, heute noch projektbezogen.
Bin aber jetzt bei Debian angekommen und geblieben.
Natürlich kann man nicht alles wissen. Bevor ich mich hier an das Forum gewendet habe, sind mindestens 3 Nächte draufgegangen. Und man beginnt an allem zu zweifeln. Bekannte Grundzüge von Linux funktionieren einfach nicht mehr. Na wenn die "Hardware" aber auch defekt ist.

Habe aber beschlossen, mich etwas in diesen Foren einzubringen. Wiewohl ich mit der Art der Anfrage manchmal nichts anfangen kann. Weil die oben genannten Basics fehlen.
Außerdem denke ich, dass die beste Lösung für das eigene Verständnis, selbst gelöste Rätsel sind.
Aber wenn man natürlich nach doch tieferer Vorarbeit immer noch auf dem Holzweg ist, auch nach Rat und Tat fragen kann. Dann könnte die Vorarbeit und die Lösung allen etwas bringen.


#5
Proxmox-Forum: Habe ich gepostet.

OPNsense nicht das Problem: generell richtig.

Wiewohl ich mir gewünscht hätte, das vielleicht Tips zur Prüfung der vollen Funktionsfähigkeit der NIC unter FreeBSD dabei sein könnten.
Ich erwarte nicht, dass jemand mir Taste für Taste diktiert ( mache ich übrigens auch nicht ); wobei Hinweise
für Möglichkeiten von Fehlern und deren Testings mir sehr willkommen sind.

Aber ich habe ja auch nicht mit allem Erfahrung. Insoweit habe ich auf die kollektive Intelligenz von Vielen gehofft.


Vielleicht haben wir eines aus diesem Thread mitgenommen:

Hardware muss nicht immer fehlerfrei funktionieren, nur weil ein Treiber geladen wurde.
Das Misstrauen gegenüber dem Computer muss wieder früher beginnen.
Was man nicht getestet hat ( Basis, Schritt für Schritt) darf man nicht einfach als Voraussetzung annehmen.

Deshalb bei Schnittstellen - Problemen schon im Bereich Hardware (Layer0), Treiber (layer1) Test der angebotenen Funktionen des Treibers prüfen (layer2). Erst wenn dies "abgesichert" ist, in Layer3 gehen - Protokolle bzw. API.

Aber tatsächlich ist es so, dass mir meine schriftliche Formulierung der Aufgabe hier im Board sehr geholfen hat:
Damit meine ich:

Strukturiert Anderen beschreiben, was vorhanden ist:
a) Ziel
b) vermeintlicher Fehler
c) Konfiguration
d) Ergebnisse von Tests
e) bisher gefundene Docus
d) Interpretation aus vorherigen Schritten


Können wir uns darauf einigen ?


#6
Hallo erstmal,
das Problem ist wohl gelöst.

Die Anleitung von OPNSense über PCI_passthrough in der VM ist nicht vollständig.
Wichtige Teile fehlen, so das man wohl Support braucht.
Ich bin dankbar, dass ich das hier aufschreiben durfte, dadurch wurde mir klar
"I'm on the woodway"
Es scheint hier zu sein, wie vermutet.
Wenn man neu ist im Forum, bekommt man keine Antworten bzw. evtl noch Mitleid zu Themen, die nicht
im WebGui zu "klicken" sind. Ist wie bei Windows. Konsole kann dort auch keiner mehr.

Schliesslich gibt es, wie an anderer Stelle im Forum vermerkt, ja noch den bezahlten Support.
Was soll der noch lösen, wenn doch die Lösungen im Forum schon verteilt sind.
Es ist so wie mit manch anderer Opensource Software.
Wie Radio Eriwan beginnt: "Im Prinzip ja, aber .....".
Out of the Box funktioniert es eben nur für Triviales, Spezielles sollte bitteschön bezahlt werden.


Aber hier für diejenigen, die Lösungen suchen:

https://github.com/yoonsikp/macos-kvm-pci-passthrough/blob/master/README.md

beschreibt es ganz gut. Große Bedeutung kommen den Parametern beim laden von vfio_pci zu.
(vfio_pci ids=8086:15b7).

und wenn es gar nicht funktionieren will
blacklist <Driver>




#7
Hallo erstmal



Neuer Tag neues Glück.

Ich habe die Nacht verwendet, um den Fehler zu suchen.

Ob ich ihn gefunden habe, bin ich mir nicht sichre.



Ich habe gedacht - jetzt ist es egal. Ich installiere OPNsense direkt auf der MAschine. das müsste doch schliesslich gehen.

Also habe ich eine KVM beantragt und das ISO eingebunden und mit dem OPNsense image gebootet.

Jetzt gibt es ja die Möglichkeit, vom Live system aus OPN zu "betreiben".

Es geschah merkwürdiges.

1. OPNsense hat vom DHCP eine Adresse zugewiesen bekommen -> das gab es als VM mit PCI Passthrough noch nie.

2. es funktionierte - Ich hatte Zugriff auf OPNsense.



Na, dachte ich, vielleicht haben die von Hetzner mich ja erhört und etwas geändert in Ihrer Router Konfiguratiion.

Also wieder mit Proxmox gebootet und VM PCI "durchgereicht" - und nichts funktionierte mehr.



Eines fiel mir aber auf: ( aus der Erinnerung vielleicht nicht sauber wieder gegeben );

Während OPN-solo im Live mode gebootet hat, meldete plötzlich der Netzwerk-Adapter: "Going down".

Jetzt könnte das ja normal sein, aber eine derartiege HArdware - Response Meldung bekam ich im VM Modus nie.



Natürlich habe ich die Routen zwischen VM Mode und Live - Mode verglichen. Die waren jetzt wirklich identisch ( bis auf die route zu den DENS Servern )

Im Life Mode konnte ich von OPN das Gateway pingen, im VM Mode erschien: HOST is down:



Ich nehme die Meldung jetzt einfach mal ernst: HOST is DOWN: Bedeutet für mich: HOST ist ausgeschaltet. Ist er natürlich nicht, was nur heißen kann, die NIC meldet dies an

OPN so weiter bzw. mangels wirklicher Antwort von der NIC sit für OPN der hsot wirklich down.



Das kann ja sein, wenn die NIC nicht sauber durchgereicht wird ( IRQ share etc. ).



Hat jemand Erfahrung mit PCI Passthrough und

05:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)

Subsystem: ASUSTeK Computer Inc. I210 Gigabit Network Connection

Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-

Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

Latency: 0, Cache Line Size: 64 bytes

Interrupt: pin A routed to IRQ 16



auf proxmox ?

Offensichtlich reicht die Anleitung von Proxmox für diese Thema (Konfiguration ) nicht aus.

da steht nämlich nichts von so Dingen wie

/etc/modprobe.d/vfio.conf
options vfio-pci ids=8006:1553
/etc/initramfs-tools/modules
vfio
vfio_iommu_type1
vfio_virqfd
vfio_pci ids=8086:1533

/etc/modprobe.d/igb.conf
blacklist igb


Ich glaube, da fehlt etwas in der Konfiguration von PVE, damit die NIC sauber und fehlerfrei durchgereicht werden kann.



Leider bin heute morgen um 6.00 Uhr dann mit dem Kopf auf der Tastatur aufgeschlagen ...

Nein, Hetzner brauchte die KVM wohl wieder und ich hatte von dieser Session ja erst mal genug.



Ich dachte auch, muss da mal in Ruhe drüber nachdenken und ein bisschen Erfahrungen austauschen ....

#



Gruß Joe
#8

in Proxmox unter /etc/pve/qemu-server/<VM-ID>.conf
serial0: socket hinzufügen ( geht auch über proxmox 5.3/5.4 WEBGUI <VMID> ->Hardware->hinzufügen->serieller port

Nach der Installation von OPN ohne PCI_Passthrough kann mit über die VM-Konsole unter proxmox ( TINY SPICe etc. ) und erstmaligem Start
auf der VM in /conf/config.xml mit vi folgende Tags einstellen:

<serialspeed>115200</serialspeed>
    <primaryconsole>serial</primaryconsole>
    <secondaryconsole>video</secondaryconsole>
Neustart.
qm start <VMID>

OPNSense Konsole "qm terminal <VMID>". ( nur über Ctrl-o zu verlassen).

Proxmox benötigt in dieser Konfiguration mho keine Konfiguration, damit OPN mit pci_passthrough
das routing übernehmen kann.

mit den tags

<wan>
      <if>em0</if>
      <enable>1</enable>
      <ipaddr>5.9.xxx.136</ipaddr>
      <ipaddrv6/>
      <blockbogons>on</blockbogons>
      <blockpriv>on</blockpriv>
      <subnet>27</subnet>
      <gateway>GW_WAN</gateway>
      <subnetv6/>
      <gatewayv6/>
    </wan>
  </interfaces>


<gateways>
    <gateway_item>
      <descr>Interface WAN Gateway</descr>
      <ipprotocol>inet</ipprotocol>
      <interface>wan</interface>
      <gateway>5.9.xxx.129</gateway>
      <monitor_disable>1</monitor_disable>
      <name>GW_WAN</name>
      <interval>1</interval>
      <weight>1</weight>
    </gateway_item>

erstellt OPN automatisch die routing table:

Destination                       Gateway               Flags  Netif Expire
default                             5.9.xxx.129           UGS   igb0
5.9.xxx.128/27                link#1                    U       igb0
5.9.xxx.129                     34:xx:f6:xx:54:xx  UHS   igb0
5.9.xxx.136                     link#1                   U        lo0



Diese route funktioniert offensichtlich bei HETZNER  nicht.

welche tags in der config.xml nötig sind, damit ein anderes routing erstellt wird, ist mir noch nicht bekannt.

Mein Beitrag zur Lösung der Herausforderung:
Ich habe dann Proxmox ohne OPN im router mode mit folgender Einstellung in
/etc/network/interfaces gestartet:

auto enp5s0
iface enp5s0 inet static
    address     5.9.xxx.136
    broadcast   5.9.xxx.159
    netmask     255.255.255.224
    gateway     5.9.xxx.129
    pointopoint 5.9.xxx.129

auto vmbr0
iface vmbr0 inet static
    address     5.9.xxx.136
    netmask     255.255.255.224
    bridge_ports none
    bridge_stp  off
    bridge_fd   0

was zu folgender routing table auf proxmox führt: (netstat -anvr)

Ziel            Router          Genmask         Flags   MSS Fenster irtt Iface
0.0.0.0         5.9.xxx.129     0.0.0.0         UG        0 0          0 enp5s0
5.9.xxx.128     0.0.0.0         255.255.255.224 U         0 0          0 vmbr0
5.9.xxx.129     0.0.0.0         255.255.255.255 UH        0 0          0 enp5s0

Wo liegt jetzt der Unterschied zwischen den 2 routing tables:

1. default route
a) OPN
   default                             5.9.xxx.129           UGS   igb0
b) Proxmox
0.0.0.0         5.9.xxx.129     0.0.0.0         UG        0 0          0 enp5s0

mho identisch:
OPN: default über 5.9.xxx.129 , (proxmox) debian: default über  5.9.xxx.129

2. Subnet
OPN:
5.9.xxx.128/27                link#1                    U       igb0
debian:
5.9.xxx.128     0.0.0.0         255.255.255.224 U         0 0          0 vmbr0


aus https://www.freebsd.org/doc/de_DE.ISO8859-1/books/handbook/network-routing.html
"FreeBSD wird automatisch Subnetzrouten für das lokale Subnetz hinzufügen. ....
Das Ziel link#1 bezieht sich auf die erste Ethernet-Karte im Rechner."

der Unterschied der Schnittstelle hier liegt wohl im bridge mode von Proxmox;
im Wesen aber gleich (?)


3. MAC-Adresse
OPN: 5.9.xxx.129                     34:xx:f6:xx:54:xx  UHS   igb0
debian: -----------

aus https://www.freebsd.org/doc/de_DE.ISO8859-1/books/handbook/network-routing.html
Bei den mit 0:e0: beginnenden Adressen handelt es sich um MAC-Adressen.
FreeBSD identifiziert Rechner im lokalen Netz, im Beispiel test0,
automatisch und fügt eine direkte Route über die Ethernet-Schnittstelle re0
zu diesem Rechner hinzu. Außerdem existiert in der Spalte Expire ein Timeout,
der verwendet wird, wenn dieser Rechner in einem definierten Zeitraum nicht
reagiert. Wenn dies passiert, wird die Route zu diesem Rechner automatisch
gelöscht. Rechner im lokalen Netz werden über das Routing Information
Protocol (RIP) identifiziert, welches den kürzesten Weg zu
den jeweiligen Rechnern berechnet.

Was ich hier nicht verstehe, ist die MAC-Adresse.
diese MAC adresse ist von dem eingebauten NIC im Server, wird hier aber
dem Gateway zugeordnet.

Wenn ich davon ausgehe, daß das IP Protokoll über Layer (1) die route findet,
könnte diese doch eigentlich nicht richtig sein ?

4. Host
OPN: 5.9.xxx.136                     link#1                   U        lo0
debian:

hier finde ich mal keine Entsprechung auf proxmox.

Ein Unterschied hier:
Debian:
5.9.xxx.129     0.0.0.0         255.255.255.255 UH        0 0          0 enp5s0

Flag H: Host
route: 0.0.0.0 ( default)
netif: enp5S0    ( entspräche in OPN igb0)


Aber wie könnte man eine derartige route in OPN: conf/config.xml
eintragen ?

ist mir derzeit noch ein Rätsel.

Vielleicht habe ich da etwas nicht verstanden oder was meinst Du?

#9
Moin,

ich habe jetzt proxmox/KVM Verbindung. Und OPNsense per pci_passthrough die NIC zugeteilt.

LAN (vtnet0)        -> v4:10.0.0.1/24
WAN (igb0)          -> v4:5.9.xxx.136/27 ( DHCP funktioniert hier nicht ?!)

Die route in OPNsense sieht jetz so aus:
Destination                       Gateway               Flags  Netif Expire
default                             5.9.xxx.129           UGS   igb0
5.9.xxx.128/27                link#1                    U       igb0
5.9.xxx.129                     34:xx:f6:xx:54:xx  UHS   igb0
5.9.xxx.136                     link#1                   U        lo0
10.0.0.0/24                     link#2                   UHS    lo0
PNsense                          link#2                   UHS    lo0
localhost                         link#4                    UH      lo0


ping nach 10.0.0.1 funktioniert (vtnet0)

ping nach 8.8.8.8  -->
ping: sendto: Host is down

Proxmox hat ja jetzt nur noch vmbr0 mit 10.0.0.2. das funktioniert.
die durchgereichte NIC sieht PVE gar nicht mehr.

Aber hier funktioniert eben auch nichts.

Wie könnte ich hier eine "hostroute" richtig einstellen ?

ich habe schon versucht mit 5.9.xxx.136/32 die IP als Host zu definieren, brachte aber auch nichts.

Bin für jede Hilfe dankbar.

Vielen Dank.

#10
Für NewBies eher nicht.
An anderer Stelle kann man im Forum nachlesen  (sinngemäß)
- ohne Support Vertrag soll sich doch bitteschön niemand beklagen --.
OpenSource heißt eben nicht Heilsarmee. Entwickler wollen entwickeln - und schon gar nicht für ihre Arbeit kritisch hinterfragt werden, nur weil "newbies" keine Handbücher lesen, keine Zeit investieren und nur meckern.

In anderen OpenSource Projekten kann man noch weitaus schlimmere Erfahrungen machen. Deshalb sind wir hier dankbar, dass wir wenigstens "Hinweise" bekommen, wie es weiter gehen könnte.

Aber kleiner Tip:
Wie ja bekannt ist, "versperrt das Sandkorn im Auge des Betrachters den Blick auf das Meer".
Vielleicht hilft man sich selbst an Popularität zu gewinnen, wenn ein Bemühen zur Lösung der Fragen anderer Forumsteilnehmer erkenntlich ist.

Deshalb macht es auch keinen Sinn, in hunderten von Foren zu saugen, denn für jede bekommene Antwort und Hilfe sollte man selbst eine Hilfe bzw. Antwort für eine von anderen gestellte Frage suchen. Und als Newbie steht man eben etwas in der Bringschuld.
In jedem guten Forum gibt es ein Scoring. Scoring 0 findet eigentlich wenig Beachtung.

#11
Das ist die Aussage von "nslookup":
DNS Server 10.0.0.1 funktioniert nicht.

Einen anderen RQ-Server eingetragen - und es funktioniert.
Ergo sind die Client - ports offen, Client - route ist vorhanden.
Aber eben DN Server "10.0.0.1" liefert keine Antwort.
Wohl an dieser Stelle direkt auf "10.0.0.1" den DN Server überprüfen, warum dieser keine Antwort liefert bzw. liefern kann. Mangels mehr infos vermute ich wohl, dass von 10.0.0.1 selbst keine route bzw. port für DNS zur Verfügung steht.
#12
Vielen Dank hbc,


Ja, das mit den Quellen ...; ich fand das auch doch sehr verwirrend...;
Routing war noch nie mein Stärke, aber "Hetzner" macht es auch nicht einfacher.

Die Schwierigkeit liegt ja darin, dass dies von der Konsole aus geschehen muss; ohne Netz kein WEB(GUI);
also lediglich mit "qm terminal <VMID> von proxmox Konsole aus einzig und allein über das sehr fortschrittliche Spider-KVM, welches von Hetzner da zugemutet wird. ('LARA').

Ich bin ein Freund der Konsole - aber hauptsächlich in Linux statt FreeBSD. FreeBSD hat eine andere Konfigdatei Struktur iAllg, OPNsense im Besonderen.

Deshalb muß ich auf der Konsole unter
"2) - IP Zuordnen" .
Könnte dann dem WAN [5.9.xxx.136/32] statt [5.9.xxx.136/27] als HauptIP eintragen?
( GW muß ja jeweils [5.9.xxx.129] bleiben).

Ansonsten könnte ich zwar über die Shell  noch weitere routen hinzufügen, nur die werden ja nicht persistent ?

#13
Hallo zusammen,

Ich bin auf der Suche noch über das Stichwort "hostroute" ( pointopoint unter Debian ) gestolpert.
Offensichtlich benötigt Hetzner Konfiguration diese hostroute

unter Debian in /etc/network/interfaces
....
gateway      <GWIp>
pointopoint <GWIp>

Also gehe ich davon aus, dass man diese hostroute auch in OPN setzen muss.

ich habe da noch etwas gefunden im FreeBSD Forum:

"ein wenig mit den Routen frickeln hat geholfen. Im Prinzip habe ich jetzt ein script, das ich aus der rc.conf aufrufen lasse, was mir eine Route über das Interface auf meinen Gateway legt und dann über den Gateway nach 0.0.0.0 weiterroutet und zusätzlich musste ich noch die Netzmaske fest auf 255.255.255.255 setzen, da FreeBSD mir eine ffff0000 gesetzt hatte"

In die Praxis umsetzen, in Befehle bzw. statische Dateien in BSD, verstehe ich aber nicht wirklich.

Könnte es dies der Fehler sein ? Könnte mir jemand behilflich sein, dies umzusetzen ?

mfg

JoeB
#14
Hallo

ich bin bei meinen VMs davon abgekommen, Balloon Speicher zu verwenden.
Zwar würde der Speicher anderen VMs zur Verfügung stehen, aber evtl. muss der Speicher dann neu geordnet werden. Das kann dauern. ( Man glaubt es kaum, evtl. geht eine anderer VM-SpeicherBereich ins Swap auf Platte).

Deshalb meine Devise: Was hilft gegen Hubraum ? Noch mehr Hubraum.
Wenn es eng wird mit dem RAM, tatsächlich wirklich RAM drauflegen.
#
Zitat aus https://www.pcwelt.de/ratgeber/Swap-Speicher_bei_Linux_optimieren-Gut_ausgelagert-8255716.html
( nur um es zu verdeutlichen ).
Linux-Systeme bieten seit dem Kernel 2.6 die Möglichkeit, das Swap-Verhalten über den Parameter ,,Swappiness" zu beeinflussen. Dieser darf einen Wert zwischen 10 und 100 annehmen. Je höher der Wert, desto aggressiver wird der Kernel versuchen, wenig benutzte Speicherseiten aus dem RAM in die Swap-Partition zu schreiben. Der voreingestellte Standardwert liegt bei 60. Ein höherer Wert kann die Systemleistung verbessern, wenn die Swap- Partition oder Auslagerungsdatei auf einer schnellen SSD liegt. Denn dann bleibt einerseits den laufenden Programmen mehr RAM, andererseits bremst die Auslagerung von selten benötigten Speicherseiten das System noch kaum aus.

Um temporär den Wert der Swappiness zu erhöhen, öffnen Sie ein Terminal und geben dieses Kommando als root oder mit sudo ein:

sysctl vm.swappiness=90

Sie können natürlich auch einen niedrigeren Wert als 60 eintragen, um die Auslagerungsaktivität zu reduzieren. Um die Änderungen auch dauerhaft zu speichern, müssen diese in einer Konfigurationsdatei hinterlegt werden. Öffnen Sie dazu ein Terminal, und geben Sie dort

sudo -H gedit /etc/sysctl.conf

ein, um die Konfigurationsdatei ,,sysctl.conf" mit dem Editor gedit zu öffnen. Suchen Sie in der Datei nun nach einem Eintrag ,,swappiness". Bei den meisten Distributionen müssen Sie diese Zeile in der Datei erst noch selbst hinzufügen:

vm.swappiness=90

Gruß

Joe
#15
Hallo zusammen,

Vielleicht könnte mich jemand gezielt unterstützen:
Es soll mein Proxmox vollständig hinter OPNsense als VM Router gestellt sein.
Hetzner ist der Provider.

Auf Proxmox möchte ich außerdem zur vollständigen Isolierung Openswitch verwenden.

Ich habe eine Haupt IP:
5.9.xxx.136, netmask 255.255.255.224, gw 5.9.xxx.129


Proxmox:
/etc/network/interfaces

auto lo
iface lo inet loopback

auto vmbr0
iface vmbr0 inet manual
        ovs_type OVSBridge
        ovs_ports int0

allow-vmbr0 int0
iface int0 inet static
        address  10.0.0.2
        netmask  255.255.255.0
        gateway  10.0.0.1
        ovs_type OVSIntPort
        ovs_bridge vmbr0

/etc/hosts
127.0.0.1 localhost
10.0.0.1 pve .....

pci_passthrough ist eingerichtet und funktioniert auch ( soweit überprüfbar ).


Proxmox mit dieser config gestartet, OPNsense als VM100 gestartet.

In OPN:
WAN: igb0, Haupt-IP von Hetzner mit Gw etc. ( 5.9.xxx136/27, 5.9.xxx.129): MAc-Adresse stimmt.
LAN: vtnet0, 10.0.0.1

Ping :
10.0.0.1 funktioniert
5.9.xxx.136 funktioniert ( Haupt-IP)
5.9.xxx.129 -- HOST is down
8.8.8.8        -- HOST is down
zur Info:
das GW antwortet auf ICMP


Der Plan, WAN über DHCP funktioniert nicht. Da kommt nichts.

Auf PVE gibt s ja mangels einem eigenen NIC keine route für WAN IPs.
die route für das 10er net ist gesetzt und funktioniert.


Vielleicht könnte mir jemand sagen, wo der "Fehler" liegt.

Eigentlich bin ich der Ansicht, viel kann da nicht mehr sein. Doch 20% der Arbeit benötigen meist 80% Aufwand.
( Mein Kompliment: Ich habe mich OPNsense über pfSense genähert - OPNsense ist eindeutig das bessere ).

Vielleicht noch soviel: Bridge mag ich nicht. Es ist auch eher nicht die Frage nach bridge. Nachdem sich OPN den NIC gegriffen hat, ist ja nur OPN für das WAN zunächst zuständig und muß selber ins Internet kommen können.

Was jemand einen Rat ?

Vielen Dank im Voraus.