2 Netzte mit identischem Subnet verbinden (Bridgen)

NOCling

@gtrdriver said in 2 Netzte mit identischem Subnet verbinden (Bridgen):

Aber evtl sollte man auch die Finger von Dingen lassen die man nicht zu 100% versteht ... - andererseits würden wir dann noch Steine kopfen :-)

Also Jens ist zertifizierter Kokosnusspflücker, für den Notfall. Aber er hat auch immer eine Plan B und ne exit Strategie zur Hand.

Jetzt mal im Ernst, man kann mit NAT und Proxy-ARP viel abgefahrenen Scheiß anstellen, aber dafür muss man da auch zu 100% drin stecken.
Ansonsten buddelst du dir ein Loch nach dem anderen und wirst auch in jedes voll rein krachen.

Mag sein das sie IP Änderung vom Server nicht einfach ist, aber das ist das mindeste.
Clients die weiter mit der alten Server IP sprechen wollen kannst du per NAT auf die neue real IP umbiegen.
Klar kann man das auch mit double NAT wieder zurück biegen, aber das macht dann bei der Fehlersuche ne ganz andere Nummer draus.

Zudem kannst du das nutzen und gleich mal ein schönes neues Netzkonzept auf zu stellen.

Das ist also ne Chance das mal richtig schön mit Struktur neu zu machen.

JeGr

@gtrdriver said in 2 Netzte mit identischem Subnet verbinden (Bridgen):

auf beiden Seiten des Tunnel mit ihren 192.168.0.0/24 Adressen erreichen können.

Nein, das hatte ich mehrfach gesagt, dass das NICHT geht. Das funktioniert nicht mit Routing. NIE. Weil kein Gateway weiß was es mit dem Kram machen soll und wo es nun hin soll. Und Bridging was immer wieder gemurmelt wird, klappt ebenfalls bei deinem Szenario nicht, denn wie soll dann die A oder B Seite entscheiden WO sie raus ins Internet gehen. Auf beiden Seiten gibt es Geräte mit der gleichen IP, das kann NIE funktionieren. Bridging kann nur klappen, wenn es keine Duplikate auf beiden Seiten gibt und die Rechner auf der einen Seite dann ihr eigenes Gateway eingetragen haben (bspw. A: 10.0.0.1 und B: 10.0.0.254 und man hat dann die Rechner/Server auf jeder Seite entsprechend konfiguriert, dass die A Kisten .1 und B Kisten .254 als GW drin haben).

Andernfalls kann Bridging nie sauber funktionieren, deshalb setzt das niemand ein der Lust auf einen Clusterfuck erster Güte im Netz hat ;)
Zwei gleiche Netze verheiraten die auch noch Doubletten als IPs haben geht einfach nicht sinnvoll, die würden sich ständig mit duplicate IP ARPs aus dem Netz bomben.

Darum hatte ich darauf hingewiesen: wenns nur darum geht die Kisten von A nach B zu schaffen und umgekehrt und die IPs nicht zu verändern, so dass sie auf der anderen Seite funktionieren und man will dann auf beide Seiten zugreifen, geht das nur, wenn man auf die jeweils andere Seite mit nem anderen IP Range zugreift. Und um den nicht tatsächlich konfigurieren zu müssen, kann man mit nem Doppel-NAT arbeiten. Das ändert aber nichts dran, dass man um von A nach B zu kommen die B Seite nicht mit 192.168.0(!) sondern mit 192.168.2.x aufrufen muss.

Cheers

gtrdriver

@jegr @NOCling

Hallo zusammen - bitte nicht falsch verstehen - ich wollte hier niemand zu nahe treten und wenn ich "genervt" habe dann möchte mich mich entschuldigen.

Habe jetzt verstanden was mit dem "umbiegen" des IP Adressbereichs gemeint war - danke nochmals für die Ausführungen.

2 Anmerkungen noch:

Ich hätte kein Problem damit die Server IP´s zu ändern und auch nicht an den 60 Clients.. Aber so ein schlauer Programmierer hat die Subnet Range fix in den Code eingebettet was die Server2Server Anfragen angeht ... Bei 2 Anwendungen sogar die exakten IP Adressen - warum - ich weiß es nicht !

Zudem geht es bei diesem "Konstrukt" auch nicht um eine Produktiv Umgebung für alle Ewigkeit sondern um eine Art "Betatest" wie es sich mit verteilter infrastruktur arbeiten lässt - der Nächste Schritt wäre dann sämtliche Server Hardware von Standort A auf B umzuziehen...

Aber wie schon beschrieben danke nochmals für die Ausführungen und Tipps - bin wieder ein Stückchen schlauer ... :-)

NOCling

@gtrdriver said in 2 Netzte mit identischem Subnet verbinden (Bridgen):

Aber so ein schlauer Programmierer hat die Subnet Range fix in den Code eingebettet was die Server2Server Anfragen angeht

Dann soll er das durch einen FQDN ersetzen, den kannst du dann auf jeder Seite mit Split DNS oder DNS Doctoring umschreiben wie du willst.

viragomann

@gtrdriver said in 2 Netzte mit identischem Subnet verbinden (Bridgen):

Ich hätte kein Problem damit die Server IP´s zu ändern und auch nicht an den 60 Clients.. Aber so ein schlauer Programmierer hat die Subnet Range fix in den Code eingebettet was die Server2Server Anfragen angeht ... Bei 2 Anwendungen sogar die exakten IP Adressen - warum - ich weiß es nicht !

Nicht schön, sollte aber auch nicht verhindern, dass man die Verbindung nattet.

Vielleicht wäre es hilfreicher, wenn du erklären würdest, was worauf und unter welchen Bedingungen zugreifen können muss. Clients aus Server und das Programm, das die Clients dafür nutzen hat die feste IP, oder Server auf Server oder das Programm am Server kann nur von einer bestimmten IP antworten?
Bislang hast du einfach nur die Vorgabe gemacht, beide Seiten müssen denselben IP Range haben, und das ist ziemlich schwierig.

gtrdriver

@viragomann

Hallo

am einfachsten beschreibe ich die Situation wie sie jetzt ist:

Standort A (Rechenzentrum)
Mehrere Server + 1 Pfsense - alle im gleichen LAN 192.168.0.0/24
Die Pfsense dort fungiert als router Firewall und Openvpn Server für die Außenstandorte

Die Außenstandorte (10 Standorte) greifen via Pfsense und Openvpn auf diese "Serverlandschaft" per openvpn Client zu an jedem Standort sind 5-10 Endgeräte welche auf alle Server an Standort A zugreifen müssen (192.168.0.0/24)

Das ist der aktuelle Status - nun sollen einzelne Server von Standort A auf Standort B (ebenfalls RZ) umziehen - ohne dass sich für die Außenstandorte (aus Netzwerksicht) noch für die Server untereinander etwas "ändert"....

Ich behaupte nach wie vor ein layer2 Bridging - mit all den Folgen - wäre wohl für diese nicht dauerhaft produtive Umgebung wohl das beste... - aber davon raten ja alle ab ...

Und wenn es über NAT - etc.. nicht oder nur mit 1000 Verbiegungen umsetzbar ist dann "geht es halt einfach nicht" und wir müssen den Plan fallen lassen ...

viragomann

@gtrdriver said in 2 Netzte mit identischem Subnet verbinden (Bridgen):

nun sollen einzelne Server von Standort A auf Standort B (ebenfalls RZ) umziehen - ohne dass sich für die Außenstandorte (aus Netzwerksicht) noch für die Server untereinander etwas "ändert"....

D.h. die Server sollen nun sukzessive übersiedelt werden?
Und der Zugriff mittels derselben IP muss auch zwischen A und B möglich sein?

Wenn der Zugriff nur die Geräte von außen betrifft, sehe ich mit NAT kein Problem.

Aber deine Erläuterung geht auf die Software mit den hard-codeten IPs nicht ein, die vielleicht der Showstopper ist.

Ich behaupte nach wie vor ein layer2 Bridging - mit all den Folgen - wäre wohl für diese nicht dauerhaft produtive Umgebung wohl das beste... - aber davon raten ja alle ab ...

Mag sein, dass auch das eine Lösung wäre. Allerdings gibt es hier wenig Erfahrung dazu. Die Leute, die mit der Technik vertraut sind und hier oft mitlesen, suchen bessere Alternativen.
Erfolgsmeldungen zu OpenVPN Setups im TAP-Mode habe ich hier schon ein paar mal gelesen.

gtrdriver

@viragomann

Hallo - ja - das ist richtig da ich nicht weiß ob ich das durch bekomme, die hard vercodeten IP´s ändern zu lassen ... - ich lass das grad klären - aber aktuell schauts eher nicht danach aus ..

Bezüglich dem Bridging habe ich die letzten Tage auch nochmals intensiv gesucht - finde aber komischerweise nur Anleitungen welche eine Einzel - Client to NET Bridge beschreiben

z.b: https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-bridged.html

Zudem habe ich im englischsprachigen Ovpn Forum hier einen Post gemacht:

https://forum.netgate.com/topic/171687/pfsense-2-5-2-bridge-tap-server-bridge-dhcp-is-greyed-out?_=1651244502392

Da die beiden Felder aus gegraut bleiben - wobei das eher "spielen" war da die Anleitung ja keine Net2NET Kopplung beschreibt sondern eine Einzelclient 2 Net via TAP...

BTW: so gruselig wie es sich mit dem TAP Bridging anhört (in einem normalen Netzwerk mit zig clienten) - ich glaube in der Konstellation hier dass das gar nicht so dramatisch wäre - zum einen ist die WAN Verbindung zwischen beiden Standorten SEHR performant zum anderen sind das nicht 254 Geräte sondern sagen wir mal 15 Clienten auf Seite A und 5 auf Seite B da sollte gar nicht so viel Overhead zusammen kommen ...

viragomann

@gtrdriver said in 2 Netzte mit identischem Subnet verbinden (Bridgen):

Bezüglich dem Bridging habe ich die letzten Tage auch nochmals intensiv gesucht - finde aber komischerweise nur Anleitungen welche eine Einzel - Client to NET Bridge beschreiben

Ich würde meinen, dass das nicht wirklich was anderes ist, aber man sucht eben lieber bessere Lösungen für eine solche Kopplung. Und ich habe auch noch immer nicht verstanden, warum keine andere Lösung möglich sein sollte.

Zudem habe ich im englischsprachigen Ovpn Forum hier einen Post gemacht:

https://forum.netgate.com/topic/171687/pfsense-2-5-2-bridge-tap-server-bridge-dhcp-is-greyed-out?_=1651244502392
Da die beiden Felder aus gegraut bleiben

OpenVPN im TAP-Mode hat da wohl auch keine höhere Fandichte.

Da die beiden Felder aus gegraut bleiben

Ich weiß nicht mal, wo diese Felder zu finden sind.

gtrdriver

@viragomann

Hi

Zu 1: ja ich sehe schon dass das nicht so sehr verbreitet ist

Zu 2: Wenn ich die IP´s einfach ändern könnte dann könnte ich mir ja das ganze hier sparen da ich dann ja bei dem Netzwerk an Standort B einfach ein anderes Subnet machen würde und dann eine openvpn NET2NET Kopplung - ganz klassisch ... - aber daran scheitert das aktuell

Zu 3: Wenn du im Openvpn Setup ein TAP Device anlegst - speicherst und das nochmals öffnest - dann sind die Felder auf "TAP" angepasst - dann tauchen die auf ...

viragomann

@gtrdriver said in 2 Netzte mit identischem Subnet verbinden (Bridgen):

Wenn ich die IP´s einfach ändern könnte dann könnte ich mir ja das ganze hier sparen da ich dann ja bei dem Netzwerk an Standort B einfach ein anderes Subnet machen

Vielleicht wäre es ein Weg, das Subnetz in 2 aufzuteilen und den einen Teil dann auf B zu schaffen und zu routen.
D.h. mit der IP-Änderung kannst du gleich auf A schon loslegen, die Geräte für B bspw. in die obere Hälfte, jene die vorerst in A bleiben in die untere.
Mit der Verlegung musst du dann auch die Subnetzmaske ändern.

Aber das läuft ebenso auf unterschiedliche Netze hinaus, zwischen du welchen dann routen könntest.

Wenn du im Openvpn Setup ein TAP Device anlegst - speicherst

Ich denke, bis zum letzten Punkt hatte ich mich noch nicht vor gewagt.

gtrdriver

@viragomann

Am Montag bekomme ich die Info ob IP Änderungen möglich sind oder besser möglich gemacht werden....

Dann schau ma weiter.....

Es gibt Dinge die man sich leichter vorgestellt hat....

gtrdriver

@JeGr @NOCling @viragomann

Hallo zusammen
Da ich bis Montag quasi nix machen/entscheiden kann habe ich in meiner Test Umgebung mal das Layer2 TAP Bridging des Todes ausprobiert.....

Vorgegangen nach dieser Anleitung:

https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-bridged.html

Beide Netze haben 192.168.0.0/24
Pfsense in Netz A hat 192.168.0.1
Pfsense in Netz B hat 192.168.0.2

Beim Client halt die entsprechende Config auf der Gegenseite.
Siehe das die Interfaces werden "grün" - ok - dachte ich - schau mer mal weiter ...
Ein Ping auf der einen Seite führte auf beiden Seiten im Traffic Stat des entsprechenden Ovpn inteface zu reaktionen - aber kein Ping.

Ok - wirklich eher raten als ernsthaft wissen was sache ist ... mal in das Ovpn Interface folgende Basis Regel rein:

Und siehe da - die beiden Pfsensen können sich gegenseitig anpingen:

Hab mich schon irrsinnig gefreut dass ich überhaupt so weit gekommen bin - ohne jetzt zu wissen ob das so richtig ist ...

Dine Pings gehen auch definitiv über die TAP Bridge sieht man am Traffic Monitor...

Leider kann ich sonst keine anderen Systeme im Besagten Netz von der anderen Seite erreichen ....

Ich weiß dass die hier vorherrschende Meinung ist dass das mit der TAP Bridge nicht optimal ist - ich würde es dennoch gerne zumindest versuchen ...

Hat jemand noch eine idee warum ich nur die Pfsensen selbst erreiche auf der anderen Seite aber sonst keinen der Server im 192.168.0.0/24 Netz ?

micneu

@gtrdriver die Geräte die du erreichen willst nutzen ein anderes Standard Gateway?
Mache es dir doch einfach buche dir doch einen Dienstleister der dich in dem Thema unterstützt, da du nicht so fit in Netzwerk Technik bist und wenn das für ein Unternehmen ist währe es besser als wenn man irgend wann in d n Medien liest das irgend welche Daten öffentlich erreichbar waren Wall ein Admin was falsch gemacht hat. Hier im Forum tummeln sich einige rum.

viragomann

@gtrdriver
Ich würde vermuten, dass die Broadcasts nicht über die Verbindung kommen, also dass keine echte L2_Verbindung besteht und damit die ARP-Requests nicht auf der anderen Seite ankommen.

Hast du auf beiden Seiten den TAP-Mode gewählt?

Um es zu überprüfen, mach ein Packet Capture auf beiden Seiten, filtere nach ARP Protokoll, während du eine IP pingst. Die Pakete sollten auf beiden Seiten zu sehen sein.

gtrdriver

Hallo zusammen

nachdem ich heute mit der SW Entwicklung gesprochen hatte wird klar dass es vorerst keine Änderungen an der Software gibt.

Da mir das ganze Bridging auch nicht ganz geheuer ist und ich bisher NIEMANDEN gefunden habe der das mit Pfsense bisher erfolgreich eingesetzt hat (NET2NET) habe ich das ganze Thema jetzt erst mal auf Eis gelegt.

Mir ist die Zeit zu schade hier Experimente zu machen welche man eher als Im Trüben fischen bezeichnen muss als wirkliches Testen....

Wenn hier irgendwer zufällig das Posting liest und (gerne auch gewerbliches) Interesse hat mich hier zu unterstützen dann gerne bei mir melden.

Grüße und nochmals Danke !

GTR

gtrdriver

Hallo zusammen

ich wollte hier noch eine kurze Rückmeldung geben - auch wenn das nicht direkt mit pfsense zusammen hängt interessiert es evtl doch mal jemanden der eine ähnliche Situation hat.

Ich bin durch zufall auf eine Software gestoßen namens "Softether" (https://www.softether.org/)

Dieses bietet ein Layer2 Bridging welches dazu noch extrem gute konfigurierbar ist UND sich über einen bestehenden VPN Tunnel (Openvpn) legen lällst.

Das erfüllt jetzt genau unseren Zweck da sich das ganze Konstrukt vollständig Virtualisieren und skalieren lässt und nichts über das öffentliche WAN läuft da die Verbindung zwischen den beiden Softether VM´s über einen PFSENSE OpenVPN Tunnel läuft.

DAmit kann man nun ganz prima ein separates Netzwerk Segment mit z.b: 4 Servern an ein entferntes im RZ transparent anbinden.

Die Performance ist überraschend gut - der Overhead üverraschend gering. Aufgrund der Architektur und der Konfig Möglichkeiten würde ich sagen es ist genau so sicher wie eine Layer2 S2S Bridge...

Wie gesagt - nur als Info falls jemand sowas mal benötigt - und es ist Freeware (Universität aus Japan)

gtrdriver

Und nochmals guten Abend in die Runde...

Da mir das ganze keine Ruhe mehr gelassen hat warum das mit PFSENSE nicht geht habe ich heute mit 2 Hardware PFSense Firewalls in einem kleinen Testaufbau den versuch widerholt und siehe da - da klappt das layer2 over OpenVPN...

Ich hatte die Config noch in einem Versuchsaufbau auf 2 Servern im RZ gespeichert -also hier exakt die gleiche Situation nachgestellt - geht nicht ...

Wollte fast schon wieder aufgeben und stoße zufälligerweise in einem anderen Zusammenhang (da ging es um OpenWRT auf ESXI) auf Mac Spoofing und das das auf ESXI per Default abgeschaltet ist.

Ok - also Mac Sppfing auf den beiden virtuellen NIC´s eingeschaltet und siehe da - LÄUFT !
Ohne Probleme - sofort auf Anhieb - auch DCHP via Bridge läuft sofort ohne mucken...

Also mal schnell ein paar Performance Tests gemacht und auch hier - Beigeisterung - ca. 30% niedriger als mit einer Layer3 S2S Bridge.

Da sich die Bridge in Pfasense als Interface integriert sind hier exakt die gleichen FW Regeln möglich - man kann also ganz wunderbar definieren wer mit wem und wer nicht ...

Nochmals zur Klarstellung - ich würde niemals auf die idee kommen eine klassische S2S Layer3 Verbindung damit zu ersetzten - darum geht es auch nicht - aber für unser Szenario - 3 Server an einem anderen standort zu betreiben -- mit quasi transparenter Netzwerk Bridge ist das jetzt optimal

Wenn jemand hier mal Bedarf hat - gerne melden.

Ansonsten - allen einen schönen Abend