2 Netzte mit identischem Subnet verbinden (Bridgen)
-
Hallo zusammen
erstmal - herzliche dank an die Community hier die immer wieder hilft und sich wirklich Mühe gibt - ein ganz dickes Lob !
Zu meinem Anliegen
Ich setzte PFSENSE zusammen mit OpenVPN bisher meist zur Net2Net Kopplung mit unterschiedlichen Subnet Adressen ein (Layer3 wenn ich mich nicht Täusche)
Lan1 Zentrale PFsense 192.168.0.x
Außenstelle1: Pfsense 192.168.10.x
Außenstelle2: Pfsense 192.168.11.x
usw...Entsprechende Anleitungen findet man im Netz zu genüge das klappt auch alles wunderbar mit OpenVpn ist schnell Performant und einfach zu verwalten.
Nun habe ich hier folgende Situation:
Nehmen wir wieder das Beispiel
Lan1 Zentrale 192.168.0.x/24 - also IP Bereich 192.168.0.1 - 192.168.0.254
Hier laufen diverse Server Anwendungen auf diversen Maschinen - die meisten Virtualisiert - das spielt hier aber erstmal keine Rolle. - ca. 30 IP Adressen sind hier vertreten.
Diese Server müssen sich nun "untereinander" verständigen können - die eingewählten Außenstellen müssen aber auch auf dieses netz via OpenvPN zugreifen.
Das ist alles Standard und nix besonderes.Nun soll/muss (nicht meine Idee) für einen begrenzten Zeitraum ein Teil dieser Server an einen anderen Standort umziehen es dürfen sich aber die IP Adressen NICHT ändern.
Beide Standorte können an deren "Öffentlicher IP / dem WAN) eine PFSENSE bekommen soweit so gut. - aber der IP Adressbereich von LAN wäre der gleiche und beide Netzte - incl der Außenstellen) soll miteinander sprechen können.
Nach einigen Recherchen habe ich hier OpenVpn TAP gefunden - welches ein Bridging der beiden Netzwerke machen soll - zum einen wird aber überall im Netz davon STRIKT abgeraten bezüglich des Protokoll overheads, der Performance und vielen anderen Gründen.
Weiterhin finde ich keine Anleitung welche eine TAP Net2Net Kopplung beschreibt.
In den Netigate Dokumenten finde ich nur eine Anleitung welche eine TAP Net2Client Config beschreibt.Ich habe hier im Forum im OpenVPN Bereich mal einen Post gemacht da es z.b: nicht möglich ist bei TAP das DHCP Sharing zu aktivieren - aber hier bisher leider keine Antwort bekommen.
Zudem habe ich in einer Testumgebung mal mit so einer Konfig rumgespielt - bekomme das aber nicht zum laufen.
Irgendwie ist mir diese Art der LAN Kopplung auch zu gruselig....
Hat jemand sonst noch eine idee wie man sowas umsetzten könnte ?
Gruß
GTR -
@gtrdriver said in 2 Netzte mit identischem Subnet verbinden (Bridgen):
Nach einigen Recherchen habe ich hier OpenVpn TAP gefunden - welches ein Bridging der beiden Netzwerke machen soll - zum einen wird aber überall im Netz davon STRIKT abgeraten bezüglich des Protokoll overheads, der Performance und vielen anderen Gründen.
Schon allein wegen Broadcast Storms zwischen den Netzen oder dem sehr einfachen Fall dass man die gleiche IP auf beiden Seiten hat - gerade wenn man Kisten von A nach B und zurück schleppt - will man das als Netzwerker aber so gar nicht haben!
@gtrdriver said in 2 Netzte mit identischem Subnet verbinden (Bridgen):
Irgendwie ist mir diese Art der LAN Kopplung auch zu gruselig....
Zurecht :)
@gtrdriver said in 2 Netzte mit identischem Subnet verbinden (Bridgen):
Hat jemand sonst noch eine idee wie man sowas umsetzten könnte ?
Jup, 1:1 NAT für beide Seiten. Das ist das Einzige was IMHO halbwegs gut geht. Aber dann müssen die Seiten damit leben, dass sie die andere Seite nur über einen anderen IP Range erreichen können, die Kisten selbst bekommen davon aber nichts mit.
Seite A und B denken beide, sie sind bspw. 192.168.0.0/24, durch 1:1 NATting auf den Tunnelendpunkten wird aber Seite A -> B zu 192.168.1.0/24 und Seite B zu Seite A zu 192.168.2.0/24.
Spricht also A nach B, kommt bei B der Traffic von .1.x, spricht B zu A kommt bei A der Traffic von .2.x an, in Real haben aber beide Seiten immer noch .0.x und machen ihr Ding vor sich hin.
Das wäre das Einzige, was ich auch Netzwerksicht vertreten könnt, eine Bridge zwischen beiden Enden wird richtig bäh gruselig, denn dazu kommt dann noch die Default Routen Geschichte, dass Seite A ja auch über Sense A ins Netz soll und B über B aber trotzdem alle ihre Konfig behalten sollen... Uiuiui, das geht so richtig böse aus :)
Cheers
-
Hallo
erstmal vielen dank dass du die die "arbeit" gemacht hast auf das zugegeben etwas schräge Thema zu antworten.
Ich hab deinen Post jetzt 3x gelesen so 100% hab ichs noch nicht verstanden.
Das würde bedeuten ich müsste am Lan in der Zentrale in der derzeit die Server stehen auch das Subnet von derzeit 192.168.0.0/24 auf 192.168.1.0/24 ändern - die Clients würden dann aber alle die 192.168.0.xer Adresse behalten ?
Dann ginge da quasi kein DHCP - korrekt ? - denn das würde ja eine IP aus dem 192.168.1.x zuteilen. - oder sehe ich das falsch ?
Vielleicht habe ich das auch vollkommen falsch verstanden !
-
@gtrdriver said in 2 Netzte mit identischem Subnet verbinden (Bridgen):
Dann ginge da quasi kein DHCP - korrekt ? - denn das würde ja eine IP aus dem 192.168.1.x zuteilen. - oder sehe ich das falsch ?
Genau aber der Grund ist falsch. Es ginge kein DHCP über den Tunnel denn der Tunnel würde nur routen, nicht bridgen. Du willst kein Bridging im VPN Tunnel. Nicht wirklich. Daher wäre ein routender Tunnel Standard und gut, aber das klappt ja aus logischem Grund nicht mit 2x gleichen Netzen.
@gtrdriver said in 2 Netzte mit identischem Subnet verbinden (Bridgen):
Das würde bedeuten ich müsste am Lan in der Zentrale in der derzeit die Server stehen auch das Subnet von derzeit 192.168.0.0/24 auf 192.168.1.0/24 ändern - die Clients würden dann aber alle die 192.168.0.xer Adresse behalten ?
Nein, das hatte ich ja beschrieben. Beide Seiten bleiben wie sie sind auf 192.168.0.0/24. Alles ist fein für die beiden Netze selbst. Dann baut man einen VPN Tunnel zwischen den beiden Seiten auf. Immer noch alles OK - nur dass man jetzt nichts routen kann weil 2x gleiches Netz, korrekt? Gut.
Hat man jetzt aber den Tunnel bestehen - egal welcher Art OpenVPN oder IPsec - dann kann man darüber ausgehend NATten. Bei IPsec wäre das direkt in der P2 anzugeben, bei OpenVPN kann man das VPN Interface auf beiden Seiten hinzufügen (Interface Assignments) und dann das Interface in 1:1 NAT entsprechend konfigurieren.
Im Prinzip geht man einfach nur her und schwindelt via NAT der anderen Seite was vor.
Seite A: 192.168.0.0/24
Seite B: 192.168.0.0/24
VPN-A: Endpunkt des VPNs
VPN-B: Endpunkt des VPNs<SeiteA> <--> <VPN-A> ====== <VPN-B> <--> <SeiteB>
Man geht dann via Routing + 1:1 NAT oder BiNAT Konfig in der P2 einfach her und definiert bspw. für Seite A:
Wenn Traffic von 192.168.0.0/24 (Seite A) nach 192.168.2.0/24 (existiert eigentlich nicht) will und das an meinem Interface LAN ankommt, dann route es über VPN-A nach Seite B rüber und ändere die Quell-IPs von 192.168.0.x auf 192.168.1.x abWenn du auf Seite A von 192.168.0.111 mit Seite B 192.168.0.222 reden willst, dann adressierst du also nicht an 192.168.0.222, sondern sagst er soll 192.168.2.222 ansprechen. Das kommt bei der Firewall an, wird via Route nach Seite B gepusht und beim Passieren des VPNs wird die Quelle von 192.168.0.x auf 192.168.1.x umgeschrieben. Beim Eintreffen bei VPN-B wird dann das Ziel 192.168.2.222 zurück umgeschrieben auf 192.168.0.222 und da das Paket von 192.168.1.111 kommt (wurde ja beim Eintritt in den Tunnel umgeschrieben) wird das Paket dann an .222 auf Seite B zugestellt und kann beantwortet werden. Der Rückweg läuft dann genauso. Der Host auf B sendet an 192.168.1.111 zurück weil er das Netz nicht kennt -> also ab an das Default Gateway. Die Firewall kennt die Route nach .1.x über das VPN und schiebt es in VPN-B rein. Dort wird der Absender von 0..222 auf .2.222 zurück umgeschrieben. Danach kommt das Paket bei VPN-A an wo das Ziel von .1.111 zurück auf .0.111 geändert wird, was die Firewall dann wieder ordentlich zustellen kann.
Man nutzt also die Netze .1.x und .2.x rein "virtuell" wenn man so will. Die sind nirgends aufgelegt oder konfiguriert, werden aber durch NAT hin und her jeweils umgeschrieben und genutzt und sind so bekannt.
Vielleicht kann mans in der Grafik besser verstehen. Die VPN-IFs sind keine extra Geräte sondern für den Fall OpenVPN oder IPsec VTI bspw. die zugewiesenen Interfaces und deren Gateways die man anlegt und auf denen GeNATtet wird:
-
Hallo jegr - erstmal - super - vielen dank für die viele Arbeit die du dir gemacht hast - nochmals - Herzlichen Dank von mir.
Ich denke ich habs jetzt den grundsätzlichen Ansatz verstanden und auch wie es technisch funktioniert.
Zum Thema DHCP - hier könnte man ja in beiden Teilnetzten (192.168.0.0/24) jweils nen DHCP Server laufen lassen und unterschiedliche "ranges" vergeben - dann wäre das Problem auch schon mal gelöst !
In diesem Zusammenhang habe ich noch 2 Fragen:
1: Nehmen wir mal an ich setzte dieses Konstrukt jetzt so um - dann könnten alle Server an Standort A mit allen Servern an Standort B sprechen und umgekehrt - schon mal sehr gut.
Von den Filialen (Nur nutzer) gibt es zu Standort "A" eine OpenVPN Net2Net Kopplung - klassich mit unterschiedlichen Subnetzen.
Können dann die Geräte in der "aussenstelle" welche sich mit "Server Standort A" verbunden haben (Openvpn) auch die Geräte an "Server Stanort B" erreichen ? - oder muss hier nochmals was extra "gedreht" werden ?
2:Ich würde das jetzt wie gesagt gerne mal antesten und obwohl ich die grundsätzliche Vorgehensweise incl dem Natting verstanden habe fehlt mir jetzt in Bezug auf PfSense jetzt ein wenig der Ansatzpunkt.
Was ich schon mal verstanden habe - ich mache auf beiden Seiten eine OpenVPN Verbindung 1x server 1x Client - OVPN Netzt z.b: 10.1.2.0/30 mit entsprechenden Keys etc. so dass sich die beide verbinden können.
Dann lege ich auf beiden Seiten ein Interface an auf Basis der jeweiligen OpenVPN Verbindung und gebe dem Interface jeweils 10.1.2.1/30 und 10.1.2.1/30
Dann lege ich ein 1:1 NAT an zwischen dem entsprechenden LAN und dem Interface des OpenVPN
soweit richtig ? Wenn ja - bitte noch die korrekten Einstellungen des NAT.
-
@gtrdriver said in 2 Netzte mit identischem Subnet verbinden (Bridgen):
2:Ich würde das jetzt wie gesagt gerne mal antesten und obwohl ich die grundsätzliche Vorgehensweise incl dem Natting verstanden habe fehlt mir jetzt in Bezug auf PfSense jetzt ein wenig der Ansatzpunkt.
Theoretisch ja.
@gtrdriver said in 2 Netzte mit identischem Subnet verbinden (Bridgen):
Zum Thema DHCP - hier könnte man ja in beiden Teilnetzten (192.168.0.0/24) jweils nen DHCP Server laufen lassen und unterschiedliche "ranges" vergeben - dann wäre das Problem auch schon mal gelöst !
Müsste doch jetzt auch schon der Fall sein, dass es getrennte DHCPs gibt. Daran ändert sich dann nichts. Und die IP Ranges sind dann eigentlich irrelevant weil sie sich nicht mehr überlagern.
@gtrdriver said in 2 Netzte mit identischem Subnet verbinden (Bridgen):
Dann lege ich auf beiden Seiten ein Interface an auf Basis der jeweiligen OpenVPN Verbindung und gebe dem Interface jeweils 10.1.2.1/30 und 10.1.2.1/30
OpenVPN Tunnel aufbauen mit irgendeinem Transfernetz. Kann man 10.1.2.0/30 nehmen, kann auch was anderes sein. Die eine Seite wird .1, die andere .2.
Das OVPN Interface in den Interface Assignments zuweisen und aktivieren. Danach OVPN auf beiden Seiten nochmal restarten, damit das Interface sauber ist. Wenn das läuft, müsste in System/Routing das GW für die OVPN Verbindung auftauchen.Dann kann man Regeln basteln und 1:1 NAT bauen.
-
Hallo - sorry - ich hab wohl irgendwo ei Brett vorm Kopf ...
Testweise mal an einem der Server Standorte und an einer Virtuellen PFsense mit öffentlicher IP was aufgesetzt - OpenVPN Tunnel eingereichtet - connectet - Interfaces auf die jeweiligen Ovpn Verbindungen eingerichtet - Ovpn neu gestartet schaut dann so aus:Standort 1:
Standort2:
Tunnel Netzwerk OpenVPN Verbindung Standort1:
Tunnel Netzwerk OpenVPN Verbindung Standort2:
Bei Remote Netzwerk habe ich nichts drin stehen (auf beiden Seiten)
Ich dachte bisher das Transfer Netzwerk beim OpenVPN muss vom Subnet auf beiden seiten immer gleich sein... - Wo bekomme ich dann das ".1.x" und das ".2.x" Subnet rein ?
Im erstellten Interface kann ich ja nix mehr einstellen ...
Entschuldige die Nachfragerei - das ist Neuland für mich ...
-
Hi,
@gtrdriver said in 2 Netzte mit identischem Subnet verbinden (Bridgen):
Bei Remote Netzwerk habe ich nichts drin stehen (auf beiden Seiten)
nein, ohne Routen geht natürlich nichts auf die andere Seite.
Jens hat ja oben die nötigen Routen in die Grafik eingetragen und dies geht über "Remote Networks" in der OpenVPN Konfiguration.
Also auf A muss da "192.168.2.0/24" rein und auf B "192.168.1.0/24".Und dann musst du genau diese Netze auf der jeweiligen Remoteseite auf das LAN mappen.
Ich habe das Gefühl, dass dir auch nicht klar ist, dass du mit diesem Setup die Hosts der Remoteseite nicht über ihre tatsächliche IP ansprechen kannst, sondern eben nur über die NAT IP.
Aus deinem ersten Post hatte ich den Eindruck, dass das nicht erwünscht wäre.Ich dachte bisher das Transfer Netzwerk beim OpenVPN muss vom Subnet auf beiden seiten immer gleich sein... - Wo bekomme ich dann das ".1.x" und das ".2.x" Subnet rein ?
Transfer Netzwerk? Das ist das Tunnel Netz, also 10.1.2.0/30.
Ich vermute, das meinst du hier aber nicht, oder? -
Hi - ok - dann habe ich es wohl falsch verstanden ...
Wenn ich layer2 Brdging nicht einsetze um 2 identische Subnetzte zu verbinden dachte ich das ist der richtige weg der hier skiziert wurde - auch wenn ich offen gesprochen irgendwo zwischendrin mal gedanklich ausgestiegen bin.
Soweit hatte ich noch verstanden dass es bezüglich des Routings gewollt ist 2 zusätzliche Transfer Netzte zu nutzen und dann mittels NAT das so umzubieteh dass sich alle Server im Netz 192.168.0.0/24 auf beiden Seiten des Tunnel mit ihren 192.168.0.0/24 Adressen erreichen können.
Aber evtl sollte man auch die Finger von Dingen lassen die man nicht zu 100% versteht ... - andererseits würden wir dann noch Steine kopfen :-)
-
@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.
-
@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
-
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 ... :-)
-
@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.
-
@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. -
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ßenstandorteDie 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 ...
-
@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. -
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 ...
-
@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 bleibenOpenVPN 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.
-
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 ...
-
@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.