20
Pfsense Bridge mit zwei LAN Ports - keine IP per DHCP
Hallo zusammen,
ich habe das Problem, das ich von zwei LAN Ports die als BRIDGE auf einer pfsense konfiguriert sind, keine IP per DHCP bekomme.
Ich habe das wie folgt eingerichtet:
Pfsense 2.5.1 auf ESXi 6.7.0 Update 3 (Build 17700523) auf einem HP ProLiant DL380p Gen8
Pfsense mit einem WAN und vier LAN Ports. Alle LAN Ports haben keinen Uplink. Der WAN Port hat natürlich einen Uplink.
LAN01 mit DHCP 172.30.0.0/24
LAN02 und LAN03 in BRIDGE mit DHCP 172.28.0.0/24
LAN04 mit DHCP 172.26.0.0/24
Im LAN der Pfsense ist ein VM Ubuntu Client.
Verbindung mit LAN01 funktioniert. IP Adresse wird zugewiesen.
Verbindung mit LAN04 funktioniert. IP Adresse wird zugewiesen.
Verbindung mit LAN02 und LAN03 funktioniert nicht.
D.h. die Bridge funktioniert nicht.
Die Bridge habe ich wie folgt eingerichtet:
Die Firewall ist wie folgt eingerichtet:
LAN02, LAN03, LAN04 und BRIDGE haben alle die gleiche folgende Firewallregel:
Der DHCP Server ist auf LAN01, LAN04 und BRIDGE gleich eingerichtet, mit den Netzwerken 172.30.0.0/24, 172.28.0.0/24 und 172.26.0.0/24:
Die zwei Parametre net.link.bridge.pfil_member und net.link.bridge.pfil_bridge sind wie folgt gesetzt:
Wenn ich den Ubuntu Client im LAN der pfsense mit LAN01 oder LAN04 verbinde, bekomme ich sofort eine IP aus dem jeweiligen Netz und komme ins Internet über den WAN Port.
Wenn ich den Ubuntu Client mit LAN02 oder LAN03 verbinde, also mit LAN Ports aus der BRIDGE, dann ist nichts.
Könnte ihr mir helfen. Was mache ich falsch, dass ich mit der BRIDGE keine Verbindung hinbekomme.
Danke und Grüße
Lehrling
ich habe das Problem, das ich von zwei LAN Ports die als BRIDGE auf einer pfsense konfiguriert sind, keine IP per DHCP bekomme.
Ich habe das wie folgt eingerichtet:
Pfsense 2.5.1 auf ESXi 6.7.0 Update 3 (Build 17700523) auf einem HP ProLiant DL380p Gen8
Pfsense mit einem WAN und vier LAN Ports. Alle LAN Ports haben keinen Uplink. Der WAN Port hat natürlich einen Uplink.
LAN01 mit DHCP 172.30.0.0/24
LAN02 und LAN03 in BRIDGE mit DHCP 172.28.0.0/24
LAN04 mit DHCP 172.26.0.0/24
Im LAN der Pfsense ist ein VM Ubuntu Client.
Verbindung mit LAN01 funktioniert. IP Adresse wird zugewiesen.
Verbindung mit LAN04 funktioniert. IP Adresse wird zugewiesen.
Verbindung mit LAN02 und LAN03 funktioniert nicht.
D.h. die Bridge funktioniert nicht.
Die Bridge habe ich wie folgt eingerichtet:
Die Firewall ist wie folgt eingerichtet:
LAN02, LAN03, LAN04 und BRIDGE haben alle die gleiche folgende Firewallregel:
Der DHCP Server ist auf LAN01, LAN04 und BRIDGE gleich eingerichtet, mit den Netzwerken 172.30.0.0/24, 172.28.0.0/24 und 172.26.0.0/24:
Die zwei Parametre net.link.bridge.pfil_member und net.link.bridge.pfil_bridge sind wie folgt gesetzt:
Wenn ich den Ubuntu Client im LAN der pfsense mit LAN01 oder LAN04 verbinde, bekomme ich sofort eine IP aus dem jeweiligen Netz und komme ins Internet über den WAN Port.
Wenn ich den Ubuntu Client mit LAN02 oder LAN03 verbinde, also mit LAN Ports aus der BRIDGE, dann ist nichts.
Könnte ihr mir helfen. Was mache ich falsch, dass ich mit der BRIDGE keine Verbindung hinbekomme.
Danke und Grüße
Lehrling
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 666702
Url: https://administrator.de/contentid/666702
Ausgedruckt am: 24.11.2024 um 16:11 Uhr
20 Kommentare
Neuester Kommentar
Die zwei Parametre net.link.bridge.pfil_member und net.link.bridge.pfil_bridge sind wie folgt gesetzt:
Wozu ? Diese musst du nicht extra setzen. Normal verbleiben sie immer im Default !2 Dinge wären hilfreich:
- Am Ubuntu ein tcpdump -i eth0 port 67 or 68 Output um zusehen ob ein DHCP Request rausgeht und ggf. ein Reply kommt vom und zum Client. (eth0 wenn das der LAN Port am Ubuntu ist)
- In der pfSense unter Diagnostics -> Packet Capture. Dort Interface Bridge und Protokoll auf UDP und Port auf 67|68 (Pipe Zeichen ist "or" !). Das zeigt dann die Gegenseite ob dort die DHCP Requests überhaupt ankommen und Replys rausgehen.
Hallo aqui,
erstmal danke für deine Unterstützung.
Die zwei Parameter hatte ich vertauscht. Habs korrigiert. Die Info hatte ich aus der Anleitung:
https://docs.netgate.com/pfsense/en/latest/bridges/interfaces.html
Ich habe hier mal den tcpdump:
und "Packet Capture":
Da kommt man nur darauf, wenn man von vernetzten Robotern erzogen wurde oder Netzwerkolologie studiert hat.
Da ich aber erstmal alles lernen muss, bin ich noch nicht soweit, dass ich auf Dinge komme, die ich nicht mal dem Namen nach kenne.
Ich habe auch nur einmal Leben und einmal Energie und viele andere Dinge in meinem Leben ausser Netzwerkolologie.
Vielen Danke für eine Unterstützung
FISI-Lehrling
erstmal danke für deine Unterstützung.
Die zwei Parameter hatte ich vertauscht. Habs korrigiert. Die Info hatte ich aus der Anleitung:
https://docs.netgate.com/pfsense/en/latest/bridges/interfaces.html
Change the bridge filtering System Tunable to disable member interface filtering
Navigate to System > Advanced, System Tunables tab
Locate the entry for net.link.bridge.pfil_member or create a new entry if one does not exist, using that name for the Tunable
Click fa-pencil to edit an existing entry
Enter 0 in the Value field
Click Save
Navigate to Interfaces > Assignments
Change the assignment of LAN to bridge0
Click Save
Assign and configure the old LAN interface as described previously, setting its IP configuration types to None and naming it WiredLAN
Edit the bridge and select the newly assigned WiredLAN as a bridge member
Change the bridge filtering System Tunable to enable bridge interface filtering
Use the procedure described previously, but set net.link.bridge.pfil_bridge to 1Ich habe hier mal den tcpdump:
und "Packet Capture":
Zitat von @aqui:
Auf diese erstmal sehr einfachen, grundlegenden Troubleshooting Tips kommt man doch aber auch selber....?!
Auf diese erstmal sehr einfachen, grundlegenden Troubleshooting Tips kommt man doch aber auch selber....?!
Da kommt man nur darauf, wenn man von vernetzten Robotern erzogen wurde oder Netzwerkolologie studiert hat.
Da ich aber erstmal alles lernen muss, bin ich noch nicht soweit, dass ich auf Dinge komme, die ich nicht mal dem Namen nach kenne.
Ich habe auch nur einmal Leben und einmal Energie und viele andere Dinge in meinem Leben ausser Netzwerkolologie.
Vielen Danke für eine Unterstützung
FISI-Lehrling
Am pfSense Output kannst du ja selber deutlich sehen das der DHCP Request vom Ubuntu Client am pfSense DHCP Server ankommt und auch vom DHCP Server 172.28.0.1 beantwortet wird.
Allerdings mit einer negative Bestätigung (DHCPNAK) ("NAK"=No ACK).
Er "mag" den DHCP Request also aus irgendeinem Grund nicht und leht ihn ab. Da musst du also mal checken warum.
Leider hast du den Wireshark NICHT auf den NAK Frame gesetzt und dort mal die Parameter eröffnet (mittleres WS Fenster, dortige Pfeile) so das die Community hier nicht sehen kann WAS den NAK bewirkt hat.
Verkleiner also mal das Binärfenster (unten) und sieht dir im vergrößerten, mittleren Fenster die DHCP Parameter des Clients einmal genauer an !
Sowas kann z.B. passieren wenn deine Ubuntu Kiste ein Dual Boot Rechner ist wo ein OS als Identifier die Hardware nutzt ein anderer aber eine DUID. Bei gleicher HW Adresse wird der DUID Request dann abgelehnt innerhalb der Lease Time. Vorab solltest du bei sowas dann IMMER unter Status --> DHCP Leases mit dem Button "Clear all DHCP leases" die Lease Database dann wieder nackig machen.
Allerdings mit einer negative Bestätigung (DHCPNAK) ("NAK"=No ACK).
Er "mag" den DHCP Request also aus irgendeinem Grund nicht und leht ihn ab. Da musst du also mal checken warum.
Leider hast du den Wireshark NICHT auf den NAK Frame gesetzt und dort mal die Parameter eröffnet (mittleres WS Fenster, dortige Pfeile) so das die Community hier nicht sehen kann WAS den NAK bewirkt hat.
Verkleiner also mal das Binärfenster (unten) und sieht dir im vergrößerten, mittleren Fenster die DHCP Parameter des Clients einmal genauer an !
Sowas kann z.B. passieren wenn deine Ubuntu Kiste ein Dual Boot Rechner ist wo ein OS als Identifier die Hardware nutzt ein anderer aber eine DUID. Bei gleicher HW Adresse wird der DUID Request dann abgelehnt innerhalb der Lease Time. Vorab solltest du bei sowas dann IMMER unter Status --> DHCP Leases mit dem Button "Clear all DHCP leases" die Lease Database dann wieder nackig machen.
Hallo aqui,
danke für die Tips.
Wieviele millionen Jahre machst du das schon oder hast du eine Mensch-Maschinen-Schnittstelle und dir alles über Netzwerke hochgeladen?
Das ist unglaublich was du hier an Infos/Tips gibst.
Hier mal der Ausschnitt über den abgelehnten DHCP Request.
Grüße
Lehrling
danke für die Tips.
Wieviele millionen Jahre machst du das schon oder hast du eine Mensch-Maschinen-Schnittstelle und dir alles über Netzwerke hochgeladen?
Das ist unglaublich was du hier an Infos/Tips gibst.
Hier mal der Ausschnitt über den abgelehnten DHCP Request.
Grüße
Lehrling
Eine Mensch-Maschine Schnittstelle !!! 🤣
Gibt es ggf. schon einen Lease Eintrag zur HW ID 02:8A:26:97:14:00 in der pfSense unter Status --> DHCP Leases ? Ubuntu Dual Boot System ?
Lösche sonst mal die komplette Lease Database auf der FW und lass ihn nochmal discovern. (Siehe Anmerkung oben).
Siehst du irgendwelche Log Meldungen in der pfSense ? (Status --> System Logs) ?
Hier solltest du in den Log Settings den Parameter "Show log entries in reverse order (newest entries on top)" anhaken damit du die aktuellsten Messages immer am Anfang siehst. VOR dem neuen DHCP Discover ggf. die Logs erstmal löschen damit du nicht zuviel anderen Logging "Müll" siehst.
Gibt es ggf. schon einen Lease Eintrag zur HW ID 02:8A:26:97:14:00 in der pfSense unter Status --> DHCP Leases ? Ubuntu Dual Boot System ?
Lösche sonst mal die komplette Lease Database auf der FW und lass ihn nochmal discovern. (Siehe Anmerkung oben).
Siehst du irgendwelche Log Meldungen in der pfSense ? (Status --> System Logs) ?
Hier solltest du in den Log Settings den Parameter "Show log entries in reverse order (newest entries on top)" anhaken damit du die aktuellsten Messages immer am Anfang siehst. VOR dem neuen DHCP Discover ggf. die Logs erstmal löschen damit du nicht zuviel anderen Logging "Müll" siehst.
Ich habe unter Lease leider kein Eintrag zu 02:8A:26:97:14:00
Welcher Reiter unter Log ist für die richtige Infromation notwendig?
Ich habe hier mal System und General
Welcher Reiter unter Log ist für die richtige Infromation notwendig?
Ich habe hier mal System und General
Auffällig sind ja die mehrfach gleichen Mac Adressen deiner Endgeräte. Keine wirklich gute Idee und lässt den leisen Verdacht aufkommen das du bem Setup der virtuellen NICs gepfuscht hast und nicht auf Einzigartigkeit geachtet hast...?!
Welcher Reiter unter Log ist für die richtige Infromation notwendig?
Gegenfrage: Was denkst du was am sinnvollsten klingt im Menü ? Routing ? Wireless ? Oder könnte evtl. "DHCP" zielführend sein ?
Die MAC Adressen sind denke ich einzigartig.
Man sieht ja dass der Lease abgelaufen ist.
Ich habe nur die Reiter so eingestellt, dass man alles sieht.
Ich probiers mal mit DHCP
Ich werde jetzt mal auf einem alten ProLiant DL360 G7 direkt ein pfsense installieren und dort auch testen.
Neben der pfsense habe ich auch ein OPNsense als VM installiert aber da habe ich das gleiche Problem, dass ich das mit der Bridge nicht verstehe/hinbekomme.
Ist es in dem Zusammenhang richtig, dass man bei einer Firewall wie der pfsense ohnehin eher keine BRIDGE einrichtet, wie in einem Router oder habe ich da was falsch gelesen.
Bei einem MikroTik oder OpenWRT ist das ja einfach die LAN Anschlüsse als eine BRIDGE zu verwenden.
Beim MikroTik muss ich das im Webfrontend nur anklicken.
Man sieht ja dass der Lease abgelaufen ist.
Ich habe nur die Reiter so eingestellt, dass man alles sieht.
Zitat von @aqui:
Gegenfrage: Was denkst du was am sinnvollsten klingt im Menü ? Routing ? Wireless ? Oder könnte evtl. "DHCP" zielführend sein ?
Gegenfrage: Was denkst du was am sinnvollsten klingt im Menü ? Routing ? Wireless ? Oder könnte evtl. "DHCP" zielführend sein ?
Ich probiers mal mit DHCP
Ich werde jetzt mal auf einem alten ProLiant DL360 G7 direkt ein pfsense installieren und dort auch testen.
Neben der pfsense habe ich auch ein OPNsense als VM installiert aber da habe ich das gleiche Problem, dass ich das mit der Bridge nicht verstehe/hinbekomme.
Ist es in dem Zusammenhang richtig, dass man bei einer Firewall wie der pfsense ohnehin eher keine BRIDGE einrichtet, wie in einem Router oder habe ich da was falsch gelesen.
Bei einem MikroTik oder OpenWRT ist das ja einfach die LAN Anschlüsse als eine BRIDGE zu verwenden.
Beim MikroTik muss ich das im Webfrontend nur anklicken.
Hi,
warum erstellst du eine Bridge ?
was willst du damit erreichen ?
CH
warum erstellst du eine Bridge ?
was willst du damit erreichen ?
CH
Hallo ChriBo,
weil pfsense das möglich macht, will ich es umsetzen.
Könnte ja an einen virtuellen LAN Port, einen physischen hängen und daran ein WIFI in die pfsense einbinden und die mit dem LAN bridgen, wie es in einem Router gemacht wird.
So dass dann ein DHCP für LAN und LAN/Wireless vorhanden ist.
Aber das ist nur theoretisch, letztendlich will ich lernen und die Bits und Bytes verstehen.
Die pfsense steht in keiner Produktivumgebung und der Server ist nur zum ausprobieren und lernen.
Grüße
FISI-Lehrling
weil pfsense das möglich macht, will ich es umsetzen.
Könnte ja an einen virtuellen LAN Port, einen physischen hängen und daran ein WIFI in die pfsense einbinden und die mit dem LAN bridgen, wie es in einem Router gemacht wird.
So dass dann ein DHCP für LAN und LAN/Wireless vorhanden ist.
Aber das ist nur theoretisch, letztendlich will ich lernen und die Bits und Bytes verstehen.
Die pfsense steht in keiner Produktivumgebung und der Server ist nur zum ausprobieren und lernen.
Grüße
FISI-Lehrling
Jetzt habe ich pfsense direkt auf einen ProLiant DL360 G7 installiert, weil ich da 4 x Ethernet Ports habe.
Einen habe ich als WAN und einen als LAN konfiguriert.
Die zwei verbleibenden als BRIDGE.
Dann die Parameter/Firewall usw. gesetzt, wie in der pfsense und OPNsense in der VM und hat auf Anhieb geklappt.
Denke dass da was mit den virtuellen Netzwerkschnittstellen nicht funktioniert.
Werde mir das mal anschauen und testen.
Interessant ist, dass jede der Schnittstellen als Standalone LAN funktioniert, nur nicht wenn ich sie als BRIDGE konfiguriere.
Aber sollte etwas mit der Virtualisierung zu tun haben, wenn es jetzt mit der direkten Installation auf Anhieb geklappt hat.
Auf jeden Fall weiß ich jetzt wie die Brigde bei pfsense eingerichtet wird.
Grüße
Lehrling
Einen habe ich als WAN und einen als LAN konfiguriert.
Die zwei verbleibenden als BRIDGE.
Dann die Parameter/Firewall usw. gesetzt, wie in der pfsense und OPNsense in der VM und hat auf Anhieb geklappt.
Denke dass da was mit den virtuellen Netzwerkschnittstellen nicht funktioniert.
Werde mir das mal anschauen und testen.
Interessant ist, dass jede der Schnittstellen als Standalone LAN funktioniert, nur nicht wenn ich sie als BRIDGE konfiguriere.
Aber sollte etwas mit der Virtualisierung zu tun haben, wenn es jetzt mit der direkten Installation auf Anhieb geklappt hat.
Auf jeden Fall weiß ich jetzt wie die Brigde bei pfsense eingerichtet wird.
Grüße
Lehrling
Nachdem das auf Anhieb mit der pfsense direkt auf der Hardware geklappt habe, habe ich es noch einmal in der VM getestet.
Erst nochmal alle LAN Ports einzeln mit DHCP Server ausgestattet und mit dem Ubuntu Client verbunden:
Funktioniert auf jedem LAN Anschluss, mit dem jeweiligen IP Range sofort.
Dann wieder bei LAN02 und LAN03 den DHCP Server rausgenommen und im Interface die Static IP auf NONE.
Das BRIDGE Interface erstellt mit LAN02 und LAN03.
Aber wie gehabt, da geht nichts.
Schon eigenartig.
Erst nochmal alle LAN Ports einzeln mit DHCP Server ausgestattet und mit dem Ubuntu Client verbunden:
Funktioniert auf jedem LAN Anschluss, mit dem jeweiligen IP Range sofort.
Dann wieder bei LAN02 und LAN03 den DHCP Server rausgenommen und im Interface die Static IP auf NONE.
Das BRIDGE Interface erstellt mit LAN02 und LAN03.
Aber wie gehabt, da geht nichts.
Schon eigenartig.
Im DHCP Log oben kannst du aber ja eindeutig sehen das der Ubuntu Client ein DHCP Offer vom DHCP Server der Firewall bekommt.
Ubuntu nimmt diesen Offer aber niemals an da der an der Ubuntu NIC niemals ankommt. Siehe tcpdump.
Fazit: Zeigt das irgendwas am Übergang der virtuellen NICs zur VM schief läuft !
Die generelle Frage ist ja wie du die intern angebunden hast ? Normal betreibt VmWare einen vSwitch an dem man so niemals 2 gebridge Interface ankoppeln darf weil es so unweigerlich zu einen tödlichen Layer 2 Loop im Netzwerk kommt. Wenn auf dem vSwitch Spanning Tree aktiv ist (was aber keiner weiss wegen fehlender Infos) sorgt der dafür das ein Interface so oder so geblockt wird.
All das ist aber frei geraten weil du dazu keinerlei Angaben machst.
Ubuntu nimmt diesen Offer aber niemals an da der an der Ubuntu NIC niemals ankommt. Siehe tcpdump.
Fazit: Zeigt das irgendwas am Übergang der virtuellen NICs zur VM schief läuft !
Die generelle Frage ist ja wie du die intern angebunden hast ? Normal betreibt VmWare einen vSwitch an dem man so niemals 2 gebridge Interface ankoppeln darf weil es so unweigerlich zu einen tödlichen Layer 2 Loop im Netzwerk kommt. Wenn auf dem vSwitch Spanning Tree aktiv ist (was aber keiner weiss wegen fehlender Infos) sorgt der dafür das ein Interface so oder so geblockt wird.
All das ist aber frei geraten weil du dazu keinerlei Angaben machst.
Nachdem ich die kompletten NICs wie geschrieben getestet habe und das Problem erst auftritt, wenn ich die zwei LAN Ports in der pfsense VM als Bridge konfiguriere, gehe ich davon aus, dass im grundsätzlichen Design nicht der Fehler steckt.
Wie dargestellt im letzen Beitrag von mir.
Es funktioniert mit LAN01 bis LAN04 mit eigenem DHCP Server ohne Probleme.
Aber wenn ich bei LAN02 und LAN03 umstelle und die in ein Bridge Interface setze dann ist nichts mehr.
Wenn ich das aber direkt auf dem ProLiant DL360 G7 mit pfsense ohne VM ESXi mache, dann klappt das Setting auch direkt und ohne Probleme.
Vielleicht kann das ja einer nachstellen. Mein Setting ist:
Pfsense 2.5.1 auf ESXi 6.7.0 Update 3 (Build 17700523) auf einem HP ProLiant DL380p Gen8
Die generelle Frage ist ja wie du die intern angebunden hast ? Normal betreibt VmWare einen vSwitch an dem man so niemals 2 gebridge Interface ankoppeln darf weil es so unweigerlich zu einen tödlichen Layer 2 Loop im Netzwerk kommt. Wenn auf dem vSwitch Spanning Tree aktiv ist (was aber keiner weiss wegen fehlender Infos) sorgt der dafür das ein Interface so oder so geblockt wird.
Verstehe das nicht was du da schreibst.
dass im grundsätzlichen Design nicht der Fehler steckt.
Das ist richtig !Verstehe das nicht was du da schreibst.
"Noch viel lernen du noch musst junger Padawan" würde Meister Joda sagen. 
Guckst du hier:
VLAN mit Cisco SG220, ESXIund Pfsense
Sophos Software Appliance UTM - VLAN - CISCO SG Series Switches
Die interne Netzwerk Konfig deines VmWare Hypervisors ist also der Knackpunkt ! Dort hast du was falsch gemacht.
"Noch viel lernen du noch musst junger Padawan" würde Meister Joda sagen.
Davon gehe ich mal ganz stark aus 
Ich schau mir jetzt mal die VMware Netzwerkkonfiguration an und poste sie hier.
Ich habe mal alle LAN Verbindungen von der pfsense mit dem Ubuntu Client verbunden.
Da läuft alles rund mit 4 NICs mit vier IPs. Alles gut.
Ich verstehe auch nicht wo ich da was ändern soll.
Ich ändere ja in der pfsense die Konfiguration.
LAN01 bis LAN04 hat ja auch keine Probleme wenn ich sie alle an den Ubuntu Clienten hänge.
Hier ist die Konfiguration aus dem ESXi.
Hast du mir einen Tip?
Muss ich die mit einer VLAN ID versehen, dass ich sie innerhalb von pfsense in eine Bridge packen kann?
Da läuft alles rund mit 4 NICs mit vier IPs. Alles gut.
Ich verstehe auch nicht wo ich da was ändern soll.
Ich ändere ja in der pfsense die Konfiguration.
LAN01 bis LAN04 hat ja auch keine Probleme wenn ich sie alle an den Ubuntu Clienten hänge.
Hier ist die Konfiguration aus dem ESXi.
Hast du mir einen Tip?
Muss ich die mit einer VLAN ID versehen, dass ich sie innerhalb von pfsense in eine Bridge packen kann?
Ich habs gefunden.
Ich muss, warum auch immer in den Eigenschaften des Standard-Switch "Gefälschte Übertragungen" auf "Akzeptieren" setzen.
So hat es jetzt geklappt und ist stabil auch nach dem Wechseln, von LAN02 auf LAN03, die ja beide Bestandteil der Bridge sind.
Nach ein und ausschalten von pfsense und Ubuntu Client bleibt es wie es soll, die BRIDGE in pfsense funktioniert in der VM.
Von wegen was falsch gemacht, auf so ein ### muss man erstmal kommen.
Hoffe der Beitrag hilft, wenn einer mit dem selben Problem kämpft.
Wieder was gelernt.
P.S.: Bei weiteren Tests habe ich bemerkt, das läuft beim Wechsel der LAN Ports nur stabil, wenn alle drei Parameter auf "Akzeptieren" gesetzt sind, bei allen LAN Schnittstellen aus der Bridge.
Ich muss, warum auch immer in den Eigenschaften des Standard-Switch "Gefälschte Übertragungen" auf "Akzeptieren" setzen.
So hat es jetzt geklappt und ist stabil auch nach dem Wechseln, von LAN02 auf LAN03, die ja beide Bestandteil der Bridge sind.
Nach ein und ausschalten von pfsense und Ubuntu Client bleibt es wie es soll, die BRIDGE in pfsense funktioniert in der VM.
Von wegen was falsch gemacht, auf so ein ### muss man erstmal kommen.
Hoffe der Beitrag hilft, wenn einer mit dem selben Problem kämpft.
Wieder was gelernt.
P.S.: Bei weiteren Tests habe ich bemerkt, das läuft beim Wechsel der LAN Ports nur stabil, wenn alle drei Parameter auf "Akzeptieren" gesetzt sind, bei allen LAN Schnittstellen aus der Bridge.
Von wegen was falsch gemacht....
Na ja du musst dir auch netzwerktechnisch mal vor Augen führen was für einen Quatsch du da auch machst.Der Hypervisor hat einen vSwitch im Background laufen, also quasi virtuell einen NetGear, D-Link oder sowas was du auch physisch irgendwo vor dir stehen hast. An dessen Ports hängen die einzelnen VMs.
Was du mit der Bridge jetzt machst ist ein Layer 2 Kurzschluß. Also das gleiche als ob du auf deinem physischen NetGear, D-Link 2 Ports mit einem Patchkabel kurzschliesst. Damit hast du einen Layer 2 Loop erzeugt. Wie technisch sinnvoll so eine Vorgehensweise ist kannst du vermutlich auch als FISI Lehrling selber besser beurteilen.
Du frickelst diesen Unsinn dann mit obskuren Security Settings irgendwie hin das es klappt.
- Promiscous Mode flutet quasi alle vSwitch Ports. Ein NoGo für den Wirkbetrieb ! Sowas nutzt man nur wenn man mit Wireshark misst oder ein Port Monitoriing macht
- On the Fly Mac Änderungen und was "Gefälschte Übertragung" ist will man besser gar nicht erst wissen...
Die generelle Frage ist WAS du mit einem Bridging Setup bewirken willst bzw. was dein Ziel ist ? Normal ist das ein Feature auf vorhandener Router Hardware Ports im Layer 2 zu bündeln. Das hast du aber gar nicht in einer vSwitch Umgebung. Sowas ist deshalb in einer vSwitch Umgebung natürlich völliger Unsinn, denn das definierst du ja letztlich über die Portgruppen des vSwitches. Das Beispiel mit dem Kurzschlußkabel oben führt dir das plastisch vor Augen.
Etwas mehr Gedanken zur Infrastruktur und den Layern einer Virtualisierungsumgebung kann also nicht schaden.
Ich wollte zur Übung auf einer pfsense eine Bridge einrichten.
So wie der https://www.youtube.com/watch?v=bz45r_4BREw
Da ich aber lieber mit VMs rumwurstle, um zu lernen, habe ich die pfsense in einer VM installiert und dann so behandelt als wäre sie direkt installiert, indem ich den ESXi "hingebogen" habe.
Da kann ich dann auch schnell mit einem Snapshot was sichern und wieder darauf zugreifen.
Dass das in einer Produktivumgebung nichts verloren hat, ist mir auch klar.
Aber wenn ich angenommen eine Dokumentation einer pfsense erstelle, wie sie funktioniert wenn ich die z.B. auf einer vorinstallierten Hardware (https://www.pfsense.org/products/) kaufe, dann entspricht das Setting in der VM, mit der Bridge, jetzt eben diesem Setting.
Das die Einstellungen auf einem Router mit pfsense richtig wären, habe ich gesehen, als ich die pfsense dann doch mal auf der Hardware direkt installiert habe.
Und zu deinem Kurzschluss Gedöns kann ich nur anmerken, dass der TÜV auch ein Auto gegen die Wand fährt um zu testen.
Ich richte auch Server ein und schalte den root auf SSH frei und nehme als Passwort root.
Warum? Weil ich in dem Setting etwas anderes ausprobiere und mich nicht mit Dingen ausbremsen will, die eben nicht dran sind.
Ich bin nicht als Administrator hier, der Fragen zu einer Produktivumgebung gelöst haben will.
In der IT stellst du eine Frage, bekommst die halb beantwortet und hast zehn neue. Da fängst du dann an, hast ein Problem mit einer Beispiel Netzwerkeinstellung, schaust nach Hilfe und bist 30 Minuten später, beim Lernen, wie man Festplatten im Terminal als RAID konfiguriert. Und zwei Tage später fällt dir dann ein, dass da doch was mit der Netzwerkeinstellung war.
Lernen kann somit auch so aussehen wie ich es mache.
So wie der https://www.youtube.com/watch?v=bz45r_4BREw
Da ich aber lieber mit VMs rumwurstle, um zu lernen, habe ich die pfsense in einer VM installiert und dann so behandelt als wäre sie direkt installiert, indem ich den ESXi "hingebogen" habe.
Da kann ich dann auch schnell mit einem Snapshot was sichern und wieder darauf zugreifen.
Dass das in einer Produktivumgebung nichts verloren hat, ist mir auch klar.
Aber wenn ich angenommen eine Dokumentation einer pfsense erstelle, wie sie funktioniert wenn ich die z.B. auf einer vorinstallierten Hardware (https://www.pfsense.org/products/) kaufe, dann entspricht das Setting in der VM, mit der Bridge, jetzt eben diesem Setting.
Das die Einstellungen auf einem Router mit pfsense richtig wären, habe ich gesehen, als ich die pfsense dann doch mal auf der Hardware direkt installiert habe.
Und zu deinem Kurzschluss Gedöns kann ich nur anmerken, dass der TÜV auch ein Auto gegen die Wand fährt um zu testen.
Ich richte auch Server ein und schalte den root auf SSH frei und nehme als Passwort root.
Warum? Weil ich in dem Setting etwas anderes ausprobiere und mich nicht mit Dingen ausbremsen will, die eben nicht dran sind.
Ich bin nicht als Administrator hier, der Fragen zu einer Produktivumgebung gelöst haben will.
In der IT stellst du eine Frage, bekommst die halb beantwortet und hast zehn neue. Da fängst du dann an, hast ein Problem mit einer Beispiel Netzwerkeinstellung, schaust nach Hilfe und bist 30 Minuten später, beim Lernen, wie man Festplatten im Terminal als RAID konfiguriert. Und zwei Tage später fällt dir dann ein, dass da doch was mit der Netzwerkeinstellung war.
Zitat von @aqui:
Na ja du musst dir auch netzwerktechnisch mal vor Augen führen was für einen Quatsch du da auch machst.
Na ja du musst dir auch netzwerktechnisch mal vor Augen führen was für einen Quatsch du da auch machst.
Lernen kann somit auch so aussehen wie ich es mache.
