Standortvernetzung mit OpenVPN Server/Client machbar?

Started by Canzler, March 01, 2019, 03:20:25 PM

Previous topic - Next topic
Hallo zusammen,

ich möchte auf Basis von Opnsense 19.1.1 zwei Standorte miteinander verbinden.
ABER: an einem Standort soll Opnsense kein Router sondern auch ein LAN-Client sein.

Hintergrund:
Wir haben eine kleine Firma übernommen und möchten deren Standort in unser Netz integrieren, dies soll aber Zug um Zug erfolgen.
Im ersten Schritt sollen die dortigen Kollegen eine -absichtlich- nur im Intranet erreichbare Zeiterfassung und Wiki (also beides Port 80) unseres Hauptstandortes nutzen können.
Um mir die Installation von OpenVPN auf jedem Rechner zu sparen, möchte ich eine Opnsense als Client (=VPN Gateway) aufsetzen.
Auf den Desktops setze ich dann eine Route mit Opensense als Ziel Gateway.

An deren aktueller Infrastruktur soll möglichst wenig verändert werden (=kosten) da in einem halben Jahr an einem neuen Standort zusammengezogen wird.

Hier die Details:
Hauptstandort: 192.168.1.0/24
Nebenstandort: 192.168.200.0/24
Tunnelnetz: 192.168.255.0/24

Ich richte für den Nebenstandort eine Opnsense mit 2 IPs im internen Netz ein:
LAN: 192.168.200.240 und WAN: 192.168.200.250
Opnsense Firewall (ist vermeintlich) komplett aus.
Mit IPSec bin ich gescheitert, also habe ich es mit OpenVPN und P2P-PSK Mode versucht:
Portweiterleitung von deren bestehendem Router 1194 UDP auf die Opnsense.
Die Opnsense am Hauptstandort hat eine feste externe IP.
Der Tunnel wird erfolgreich aufgebaut. Ich kann per Konsole die Opensense gegenseitig über deren Tunnel-IP-Adresse anpingen.
Aber in die jeweiligen lokalen Netze oder auch an die lokalen Opensense IPs komme ich nicht per Ping.

Von anderen Clients aus dem LAN kann ich nur die Tunnel IP der lokalen Opensense anpingen.
Beispiel: Ich erreiche über einen Client im Nebenstandort 200er Netz die Opensense über 255.1 aber nicht die Opnsense am Hauptstandort 255.2 geschweige denn dort ein Gerät im 1er Netz.

Auf den Clients sind folgende Routen gesetzt:
route add 192.168.1.0 mask 255.255.255.0 192.168.200.240
route add 192.168.255.0 mask 255.255.255.0 192.168.200.240

Wo liegt der Denkfehler?

Haste bei IPSec die FWRules eingerichtet für die Netze und alle Netze bei jeder jeder FW eingetragen?

Sprich:
- Unter die FWRules von IPSec mal ein All:All machen (nur zum testen! damit wird jeder Traffic auf dem IPSec-Interface durchgelassen)
- In der IPSec-Config jeweils die entfernten Netze eingetragen, die man darüber erreichen soll (die muss auf beiden FWs passieren, damit dies funktioniert)

Kann heute Abend meine Config schicken.
Ist einfacher zu erklären.

Trotzdem hier die offizielle Anleitung von OPNSense: https://docs.opnsense.org/manual/how-tos/ipsec-s2s.html

Vielleicht hilft die dir weiter.
Bei mir hat es so einwandfrei getan.

Wichtig! Alle Standorte brauchen eine fixe IP!


Gesendet von iPhone mit Tapatalk

March 01, 2019, 04:19:13 PM #2 Last Edit: March 01, 2019, 04:21:29 PM by chemlud
Quote from: MBG on March 01, 2019, 03:23:39 PM

Wichtig! Alle Standorte brauchen eine fixe IP!

Nein, mit einem DynDNS-Service geht das auch mit dynamischer Adresse

Zwei Dinge:

1. Outbound NAT sollte auf jeder Seite eine Regel für das Netzwerk auf der ANDEREN Seite des Tunnels haben (interface WAN).
2. openVPN Firewall tabs: Nicht vergessen entsprechende Regeln zu setzen, um den Verkehr zu erlauben (Source: das ENTFERNTE Netzwerk, Destination: die Resource im lokalen Netzwerk, die erreicht werden soll.
kind regards
chemlud
____
"The price of reliability is the pursuit of the utmost simplicity."
C.A.R. Hoare

felix eichhorns premium katzenfutter mit der extraportion energie

A router is not a switch - A router is not a switch - A router is not a switch - A rou....

Quote from: chemlud on March 01, 2019, 04:19:13 PM
Quote from: MBG on March 01, 2019, 03:23:39 PM

Wichtig! Alle Standorte brauchen eine fixe IP!

Nein, mit einem DynDNS-Service geht das auch mit dynamischer Adresse.

Zwei Dinge:

1. Outbound NAT sollte auf jeder Seite eine Regel für das Netzwerk auf der ANDEREN Seite des Tunnels haben (interface WAN).
2. openVPN Firewall tabs: Nicht vergessen entsprechende Regeln zu setzen, um den Verkehr zu erlauben.


Nur kann mit mit OpenVPN (Client-To-Site) kein Site-To-Site-VPN aufbauen...
Dazu benötigt man IPSec


Gesendet von iPhone mit Tapatalk

Ähh, das mache ich seit Jahren, warum sollte das nicht gehen?
kind regards
chemlud
____
"The price of reliability is the pursuit of the utmost simplicity."
C.A.R. Hoare

felix eichhorns premium katzenfutter mit der extraportion energie

A router is not a switch - A router is not a switch - A router is not a switch - A rou....

Weil dies ein SSL-Client-To-Site-VPN Service ist?

Offiziell sollte man dies so nicht verwenden.
Allein schon deswegen, da die Verschlüsselung reines SSL/TLS ist.

Aspekt zur Sicherheit: IPSec nutzt mehrere Verschlüsselungen und stärkere. Ergo: Der Datenverkehr ist sicherer

Zu mal IPsec für Site-To-Site ausgelegt ist. Und das weltweiter Standart ist.


Gesendet von iPhone mit Tapatalk

Eieiei, weltweiter Standard (oder Standart? Wer weisss...). Jetzt bin ich beeindruckt. Hast du eine Quelle für solches Wissen?

Was soll ein "SSL-Client to site VPN" sein und wofür, wenn nicht site-to-site sollte der peer-tp-peer SSL/PSK mode bei openVPN gut sein, wenn nicht zum Verbinden von Standorten. :-)

kind regards
chemlud
____
"The price of reliability is the pursuit of the utmost simplicity."
C.A.R. Hoare

felix eichhorns premium katzenfutter mit der extraportion energie

A router is not a switch - A router is not a switch - A router is not a switch - A rou....

Quote from: chemlud on March 01, 2019, 04:30:27 PM
Eieiei, weltweiter Standard (oder Standart? Wer weisss...). Jetzt bin ich beeindruckt. Hast du eine Quelle für solches Wissen?

Was soll ein "SSL-Client to site VPN" sein und wofür, wenn nicht site-to-site sollte der peer-tp-peer SSL/PSK mode bei openVPN gut sein, wenn nicht zum Verbinden von Standorten. :-)

Vielen Dank für die Korrektur... (passiert halt wenn man viel Englisch schreibt ;-) )

Meine Quelle sind meine Lehrbücher.
Plus bietet OpenVPN nur Client-Software an.
Bedeutet: Lokal installierte Software, die den Traffic von diesem einem Client durchs VPN auf eine VPN-Site leitet.

Wieso sollte dies für 2 oder mehr Sites gut sein?
Es kann zwar funktionieren, aber da nimmst du lieber eine VPN-Software die für Site-To-Site ist.

Vorallem nutzt du automatisch IPSec, wenn du Partnerfirmen als Router nutzt (zb: Global Cloud Exchange).

Schwer ist dies nicht zu konfigurieren. Und es läuft (zu mindest bei mir) wesentlich schneller als über OpenVPN.

PS: Dein Letzter Abschnitt ist schlecht leserlich... Da man nicht mehr versteht was gemeint ist.


Gesendet von iPhone mit Tapatalk

Standard schreibt sich am Ende mit d in beiden Sprachen :-D

Nein, es gibt einen peer-to-peer mode in openVPN, mit TLS oder mit PSK. Und damit verbindet man zwei oder mehr Netze, die räumlich getrennt sind. Das ist so und wird auch so bleiben. Ich schreibe diesen Post gerade durch einen solchen Tunnel... ;-)

Vielleicht sollten wir einfach die Konfiguration von Canzler zum laufen bringen, wobei ich mir nicht sicher bin, ob es reicht den Standardport 1194 an die OPNsense dahinter durchzureichen. Das habe ich bisher nicht probiert, bei mir sind die Sensen immer auch Perimeterfirewalls....
kind regards
chemlud
____
"The price of reliability is the pursuit of the utmost simplicity."
C.A.R. Hoare

felix eichhorns premium katzenfutter mit der extraportion energie

A router is not a switch - A router is not a switch - A router is not a switch - A rou....

Quote from: chemlud on March 01, 2019, 04:47:33 PM
Vielleicht sollten wir einfach die Konfiguration von Canzler zum laufen bringen, wobei ich mir nicht sicher bin, ob es reicht den Standardport 1194 an die OPNsense dahinter durchzureichen. Das habe ich bisher nicht probiert, bei mir sind die Sensen immer auch Perimeterfirewalls....

Gute Frage nächste Frage... ;P
Theoretisch eigentlich schon

Beide FWs müssten sich ja auf den Port verbinden, um den Tunnel aufzubauen.
Die restlichen Ports sind ja dann dynamisch und diese verhandeln sie ja selbst aus...

Wüsste nicht warum der nicht ausreichen würde.



Gesendet von iPhone mit Tapatalk

Es macht durchaus einen Unterschied ob man ESP (IPsec) oder OpenVPN nimmt, da ESP vom Kernel beschleunigt abgearbeitet werden kann und man so einen hohen Durchsatz erzielen kann und dabei die CPU last nicht so hoch ist wie bei TLS (das könnte sich in Zukunft zumindest auf Linux etwas angleichen mit dem Kernel-TLS support).

Der große Unterschied ist, ob es wie bei OpenVPN in TUN modus ein Transfernetz gibt oder nicht (IPsec routet ohne Transfernetz und OpenVPN im TAP-Modus emuliert einen Switch). Was man da haben will, hängt an den Anforderungen. Zudem muss man bei IPsec regeln, wie man mit ESP encapsulation umgehen will, weil NAT ohne UDP encapsulation Probleme macht.

Soviel mal zu den technischen Fragen. Wenn der Tunnel steht, würde ich auf einen der zwei Klassiker tippen:

* eine Firewall blockierts
* eine Route am jeweils anderen Netz fehlt, falls kein SNAT konfiguriert ist

Quote from: fabian on March 01, 2019, 05:02:04 PM
Es macht durchaus einen Unterschied ob man ESP (IPsec) oder OpenVPN nimmt, da ESP vom Kernel beschleunigt abgearbeitet werden kann und man so einen hohen Durchsatz erzielen kann und dabei die CPU last nicht so hoch ist wie bei TLS (das könnte sich in Zukunft zumindest auf Linux etwas angleichen mit dem Kernel-TLS support).

Der große Unterschied ist, ob es wie bei OpenVPN in TUN modus ein Transfernetz gibt oder nicht (IPsec routet ohne Transfernetz und OpenVPN im TAP-Modus emuliert einen Switch). Was man da haben will, hängt an den Anforderungen. Zudem muss man bei IPsec regeln, wie man mit ESP encapsulation umgehen will, weil NAT ohne UDP encapsulation Probleme macht.

Soviel mal zu den technischen Fragen. Wenn der Tunnel steht, würde ich auf einen der zwei Klassiker tippen:

* eine Firewall blockierts
* eine Route am jeweils anderen Netz fehlt, falls kein SNAT konfiguriert ist

Wow danke für die Bestätigung und die ausführlichere Erklärung auf das was ich hinaus wollte *-*!!!!

Aber genau aus dem Grund hab ich die Manual dazu getan, wie man in der Sense ein korrekte IPSec hinzufügt.

Aber das Problem mit ESP haste nicht.
Man muss auch keine NAT-Rules machen.
Zumindest nicht in der Sense.

IPSec dort einzurichten ist Pipifax.
Man muss nur gucken, dass man die richtigen Keys und Daten eingibt, sowie entfernte und lokale Netze + WAN-Rules, die die benötigten Ports aufmachen für den IPSec-Traffic.


Gesendet von iPhone mit Tapatalk

Ich kann aber in all dem Techie-Talk nicht erkennen, warum man kein site-to-site mit openVPN machen KÖNNEN soll und warum das unsicherer sein soll. Aber das ist ein anderes (verbreitetes) Problem in Software-Foren.

IPsec hatte ich vorher. Weniger stabil (unter meinen Bedingungen) und die Konfiguration ist wesentlcih fehleranfälliger. Durchsatz war bei meiner Anwendung mit openVPN besser. Das habe ich so auch anderweitig öfter gelesen. Geschenkt. Schreib noch was, damit du den letzten Post hast :-D
kind regards
chemlud
____
"The price of reliability is the pursuit of the utmost simplicity."
C.A.R. Hoare

felix eichhorns premium katzenfutter mit der extraportion energie

A router is not a switch - A router is not a switch - A router is not a switch - A rou....

Punkt Sicherheit: IPSec unterstützt sehr viele sehr starke Verschlüsselungen.

Und IPSec ist wirklich ,,performanter".
Vielleicht speziel bei dir nicht aber kenne genug die IPSec für alles nutzen, nur aus Performancegründen.

Klar ist IPSec ,,fehleranfällig", da die Kompatibilität gegeben sein muss und die richtige Eingabe des Konfigurators.
Aber weil alles Senses sind ist die Kompatibilität gegeben und ja die Layer 8 Fehler kann man nicht umgehen.


Gesendet von iPhone mit Tapatalk

Quote from: chemlud on March 01, 2019, 05:23:00 PM
Ich kann aber in all dem Techie-Talk nicht erkennen, warum man kein site-to-site mit openVPN machen KÖNNEN soll und warum das unsicherer sein soll. Aber das ist ein anderes (verbreitetes) Problem in Software-Foren.

Siehe mein Kommentar -> Es geht und macht auch sicher keine Probleme (außer du willst ein großes Netz anbinden).

Quote from: chemlud on March 01, 2019, 05:23:00 PM
IPsec hatte ich vorher. Weniger stabil (unter meinen Bedingungen) und die Konfiguration ist wesentlcih fehleranfälliger.
IPsec ist an sich einfach, das Problem ist immer der IKE daemon ;)

Bei IKEv1 ist leider nicht viel standardisiert, was dazu führt, dass die Implementierungen nicht immer zueinander kompatibel waren. Mit IKEv2 sollte sich das gebessert haben.

PS: Die verwendeten Algorithmen für TLS und IPsec sind weitestgehend ident. Von dem her macht es keinen Unterschied.