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.
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.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-Key: 206293
Url: https://administrator.de/contentid/206293
Ausgedruckt am: 29.03.2024 um 08:03 Uhr
8 Kommentare
Neuester Kommentar
Hi,
Wieso zwei Verbindungen, ein OpenVPN zum verbinden beider Netze.
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
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
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.
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
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...
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...
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
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
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 !
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 !
als NetBEUI Standard für Windows-Netzwerke war.
lks