Mikrotik VPN - Router hat Zugriff, Client nicht
Hallo zusammen,
leider muss ich euch noch mit einer weiteren Frage zu meiner VPN-Problematik behelligen.
Stand der Dinge ist folgendes:
Netzwerk in der Zentrale: 10.10.20.0/24 (Sophos UTM)
Netzwerk hinter Mikrotik: 10.0.5.0/24
In der Sophos habe ich einen Eintrag für das SSL-S2S VPN angelegt.
Dort habe ich bei Lokale Netze das 10.10.20.0/24 eingetragen und bei entfernte Netze 10.0.5.0/24.
Automatische Firewallregeln sind aktiviert.
Im Mikrotik habe ich dann ein ovpn-interface angelegt mit den entsprechenden Einstellungen und Zertifikaten.
Das Interface läuft und über die Mikrotik-Shell kann ich einen Rechner in der Zentrale anpingen. (Debian Linux, keine besonderen Firewalleinstellungen)
Leider gelingt mir der Zugriff von Geräten hinter dem Mikrotik nicht.
Die Route in der Sophos existiert:
Die Route im Mikrotik auch:
Im Firewall-Log der Sophos tauchen keine geblockten Pakete auf. Dort habe ich an den FIrewallregeln nichts verändert, aber durch "Automatische Firewallregeln" müsste der Zugriff möglich sein. (Ausserdem kann ich ja vom Mikrotik aus pingen)
In der Mikrotik-Firewall wird erstmal global alles akzeptiert sowohl input als auch forward.
Und jetzt weiß ich nicht mehr weiter. Hat jemand von euch noch eine Idee?
Danke und beste Grüße!
Berthold
EDIT: Nachtrag zur Fehlersuche: Ich habe mir jetzt auf dem Zielrechner des Pings per tcpdump die eingehenden ICMP-Pakete angesehen. Vom Mikrotik kommen die Pakete an, vom Client dahinter nicht.
leider muss ich euch noch mit einer weiteren Frage zu meiner VPN-Problematik behelligen.
Stand der Dinge ist folgendes:
Netzwerk in der Zentrale: 10.10.20.0/24 (Sophos UTM)
Netzwerk hinter Mikrotik: 10.0.5.0/24
In der Sophos habe ich einen Eintrag für das SSL-S2S VPN angelegt.
Dort habe ich bei Lokale Netze das 10.10.20.0/24 eingetragen und bei entfernte Netze 10.0.5.0/24.
Automatische Firewallregeln sind aktiviert.
Im Mikrotik habe ich dann ein ovpn-interface angelegt mit den entsprechenden Einstellungen und Zertifikaten.
Das Interface läuft und über die Mikrotik-Shell kann ich einen Rechner in der Zentrale anpingen. (Debian Linux, keine besonderen Firewalleinstellungen)
Leider gelingt mir der Zugriff von Geräten hinter dem Mikrotik nicht.
Die Route in der Sophos existiert:
10.0.5.0/24 via 10.242.2.1 dev tun0 proto 41
Die Route im Mikrotik auch:
Im Firewall-Log der Sophos tauchen keine geblockten Pakete auf. Dort habe ich an den FIrewallregeln nichts verändert, aber durch "Automatische Firewallregeln" müsste der Zugriff möglich sein. (Ausserdem kann ich ja vom Mikrotik aus pingen)
In der Mikrotik-Firewall wird erstmal global alles akzeptiert sowohl input als auch forward.
Und jetzt weiß ich nicht mehr weiter. Hat jemand von euch noch eine Idee?
Danke und beste Grüße!
Berthold
EDIT: Nachtrag zur Fehlersuche: Ich habe mir jetzt auf dem Zielrechner des Pings per tcpdump die eingehenden ICMP-Pakete angesehen. Vom Mikrotik kommen die Pakete an, vom Client dahinter nicht.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 307989
Url: https://administrator.de/contentid/307989
Ausgedruckt am: 08.11.2024 um 21:11 Uhr
28 Kommentare
Neuester Kommentar
Leider gelingt mir der Zugriff von Geräten hinter dem Mikrotik nicht.
Macht der MT irgendeine Art von NAT ?? Denk dran das du den VPN Tunnel Traffic beider lokalen Netze aus der NAT Regel excluden musst in den Firewall Settings des MT und das VOR der NAT Regel (Reihenfolge !)Ansonsten NATet der MT auch den Tunneltraffic was dann in dem Fehler resultiert.
Ist identisch zu hier im Kapitel: Wichtig: Ausnahme in der NAT Firewall definieren das VPN Traffic nicht geNATet wird:
Wichtig wäre auch zu wissen ob es im MT noch einen anderen Router gibt und ob dieser ggf. der Default Router dieser Geräte ist ? Dann hast du ein Routing Problem und musst dort erst eine statische Route auf 10.10.20.0/24 mit next Hop MT IP eintragen.
Traceroute und Pathping sind hier deine Freunde !
Ebenso die Routing Tabelle auf dem MT und der Sophos die dir sagt wie deine Zielnetze zu erreichen sind !
Da der VPN Tunnel sauber funktioniert kann es nur noch ein Routing oder FW Problem sein !
He he he...
Das ist ja wie bei Microsoft !!
Wichtig ist hier was die Sophos, sofern diese OVPN Server ist, per push Kommando an den OVPN Client (MT) sendet.
Da du hier leider keinerlei Server Konfig postest kann man das nicht checken
Vermutlich also schlicht und einfach wie so oft eine falsche oder fehlerhafte Server.conf Datei mit falschem Push Kommando für die Route ?!
Grundlagen dazu guckst du hier:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Die Konfig ToDos sind auf allen OVPN Plattformen immer gleich !
Das ist ja wie bei Microsoft !!
er routet die ganzen Netze auf das Gateway 255.255.255.0, daher muss man die Routen jedes Mal selbst anpassen.
Sorry aber das ist (vermutlich) Quatsch und zeugt eher von einer falschen OVPN Konfiguration !!Wichtig ist hier was die Sophos, sofern diese OVPN Server ist, per push Kommando an den OVPN Client (MT) sendet.
Da du hier leider keinerlei Server Konfig postest kann man das nicht checken
Vermutlich also schlicht und einfach wie so oft eine falsche oder fehlerhafte Server.conf Datei mit falschem Push Kommando für die Route ?!
Grundlagen dazu guckst du hier:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Die Konfig ToDos sind auf allen OVPN Plattformen immer gleich !
Naja, bei der Sophos komme ich ja standardmäßig nicht an die Server-Konfigurationsdatei.
Ooops..Klicki Bunti... Na ja ist ja egal wie es in die Konfig Datei kommt Hauptsache es steht da und geht per Push raus was ja laut o.a. Log der Fall zu sein scheint.
Spannend wäre hier nochmal die MT Routing Tabelle zu sehen wenn die Verbindung aktiv ist ob die Routen auch wirklich umgesetzt wurden.
Was den Abbruch anbetrifft 2 Dinge:
- Ist auf dem MT die aktuelles Firmware geflasht ??
- Es sieht nach den Error messages so aus als ob eine Seite einen Keepalive macht mit Pings. Das muss natürlich klappen und ICMP darf dann im Tunnel oder den Tunnelinterfaces nicht geblockt sein !!
Das hört sich so danach an das Ping nicht klappt, damit dann der Keepalive fehlschlägt und ein Ende den Tunnel runternimmt.
Also entweder Ping zum Fliegen bringen oder Tunnel Keepalive deaktivieren.
Wenn ich nicht manuell die Routen angebe, funktioniert garnix. Hier die Routing-Table des MT:
Ist das jetzt die Tabelle mit deinen zusätzlichen statischen Routen oder die OHNE ??Letztere wäre relevant !!! Das es mit statischen geht ist ja klar.
Normal sollte ein OVPN Client diese per Push Kommando bekommen und dann automatisch beim Connect in die Routing Tabelle übernehmen.
Die oben von dir gepostete Tabelle ist ja richtig ! Vermutlich ist es aber die MIT den statisch zugefügten Routen ?!
Nochmal die Frage ob der MT irgendeine Art von NAT macht ??? Richtung WAN usw. ?
Ist das der Fall musst du den Tunnel vom NAT ausnehmen !
Und wie ich das Keepalive deaktiviere? - Tja, da habe ich gerade null Ahnung...
Der Server kann sowas haben wie: ping 30
ping-restart 120
push "ping 15"
push "ping-restart 60"
Damit erzwingt man einen Tunnel Keepalive auf beiden Seiten:
https://openvpn.net/index.php/open-source/documentation/manuals/65-openv ...
Erklärt die Syntax unter Tunnel Options und dann beim Kommando -ping
Besonders: --ping-exit n
==> Causes OpenVPN to exit after n seconds pass without reception of a ping or other packet from remote.
Dein Timer steht da vermutlich auf 300 oder sowas...
Ping Keepalive MUSS beidseitig konfiguriert werden da der Ping nicht geechot wird wie bei ICMP !
--ping on both peers to cause ping packets to be sent in both directions since OpenVPN ping packets are not echoed like IP ping
Nimm sonst mal einen Raspberry Pi testweise als OVPN Server
https://jankarres.de/2013/05/raspberry-pi-openvpn-vpn-server-installiere ...
Server Konfig:
root@raspi2:/etc/openvpn# cat openvpn.conf
dev tun
proto udp
port 1194
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem
user nobody
group nogroup
server 10.99.99.0 255.255.255.0
persist-key
persist-tun
status /var/log/openvpn-status.log
verb 3
push "10.10.20.0 255.255.255.0"
log /var/log/openvpn
comp-lzo
max-clients 10
keepalive 10 120
Hallo Berthold,
habe das ganze hier mal mit einer Sophos VM (UTM v9) und eine Mikrotik RB951G-2Hnd getestet und es zum fliegen gebracht. Das Problem ist hier das der Mikrotik die Routen die die Sophos an den Mikrotik "pusht" missinterpretiert. Sieht man ja auch oben an deinem Screenshot, der Mikrotik versucht hier über GW 255.255.255.0 das interne LAN der Sophos zu erreichen was natürlich nicht funktionieren kann.
Wenn ich diese fehlerhaften Routen rausschmeiße und sie statisch anlege funktioniert das ganze nämlich problemlos. Der Mikrotik scheint sich bei diesen unüblichen dynamischen Routen "wegzuhängen".
Nun habe ich mich mal mit der Konsole der Sophos verbunden und mir das CCD File für den Client mal angeschaut und dort in das "push route" hinten die Gateway-IP des VPN-Pools direkt hinten mit angehängt.
Also anstatt:
die Zeile so geschrieben (mit expliziter Angabe des Gateway)
Die Config liegt auf der Sophos in einer CHROOT Umgebung unter
Das XXXXX ist der Username den du aus dem *.pac file extrahiert hast.
Das File kannst du direkt mit vi dort bearbeiten.
Danach Interface im Mikrotik das OpenVPN Interface deaktiviert und neu aufgebaut.
Fazit: Damit läuft es hier bisher einwandfrei.
Grüße Uwe
habe das ganze hier mal mit einer Sophos VM (UTM v9) und eine Mikrotik RB951G-2Hnd getestet und es zum fliegen gebracht. Das Problem ist hier das der Mikrotik die Routen die die Sophos an den Mikrotik "pusht" missinterpretiert. Sieht man ja auch oben an deinem Screenshot, der Mikrotik versucht hier über GW 255.255.255.0 das interne LAN der Sophos zu erreichen was natürlich nicht funktionieren kann.
Wenn ich diese fehlerhaften Routen rausschmeiße und sie statisch anlege funktioniert das ganze nämlich problemlos. Der Mikrotik scheint sich bei diesen unüblichen dynamischen Routen "wegzuhängen".
Nun habe ich mich mal mit der Konsole der Sophos verbunden und mir das CCD File für den Client mal angeschaut und dort in das "push route" hinten die Gateway-IP des VPN-Pools direkt hinten mit angehängt.
Also anstatt:
push "route 10.0.5.0 255.255.255.0"
push "route 10.0.5.0 255.255.255.0 10.242.2.1"
/etc/sec/chroot-openvpn/etc/openvpn/conf.d/XXXXXX
Das File kannst du direkt mit vi dort bearbeiten.
Danach Interface im Mikrotik das OpenVPN Interface deaktiviert und neu aufgebaut.
Fazit: Damit läuft es hier bisher einwandfrei.
Grüße Uwe
Ich nutze hier im Moment AES-256-CBC damit läuft es bisher seit 30 Minuten ohne Abbruch, mit Dauerping und Datenlast.
Schalte auf der Sophos doch mal das DEBUG-LOG für das SSL-VPN ein .
Was ich aber gestehen muss ist das der orignale in den Mikrotik integrierte OpenVPN Client noch nie der Bringer war und ist, es gibt diverse Probleme damit wie man im Web in diversen Foren nachlesen kann...
Viele weichen hier auf eine andere Version aus die in einer METARouter-Instanz(virtueller OpenWRT) auf dem Mikrotik läuft.
Schalte auf der Sophos doch mal das DEBUG-LOG für das SSL-VPN ein .
Was ich aber gestehen muss ist das der orignale in den Mikrotik integrierte OpenVPN Client noch nie der Bringer war und ist, es gibt diverse Probleme damit wie man im Web in diversen Foren nachlesen kann...
Viele weichen hier auf eine andere Version aus die in einer METARouter-Instanz(virtueller OpenWRT) auf dem Mikrotik läuft.
2016:06:24-17:11:02 utm-2 openvpn[25983]: REF_AaaUse1/37.xxx.xxx.xxx:38481 [REF_AaaUse1] Inactivity timeout (--ping-restart), restarting
https://openvpn.net/index.php/open-source/documentation/manuals/65-openv ...
Schneide die Pakete auf beiden Seiten mit und untersuche mit Wireshark wer da auf wen wartet. Dann kannst du es auf einen der beiden einschränken.
Ich vermute der DD-WRT anwortet nicht (oder Pakete gehen verloren) und die Sophos resettet die Verbindung daraufhin. MTU überprüfen.
Ok, siehe oben, MTU am OpenWRT verringern und testen, und wie gesagt schau dir den Traffic mal mit Wireshark an.
Wie sieht dein Testsetup aus netzwerkmäßig? Über welche Leitungen machst du das ganze, etc pp. Denn das beide abbrechen ist sehr ungewöhnlich da muss bei dir noch irgendwas dazwischen hängen, die Leitung nicht zuverlässig sein, die MTU der DSL Leitung nicht stimmen, etc. pp...Dem kommst du am einfachsten auf die Schliche indem du den Verbose-Parameter in der Client und Server-Config erhöhst und mit WS mitschneidest.
Alles andere ist nur Glaskugelraten von hier aus.
Wie sieht dein Testsetup aus netzwerkmäßig? Über welche Leitungen machst du das ganze, etc pp. Denn das beide abbrechen ist sehr ungewöhnlich da muss bei dir noch irgendwas dazwischen hängen, die Leitung nicht zuverlässig sein, die MTU der DSL Leitung nicht stimmen, etc. pp...Dem kommst du am einfachsten auf die Schliche indem du den Verbose-Parameter in der Client und Server-Config erhöhst und mit WS mitschneidest.
Alles andere ist nur Glaskugelraten von hier aus.
Zitat von @BirdyB:
Ich habe die Link-MTU jetzt auf 1400 gesetzt. Bei einer TCP-Verbindung dürfte das aber nicht so viele Probleme bringen, oder?
Je nach Setup schon...hier ein Beispiel genau nach deiner Schilderung:Ich habe die Link-MTU jetzt auf 1400 gesetzt. Bei einer TCP-Verbindung dürfte das aber nicht so viele Probleme bringen, oder?
https://forums.untangle.com/openvpn/4214-openvpn-client-disconnects-afte ...
Das jetzige Setup ist: OpenWRT ---> HeimRouter (auch OpenWRT) ---> Internet ---> Sophos
OKDie einzige Stelle, an der ich mit Wireshark lauschen könnte wäre zwischen OpenWRT und meinem HeimRouter...
Ich würde direkt auf dem OpenWRT ein TCPdump machen.Die beiden Verbose-Logs während des Abbruchs habe ich ja schon zur Verfügung gestellt.
Du kannst das Verbose-Level mit dem VERB Parameter in der OpenVPN Config noch erhöhen, sowohl in der Client- als auch in der Serverconfig.P.S.: Ich bin schon fast versucht, das keepalive in der Sophos zu deaktivieren... Ich weiß nur nicht, ob es eine gute Idee ist, die Konfiguration der Sophos händisch zu ändern...
Und Firewall des OpenWRT checken ob hier ICMP in irgendeiner Art und weise geblockt werden (z.B. DDOS Settings)
Hier helfen nur Fakten, alles vermuten und nur ausprobieren auf gut Glück finde ich persönlich nicht zielführend.