OpenVPN Konfiguration PING und Freigaben antworten

midivirus
Goto Top
Servus Zusammen -

Derzeit probiere ich mich an OpenVPN heran und muss immer an einer Stelle den Dienst quittieren, egal mit welcher Konfirmation der Server gestartet wird:

Die Verbindung wird am Client aufgebaut (grün), dies wird auch am Server verzeichnet.
Dann: keine Daten werden ausgetauscht.
Der Ping auf einen Server (x.y.0.2) oder auch auf den VPN (x.y.0.33) wird damit beendet:


Für mich stellt sich die Frage, wo ich einen Denkfehler habe?


Anbei ein paar Auszüge:







siehe sonst auch:
OpenVPN - Ethernet-Tunnel - VERIFY ERROR...

Content-Key: 457456

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

Ausgedruckt am: 19.05.2022 um 14:05 Uhr

Mitglied: Pjordorf
Pjordorf 31.05.2019 um 14:17:21 Uhr
Goto Top
Hallo,

Zitat von @Midivirus:
egal mit welcher Konfirmation der Server gestartet wird:
Da ein VPN nichts mit Konfirmation zu tun hat, oder ein Geistliches VPN is, meinst du sicherlich Konfiguration, oder?

Der Ping auf einen Server (x.y.0.2) oder auch auf den VPN (x.y.0.33) wird damit beendet:
Wenn du hier versuchst deine Privaten IPs (Millionen anderer nutzen die auch) zu verschleiern, mach das bitte auch in den Weitere Verlauf, obwohl fast jeder sich für x= 192 und y=168 wérwärmen könnte.
https://de.wikipedia.org/wiki/Private_IP-Adresse
https://simple.wikipedia.org/wiki/Private_network

local 192.168.0.33
Wohl doch keine x.y.0.33 :-) face-smile

Ping wird ausgeführt für 192.168.0.2 mit 32 Bytes Daten:
Antwort von 62.155.242.200: Zielnetz nicht erreichbar.
Dein Ping wird ins Internet weitergeleitet. Konfiguration. Oder betreibs du Geräte im 62.155.242.xy/xy Netz? Gibt es weitere Router?

Gruß,
Peter
Mitglied: aqui
Lösung aqui 31.05.2019 aktualisiert um 16:44:28 Uhr
Goto Top
Die Verbindung wird am Client aufgebaut (grün), dies wird auch am Server verzeichnet.
Ahem...eine Binsenweisheit ! Sinnfrei sowas in einem Administrator Forum zu betonen. Jedem Netzwerk Admin ist das klar. ;-) face-wink Das ist also völlig normal oder dachtest du das der Server die Verbindung zum Client initiiert, sprich also das Pferd von hinten aufzäumt ?!!
Dann: keine Daten werden ausgetauscht.
Warum auch ?? Wenn du keine Daten für die andere Seite generierst die über den Tunnel laufen werden logischerweise auch keine ausgetauscht. Auch das ist also völlig normal.
Wo ist denn nun dein wirkliches Problem ??

Der Ping auf einen Server (x.y.0.2) oder auch auf den VPN (x.y.0.33)
Bahnhof ? Ägypten ? Wer oder was soll "VPN" sein ??? Und WIE sind deine IP Adressen zu verstehen ??
Grundlagen zu dem Thema findest du wie immer im OVPN Tutorial hier:
https://administrator.de/wissen/openvpn-server-installieren-pfsense-fire ...

Abbrechen tut auch gar nix, denn dein Client meldet "Initialization Sequence Completed" was zeigt das der Tunnel fehlerfrei aufgebaut wurde !!! Du hast also soweit alles richtig gemacht wenn man mal von den kosmetischen Fehlern wie dem nicht beidseitigen "comp-lzo" und der ungleichen Link MTU absieht. Das ist erstmal nur kosmetisch.
Die große Frage ist WO ist dein Server ?? Im internen LAN, im Internet ??? Und WO ist der Client ?
Eine kurze Skizze hätte hier allen in der Community geholfen dein Design zu verstehen.
Nur so viel...
Wenn du remote (Winblows) Rechner nicht pingen kannst hat das in der Regel 4 Gründe:
  • Du hast die lokale Firewall NICHT angepasst. Die blockt alles was aus fremden IP netzen kommt und dein VPN Client hat eine Absender IP von 192.168.10.0. Solcher Traffic wird geblockt
  • ICMP (Ping, Traceroute) wird generell per Default geblockt. Wie man das freischaltet kannst du hier nachlesen: https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
  • Das virtuelle TAP Interface hat oft ein falsches Windows Firewall Profil ! Durch die fehlende Gateway Discovery deklariert Winblows das Interface als Public und blockiert damit jeglichen eingehnden Traffic. Das TAP Interface musst du also auf ein Private Profil setzen in den Firewall Settings !
  • Der OVPN Server ist im lokalen LAN. Dann fehlt oft eine statische Route auf dem Internet Router die dann zwingend erforderlich ist. Siehe auch hier:
https://administrator.de/wissen/openvpn-server-installieren-pfsense-fire ...
Deshalb pingt man also immer die lokalen Router Interface oder Drucker usw. also Geräte die keine lokale Firewall haben !!
Checke diese 4 Punkte, dann kommt das auch sofort zum Fliegen !
Mitglied: Midivirus
Midivirus 03.06.2019 aktualisiert um 11:06:30 Uhr
Goto Top
Besten Dank für den Hinweis, die grüne Signalisierung nichts bedeutet.
Das ist fast klar, erst wenn etwas tatsächlich funktioniert, werden Statusmeldungen anerkannt.

Wo ist denn nun dein wirkliches Problem ??

Der Tunnel wird aufgebaut, wie erkannt, allerdings können keine Daten fließen.

Du hast also soweit alles richtig gemacht wenn man mal von den kosmetischen Fehlern wie dem nicht beidseitigen "comp-lzo" und der ungleichen Link MTU absieht.

Das dachte ich mir.

Die große Frage ist WO ist dein Server ?? Im internen LAN, im Internet ??? Und WO ist der Client ?

Der Server steht hinter NAT mit 192.168.0.33/24
Der Client extern hinter NAT mit 192.168.11.66/24
Beide stehen geographisch an zwei unterschiedlichen Standorten und haben entsprechend jeweils eine andere öffentliche IPv4 Adresse

Es gibt noch einen Drucker 192.168.0.111 - welcher aktuell die 'ping' ohne Antwort lässt.


Getestet, wenn Server die Adressen aus dem gleichen Subnetz vergibt:


In der Zwischenzeit arbeite ich die (verlinkten) Anleitungen durch.
Mitglied: Midivirus
Midivirus 03.06.2019 um 11:34:19 Uhr
Goto Top
es ist gerade leicht peinlich:

vpn1

Starte ich den OpenVPN Server mit den unten eingestellten Informationen:

Gibt es eine Verbindung.
Ich kann den Drucker erreichen und diverse andere Ziele.


Weil aktuell das 'comp-lzo' zu einem Problem führte, habe ich es temporär auskommentiert.



Was mich nur stutzig macht, warum 2 unterschiedliche Zertifikate den Ping sehr stark beeinflussen.
111 (Printserver) und 222 (direkt) sind Drucker und eine Windowskiste auf 2




Aktueller Status:
Es funktioniert, mehr aber noch nicht.
Mitglied: aqui
aqui 04.06.2019 aktualisiert um 13:00:43 Uhr
Goto Top
Der Server steht hinter NAT mit 192.168.0.33/24 Der Client extern hinter NAT mit 192.168.11.66/24
Nicht ganz !
NAT gilt ausschliesslich nur für den Traffic ins Internet NICHT aber für den durch den VPN Tunnel. Dort macht man sinnigerweise kein NAT und routet immer transparent.
Das Server Bridge Statement ist tödlich !
Damit verbindest du deine 3 unterschiedlichen IP Netzwerke über eine Layer 2 Bridge.
https://openvpn.net/community-resources/ethernet-bridging/
Sowas Gruseliges mach man sich gar nicht vorstellen.... Damit wird jegliche Sicherheit ausgehebelt.
Sinnvoll wäre es mal wenn du die Routing Tabellen hier postest um zu sehen das die IP Netze auch sauber propagiert werden.
Die Firewall und ICMP Settings hast du umgesetzt ?
Mitglied: Midivirus
Midivirus 04.06.2019 um 14:23:14 Uhr
Goto Top
NAT gilt ausschliesslich nur für den Traffic ins Internet NICHT aber für den durch den VPN Tunnel. Dort macht man sinnigerweise kein NAT und routet immer transparent.

So ist es - Aussage galt als Erklärung.


Route Client:

Route SERVER:



Verbindung steht, Drucker und Freigaben können erreicht werden.
Mitglied: aqui
aqui 04.06.2019 um 18:59:04 Uhr
Goto Top
Irgendwas stimmt da aber grundsätzlich nicht bei dir !!
Wo ist denn dein internes OpenVPN Netzwerk ?? Das IP Netz was du mit server 192.168.10.0 255.255.255.0 definierst muss ja am Tunnel Interface anliegen. Der Server hat immer die .1 und die Route im Client MUSS auf diesen Adapter bzw. auf diese IP Adresse zeigen. Genau DAS ist bei dir nicht der Fall ! :-( face-sad
Das sieht so aus als ob du da irgendwie ein Bridging machst statt Routing und falscxhe Adapter benutzt.

Mach dochmal ein ganz einfache und banale Server Konfig:
port 1194
proto udp
dev tun0
ca /tmp/openvpn/ca.crt (Master Zertifikat)
cert /tmp/openvpn/cert.pem (Server Zertifikat)
key /tmp/openvpn/key.pem (Server Key)
dh /tmp/openvpn/dh.pem (DH Parameter)
server 192.168.10.0 255.255.255.0
push "route 192.168.0.0 255.255.255.0"
keepalive 10 120
persist-key
persist-tun
verb 3


Und Client:
client
dev tun
proto udp
remote x.y.z.a 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca C:/Programme/OpenVPN/easy-rsa/keys/ca.crt
cert C:/Programme/OpenVPN/easy-rsa/keys/client1.crt
key C:/Programme/OpenVPN/easy-rsa/keys/client1.key
ns-cert-type server
comp-lzo
verb 3

Mitglied: Midivirus
Midivirus 05.06.2019 um 09:31:32 Uhr
Goto Top
Im Testbetrieb ohne VPN-Netz gelassen (192.168.0.0 DHCP 60-70)


Route Print vom Client:

route print server


jetzt kommt am Client wieder dieser Fehler:

ping auf Drucker 192.168.0.111 ohne Rückmeldung

Das sieht so aus als ob du da irgendwie ein Bridging machst statt Routing und falscxhe Adapter benutzt.

lan-brücke


Das könnte also die Ursache sein, dass ich in einer ganz früheren Anleitung eine Brücke erstellen sollte (...).
Mitglied: aqui
aqui 05.06.2019 aktualisiert um 16:27:16 Uhr
Goto Top
OK, jetzt stimmt das wenigstens mit den IP Netzen in der Routing Tabelle.
Das mit dem LZO Fehler kannst du ignorieren. Lösche das "comp-lzo" aus der Server und Client Konfig, dann verschwindet das ! Damit ist dann Kompression erstmal komplett deaktiviert.

Was verwundert ist deine Bridge dort in den Winblows Adaptern !! Die hat da nichts zu suchen. OpenVPN sollte man immer routen. Also weg damit !
Du darfst keines der Interfaces irgendwie in eine Bridge oder "Netzwerkbrücke" einbinden !!!
Hier nochmal die Punkte die zu beachten sind:
  • Keinerlei Bridges. Sollten alle gelöscht sein !
  • Das Tunnel Interface (tap) muss ein Privates Firewall Profil haben
  • VPN Tunnelaufbau sollte mit "Intizialisation sequence completed" abschliessen, was dann zeigt das der Tunnel erfolgreich etabliert wurde.

Den Drucker remote zu pingen ist schonmal richtig, denn der hat ja keine Firewall die dir ein Bein stellen kann ! ;-) face-wink
Allerdings musst du folgendes dazu absolut sicherstellen:
  • Drucker MUSS ein Default Gateway definiert haben !
  • Default Gateway sollte der Internet Router sein. (Normal wenn der Drucker eine DHCP IP vom Router bekommt)
  • Der Internet Router MUSS eine statische Route auf das interne OVPN IP Netz (bei dir 192.168.0.0 /24) haben wenn der OVPN Server im lokalen LAN ist !
Siehe hier:

ovpn

Tue so also ob das NAS In der Zeichnung dein Drucker ist und ersetze das dort interne 10.10.10.0 /24 Netz mit deinem 192.168.0.0 /24
Das ist ja das gleiche Design was du hast !
Wichtig eben die statische Route, denn wenn der Drucker(NAS) auf die Ping Pakete mit der internen OVPN IP Absenderadresse antwortet schickt er das erst an sein Default Gateway, der Internet Router.
Der muss es natürlich dann an die lokale LAN IP des OVPN Servers routen, der es dann wiederum in sein internes Tunnelnetz routet.
Deshalb diese 3 wichtigen Punkte:
  • Windows OVPN Server muss IPv4 Forwarding (Routing) aktiviert haben !!
  • Firewall Profil des tap Interface muss Privat sein.
  • Statische Route Internet Router: Zielnetz: 192.168.0.0, Maske: 255.255.255.0, Gateway: <LAN_IP_OVPN-Server>
So wird ein Schuh draus !
Mitglied: Midivirus
Midivirus 07.06.2019 um 11:14:30 Uhr
Goto Top
nach einiger Zeit auch eine Rückmeldung:


Gibt es einen Kniff, dem 'mytap' was anderes zuzuweisen?
vpn1
(In der Oberfläche klappt es zumindest nicht)

Drucker MUSS ein Default Gateway definiert haben !
DHCP :Þ Gateway ist wegen Maildienste bereits hinterlegt.


vpn2
Ich denke, diese Route ist gemeint (Digitalisierungsbox Premium)
Hinweis:
In der Grafik ist ein Zahlendreher 245 vs 254

vpn3
Vermutlich hängt es da auch noch !!!



die config ist jedenfalls jetzt so gemacht worden, dass gar nichts mehr geht.


Habe da vermutlich kein Verständnis für, jedoch interessant, warum man dafür extra Netze aufspannen soll.
Vorher ging es ja :Þ


Werde in den nächsten Tagen sehr wenig Zeit haben (...).
Mitglied: Midivirus
Midivirus 07.06.2019 um 11:53:04 Uhr
Goto Top
Vermutlich, Laptop / Rechner steht geographisch woanders, gibt es jetzt immer einen BlueScreen und Neustart, nachdem die Verbindung zustande gekommen ist.

Dies gab es früher mal - mit einer ersten Konfiguration und ist danach nicht mehr aufgetaucht.

Der Computer wurde nach einem schwerwiegenden Fehler neu gestartet. Der Fehlercode war: 0x000000d1 (0x00000020, 0x00000002, 0x00000000, 0x8c6abece).


Zwischenmeldung
Mitglied: Pjordorf
Pjordorf 07.06.2019 um 12:10:45 Uhr
Goto Top
Hallo,

Zitat von @Midivirus:
Der Computer wurde nach einem schwerwiegenden Fehler neu gestartet. Der Fehlercode war: 0x000000d1 (0x00000020, 0x00000002, 0x00000000, 0x8c6abece).
Und? Schon mal geschaut was evtl. für ein Treiber da verrücktspielt? Schon mal geschaut was bei 0x000000d1 zu tun ist?

https://www.google.com/search?q=0x000000d1

Gruß,
Peter
Mitglied: aqui
aqui 08.06.2019 aktualisiert um 12:31:09 Uhr
Goto Top
Hier:
Client01/(extern):55854 IP packet with unknown IP version=15 seen
stimmt ja auch schon grundsätzlich was nicht. Die ganze Konfig scheint ein einziger Murks zu sein. :-( face-sad
https://askubuntu.com/questions/233396/openvpn-logs-ip-packet-with-unkno ...
Irgendwas mit der Tunnel Interface Defintion in der Konfig Datei ist hier also falsch !

Irgendwie alle unverständlich...
  • Aktuelle Version geladen: https://openvpn.net/community-downloads/
  • Auf Windows installiert
  • Zertifikate generiert
  • Standard Konfig Datei verwendet
  • Routen und Routing angepasst.
  • Server gestartet
  • Geht !
Was ist daran nur so schwer...??!