istike2
Goto Top

Zwei netzwerke mit OpenVPN verbinden

Hallo,

ich wollte anhand Aquis Anleitung zwei Niederlassungen mit OpenVPN vernetzen:

OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router

LAN1: 10.1.1.0
LAN2: 10.1.2.0

LAN1 hat bereits jetzt eine pfSense-Installation wo OpenVPN sehr stabil läuft. Jetzt am WE sollte ich die 2. Installation hinkriegen.

wenn ich die Anleitung richtig verstehe, werden die Niederlassungen auch als OVPN-Clients eingerichtet. Jeweils ein Server ist natürlich in beiden Fällen installiert, damit die sonstigen Clients unabhängige Verbindungen zu den einzelnen Netzwerken aufbauen können.

Meine Fragen:

- Werden in beiden pfSense-Installs jeweils ein Client für diesen Zweck erstell oder reicht es wenn z. B. LAN2 einen Client für die Verbindung zu LAN1 hat?

- Sollten die OpenVPN-IP-Einstellungen bei beiden Verbindungen unterschiedliche sein? (Ja, nehme ich mal an). Also z. B. 172.16.1.0 und 172.16.2.0.

Danke sehr.

Gr. I.

Content-Key: 206293

Url: https://administrator.de/contentid/206293

Ausgedruckt am: 29.03.2024 um 08:03 Uhr

Mitglied: orcape
orcape 10.05.2013 um 15:56:08 Uhr
Goto Top
Hi,

Wieso zwei Verbindungen, ein OpenVPN zum verbinden beider Netze.
LAN1 hat bereits jetzt eine pfSense-Installation wo OpenVPN sehr stabil läuft.
Innerhalb Deines LAN1 ein OpenVPN ?
pfSense LAN1 = OpenVPN-Server
pfSense LAN2 = OpenVPN-Client

Tunnel-Netz 172.16.2.0/24
...und schon sollten beide Netze verbunden sein.

Oder ich habe bei Deiner etwas diffusen Beschreibung etwas falsch verstanden.

Gruß orcape
Mitglied: Lochkartenstanzer
Lochkartenstanzer 10.05.2013 aktualisiert um 18:00:33 Uhr
Goto Top
Zitat von @orcape:
Hi,

Wieso zwei Verbindungen, ein OpenVPN zum verbinden beider Netze.
> LAN1 hat bereits jetzt eine pfSense-Installation wo OpenVPN sehr stabil läuft.
Innerhalb Deines LAN1 ein OpenVPN ?
pfSense LAN1 = OpenVPN-Server
pfSense LAN2 = OpenVPN-Client

Tunnel-Netz 172.16.2.0/24
...und schon sollten beide Netze verbunden sein.

Oder ich habe bei Deiner etwas diffusen Beschreibung etwas falsch verstanden.


Moin

Ich meine noch herausgelesen zu haben, daß er mit Clients sich auch an LAN2 verbinden will. Dann würden da Client und Server notwendig sein.

lks
Mitglied: aqui
aqui 10.05.2013 um 23:36:38 Uhr
Goto Top
Und Ich meine noch herausgelesen zu haben, daß er eine LAN zu LAN sprich Site to Site Vernetzung machen will.
Leider hat er die Frage nicht beantwortet WIE die bestehende OVPN Installation arbeitet.
Nehmen wir mal an als Server, was ja am meisten Sinn macht.
Dann musst der 2te Standort nur als Client definiert werden. Das interne OVPN Netzwerk kann natürlich beibehalten werden.
Der Rest steht im Tutorial...
Mitglied: ente
ente 13.05.2013 aktualisiert um 19:48:34 Uhr
Goto Top
also ich habe ähnliches mit der Endian-Firewall (Community-Edition reicht, darin ist auch openVPN enthalten) gemacht, wir haben einfach die 2 Standorte gebridgt ... ein IP-Bereich für alle und nur auf einer Site DHCP, DNS usw. - selbst die IP-Telefone bekommen alles über den Tunnel von der Tel-Anlage ... ist genial einfach.
Es ist so eingestellt, das der kleinere Standort sich als Client bei dem openVPN-Server anmeldet.
Um wie viele Clients geht es überhaupt auf beiden Seiten ... wir haben auf den einen Standort vielleicht 20 Clients ... der andere hat ca. 50 Clients.
Einwahl per openVPN-Client klappt auch perfekt.


Herzliche Grüße

Heiko
Mitglied: aqui
aqui 13.05.2013, aktualisiert am 17.05.2013 um 15:33:49 Uhr
Goto Top
Vorsicht !
Von einem obigen Bridging Szenario kann man nur dringenst abraten ! In einer WAN / VPN Verbindung mit begrenzter Bandbreite ist das extrem kontraproduktiv. Auch die OVPN HowTos sprechen da eine sehr deutliche Sprache !
Es gilt der goldene Grundsatz den jeder noch so kleine Netzwerker kennt: "Bridge where you must, route where you can !"
In einem o.g. Bridging Szenario kumuliert der gesamte Broad- und Multicast Traffic beider Seiten im VPN Tunnel und belastet die Performance erheblich. Gerade in geschwätzigen Winblows Netzwerken ist das nicht zu unterschätzen !
So ein Design mag im einzelnen funktionieren für 2 Nachbarn oder Freunde privat zum Spielen ist aber nicht skalierbar für Firmen und birgt erhebliche Performance Risiken und das gerade beim Voice Betrieb. Ein absolutes No Go also im Firmenumfeld und Firmennetzen !
Zudem ist es auch vollkommen überflüssig, da Telefone, DHCP, DNS usw. heutzutage vollkommen problemlos in gerouteten Umgebungen funktionieren.
Solche Designs kommen aus der Steinzeit des Netzwerkens oder machen Administratoren die kein kein Wirkliches IP und Netzwerk Know How haben, sorry.
Klares Fazit: Finger weg von VPN Bridging Szenarien in solchen Umgebungen !
Mitglied: Lochkartenstanzer
Lochkartenstanzer 13.05.2013 um 20:47:28 Uhr
Goto Top
Zitat von @aqui:
Solche Designs kommen aus der Steinzeit des Netzwerkens ...

als NetBEUI Standard für Windows-Netzwerke war. face-smile

lks
Mitglied: ente
ente 17.05.2013 aktualisiert um 15:11:13 Uhr
Goto Top
Danke Aqui für den Hinweis ... Kritik ist angekommen - bin ich immer dankbar dafür.

werde ich mal testen und dann wird umgesetzt bzw. auf geroutet geändert.
Würde Subnetting reichen ... vermute mal ja.

Herzliche Grüß und schöne Pfingsttage

Heiko
Mitglied: aqui
aqui 17.05.2013 aktualisiert um 15:32:12 Uhr
Goto Top
Ja, alle Arten von Subnetting reichen da vollauf. Hauptsache du bekommst 2 unterschiedliche IP Netze und kannst routen face-wink