birdyb
Goto Top

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:
10.0.5.0/24 via 10.242.2.1 dev tun0  proto 41 

Die Route im Mikrotik auch:
route

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.

Content-ID: 307989

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

Ausgedruckt am: 08.11.2024 um 21:11 Uhr

aqui
Lösung aqui 23.06.2016 aktualisiert um 11:04:41 Uhr
Goto Top
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 !
BirdyB
BirdyB 23.06.2016 aktualisiert um 11:05:08 Uhr
Goto Top
Ähem, nun gut... Für Mikrotik gilt das gleiche wie für jeden anderen Rechner:
"Hast du es schonmal aus- und wieder eingeschaltet?"

Fazit: geht!

Nur: die Routen, die von der Sophos übergeben werden kann der MT nicht ab: er routet die ganzen Netze auf das Gateway 255.255.255.0, daher muss man die Routen jedes Mal selbst anpassen.
aqui
aqui 23.06.2016 aktualisiert um 11:09:21 Uhr
Goto Top
He he he... face-smile
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 face-sad
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 !
BirdyB
BirdyB 23.06.2016 um 11:25:40 Uhr
Goto Top
Leider ja. Neues Problem: zuerst rennt die Verbindung einwandfrei, nach ca. 5min bricht die Verbindung zusammen und erst besagter Neustart bringt den Mikrotik für weitere 5 Minuten dazu seinen Job zu machen.

Mann, ich könnt ko###
BirdyB
BirdyB 23.06.2016 aktualisiert um 11:46:52 Uhr
Goto Top
Naja, bei der Sophos komme ich ja standardmäßig nicht an die Server-Konfigurationsdatei. Letztenendes klicke ich das ganze im Webinterface schön zusammen.
Das Push-Kommando wird an dieser Stelle von der Sophos selbst erzeugt. Was soll ich also tun?

Sophos sagt übrigens:
2016:06:23-11:37:11 utm-2 openvpn[25983]: USER/37.xxx.xxx.xxx:55531 SENT CONTROL [REF_AaaUse1]: 'PUSH_REPLY,topology subnet,route-gateway 10.242.2.1,route 10.10.20.0 255.255.255.0,route 172.16.0.0 255.255.255.0,route 10.10.30.0 255.255.255.0,route 10.10.40.0 255.255.255.0,route 172.16.1.0 255.255.255.0,setenv-safe remote_network_1 10.10.20.0/24,setenv-safe remote_network_2 172.16.0.0/24,setenv-safe remote_network_3 10.10.30.0/24,setenv-safe remote_network_4 10.10.40.0/24,setenv-safe remote_network_5 172.16.1.0/24,setenv-safe local_network_1 10.0.5.0/24,ifconfig 10.242.2.2 255.255.255.0' (status=1)   

Und wenn dann die Verbindung abbricht passiert folgendes:
2016:06:23-11:41:20 utm-2 openvpn[25983]: REF_AaaUse1/37.xxx.xxx.xxx:38070 [REF_AaaUse1] Inactivity timeout (--ping-restart), restarting
2016:06:23-11:41:20 utm-2 openvpn[25983]: REF_AaaUse1/37.xxx.xxx.xxx:38070 SIGUSR1[soft,ping-restart] received, client-instance restarting
2016:06:23-11:41:20 utm-2 openvpn[25983]: id="2204" severity="info" sys="SecureNet" sub="vpn" event="Site-to-site VPN down" variant="ssl" connection="REF_SslSerXXX" address="217.xxx.xxx.xxx"   

Dann wird zwar die Verbindung neu aufgebaut, aber ich bekomme keinen Zugriff mehr auf das Netz...
aqui
Lösung aqui 23.06.2016 aktualisiert um 12:05:48 Uhr
Goto Top
Naja, bei der Sophos komme ich ja standardmäßig nicht an die Server-Konfigurationsdatei.
Ooops..Klicki Bunti... face-smile
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.
BirdyB
BirdyB 23.06.2016 aktualisiert um 12:21:10 Uhr
Goto Top
Zitat von @aqui:

Naja, bei der Sophos komme ich ja standardmäßig nicht an die Server-Konfigurationsdatei.
Ooops..Klicki Bunti... face-smile
Sorry, da kann ich nix dafür...
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.
Wenn ich nicht manuell die Routen angebe, funktioniert garnix. Hier die Routing-Table des MT:
tablemt
Was den Abbruch anbetrifft 2 Dinge:
  • Ist auf dem MT die aktuelles Firmware geflasht ??
v6.35.4 - Gestern aktualisiert.
* 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.
Da stellt sich nur die Frage: Wie? - Ich hab ehrlichgesagt keine Ahnung, wie ich das hinbekomme. Aus dem Mikrotik-Netz kann ich 10.242.2.1 und 10.242.2.2 einwandfrei anpingen. Die Sophos kann auch beide IPs problemlos erreichen.

Und wie ich das Keepalive deaktiviere? - Tja, da habe ich gerade null Ahnung...

P.S.: Das Deaktivieren und Aktivieren des Interfaces auf dem Mikrotik genügt, damit die Verbindung wieder funktioniert.
aqui
Lösung aqui 23.06.2016 aktualisiert um 16:42:40 Uhr
Goto Top
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 face-wink
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 
Damit sollte es immer klappen face-wink
BirdyB
BirdyB 23.06.2016 um 18:28:32 Uhr
Goto Top
Hallo @aqui,

das ist die Routing-Table mit meinen Einträgen. Denk dir alles mit der Schaltfläche "D" am Anfang weg und du hast die dynamische Table.

Ich komme nur bei der Sophos nicht an die Konfigurationsdateien ran. Oder gibt es da einen Weg?

Den Extra-VPN-Server wollte ich mir gerne ersparen...

Beste Grüße!


Berthold
BirdyB
BirdyB 24.06.2016 um 00:56:30 Uhr
Goto Top
Also ich habe nochmal fleißig gesucht, aber ich finde keinen Weg die Konfiguration im Mikrotik oder in der Sophos entsprechend anzupassen. Das kann doch eigentlich nicht sein ?!?
Irgendwie muss es doch möglich sein, zwischen Sophos und Mikrotik ein S2S-VPN zu etablieren.

Oder muss ich doch wieder zurück zum IPSec-Vorhaben?
aqui
aqui 24.06.2016 um 11:18:23 Uhr
Goto Top
Ich check das mal mit dem MT und einem Standard VPN Server, da ich keine Sophos habe. Mal sehen was da passiert mit der Route Injection.
BirdyB
BirdyB 24.06.2016 aktualisiert um 16:06:32 Uhr
Goto Top
Ich habe es jetzt mal mit einem OpenWRT-Router probiert und die Verbindung rennt einwandfrei... Auch ohne manuelles Routing...
Mir scheint es, als sei MT mit Sophos nur bedingt kompatibel...
colinardo
Lösung colinardo 24.06.2016 aktualisiert um 16:51:48 Uhr
Goto Top
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:
push "route 10.0.5.0 255.255.255.0"
die Zeile so geschrieben (mit expliziter Angabe des Gateway)
push "route 10.0.5.0 255.255.255.0 10.242.2.1"
Die Config liegt auf der Sophos in einer CHROOT Umgebung unter
/etc/sec/chroot-openvpn/etc/openvpn/conf.d/XXXXXX
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
BirdyB
BirdyB 24.06.2016 aktualisiert um 16:54:08 Uhr
Goto Top
Hallo Uwe,

danke für die Hilfestellung. Mein größeres Problem ist, dass die Verbindung alle 5 Minuten abbricht. Scheinbar wegen eines Timeouts.
Bekommst du auch diese Verbindungsabbrüche?

Die Config-Files meiner Sophos sehen so aus:

openvpn.conf
cat openvpn.conf
dev tun
tun-ipv6

local 217.xxx.xxx.xxx 443 tcp
mark 4458

daemon
multihome
topology subnet
server 10.242.2.0 255.255.255.0


ccd-exclusive
duplicate-cn
route-gateway 10.242.2.1
push 'route-gateway 10.242.2.1'  
route 10.0.5.0 255.255.255.0

cipher AES-128-CBC
auth SHA1
comp-lzo no

persist-key
persist-tun
reneg-sec 28800
keepalive 10 120
verb 3
down-pre
username-as-common-name

capath /etc/openvpn/ca.d
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
dh /etc/openvpn/dh1024.local.pem

client-config-dir /etc/openvpn/conf.d
status /var/run/openvpn-status.log
ifconfig-pool-persist /var/run/ipp.txt

management /var/run/openvpn_mgmt unix
management-client-user root
management-client-group root

Benutzerspezifische Konfiguration:
cat REF_AaaUse1 
push-reset
push 'topology subnet'  
push 'route-gateway 10.242.2.1'  
push 'route 10.10.20.0 255.255.255.0'  
push 'route 172.16.0.0 255.255.255.0'  
push 'route 10.10.30.0 255.255.255.0'  
push 'route 10.10.40.0 255.255.255.0'  
push 'route 172.16.1.0 255.255.255.0'  
push 'setenv-safe remote_network_1 10.10.20.0/24'  
push 'setenv-safe remote_network_2 172.16.0.0/24'  
push 'setenv-safe remote_network_3 10.10.30.0/24'  
push 'setenv-safe remote_network_4 10.10.40.0/24'  
push 'setenv-safe remote_network_5 172.16.1.0/24'  
push 'setenv-safe local_network_1 10.0.5.0/24'  
iroute 10.0.5.0 255.255.255.0

Irgendwelche Ideen?
colinardo
colinardo 24.06.2016 aktualisiert um 17:04:02 Uhr
Goto Top
Ich nutze hier im Moment AES-256-CBC damit läuft es bisher seit 30 Minuten ohne Abbruch, mit Dauerping und Datenlast.

screenshot

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.
BirdyB
BirdyB 24.06.2016 um 17:06:19 Uhr
Goto Top
Hallo Uwe,

im Moment habe ich das ganze erstmal auf einem OpenWRT-Router laufen (da klappt es wenigstens mit den Routen).
Ansonsten verwende ich hier: AES-128-CBC, SHA1 und 1024 bit.

An die Einstellungen mag ich ehrlichgesagt auch nicht ran, da unsere Remote-User (die nur den Softwareclient verwenden) sonst vermutlich nicht mehr ins VPN kommen.

Ich poste gleich nochmal das Sophos-Debug-Log nach dem nächsten Timeout...
colinardo
colinardo 24.06.2016 aktualisiert um 17:15:18 Uhr
Goto Top
Welches PPP-Profil verwendest du auf dem Mikrotik, bzw wie sehen dort die Einstellungen aus?
BirdyB
BirdyB 24.06.2016 um 17:20:46 Uhr
Goto Top
Hallo Uwe,

hier erstmal der Link zum Sophos-Log: http://pastebin.com/HKp8ERtz
Ich wollte hier nicht so viel Text posten, die meisten Server Reads und Writes habe ich entfernt.

Im Moment habe ich den Mikrotik nicht im Einsatz. Wie schon geschrieben: Derzeit teste ich das ganze mit einem OpenWRT-Router.

Ich müsste den Mikrotik sonst nochmal anschließen, dann kann ich dir auch die PPP-Einstellungen sagen. Da der MT aber komplett auf Werkseinstellungen zurückgesetzt wurde, kann ich dir schonmal sagen, dass es die Standardwerte sind.
colinardo
colinardo 24.06.2016 aktualisiert um 17:23:04 Uhr
Goto Top
Ich schau mit den Log nachher mal an.
Nur mal so nachgefragt, warum verwendest du keinen IPSec-Tunnel ?
BirdyB
BirdyB 24.06.2016 um 17:34:53 Uhr
Goto Top
Weil der Client hinter einem (irgendeinem, nicht näher zu benennenden) NAT-Router steht / stehen wird. Ich hatte es bereits mit IPSec versucht, hatte aber damit schon deutliche Schwierigkeiten.
@aqui hat mir empfohlen, ich solle das ganze doch am besten per OpenVPN machen. Daher bin ich dann umgeschwenkt.
colinardo
colinardo 24.06.2016 aktualisiert um 17:44:28 Uhr
Goto Top
2016:06:24-17:11:02 utm-2 openvpn[25983]: REF_AaaUse1/37.xxx.xxx.xxx:38481 [REF_AaaUse1] Inactivity timeout (--ping-restart), restarting
So wie es aussieht ein Ping-Timeout die Ursache. Wie sieht denn die OpenVPN-Client-Config des DD-WRT-Routers aus?
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.
BirdyB
BirdyB 24.06.2016 um 17:47:40 Uhr
Goto Top
Das Timeout-Problem hatte ich aber auch mit dem Mikrotik... Daher habe ich es ja nochmal mit OpenWRT versucht.
Hier die Client-Config des OpenWRT:
config openvpn 'XXX'  
	option nobind '1'  
	option float '1'  
	option client '1'  
	option reneg_sec '0'  
	option dev 'tun'  
	option persist_key '1'  
	option remote 'xxx.xxx.xxx.xxx'  
	option port '443'  
	option ca '/etc/luci-uploads/cbid.openvpn.XXX.ca'  
	option cert '/etc/luci-uploads/cbid.openvpn.XXX.cert'  
	option key '/etc/luci-uploads/cbid.openvpn.XXX.key'  
	option pull '1'  
	option auth_user_pass '/etc/openvpn/userpass.txt'  
	option cipher 'AES-128-CBC'  
	option enabled '1'  
	option ping '10'  
	option ping_restart '60'  
	option ping_exit '120'  
	option comp_lzo 'adaptive'  
	option verb '6'  
	option dev_type 'tun'  
	option link_mtu '1560'  
	option tls_client '1'  
	option key_method '2'  
	option keysize '128'  
	option proto 'tcp'  
BirdyB
BirdyB 24.06.2016 aktualisiert um 17:51:31 Uhr
Goto Top
Der OpenWRT merkt den Verbindungsabbruch scheinbar garnicht:
Fri Jun 24 15:34:11 2016 daemon.notice openvpn(MedCarePro)[9068]: TCPv4_CLIENT WRITE [133] to [AF_INET]217.6.252.116:443: P_DATA_V1 kid=0 DATA len=132
Fri Jun 24 15:34:11 2016 daemon.notice openvpn(MedCarePro)[9068]: TCPv4_CLIENT READ [133] from [AF_INET]217.6.252.116:443: P_DATA_V1 kid=0 DATA len=132
Fri Jun 24 15:34:12 2016 daemon.notice openvpn(MedCarePro)[9068]: TCPv4_CLIENT WRITE [133] to [AF_INET]217.6.252.116:443: P_DATA_V1 kid=0 DATA len=132
Fri Jun 24 15:34:12 2016 daemon.notice openvpn(MedCarePro)[9068]: TCPv4_CLIENT READ [133] from [AF_INET]217.6.252.116:443: P_DATA_V1 kid=0 DATA len=132
Fri Jun 24 15:34:13 2016 daemon.notice openvpn(MedCarePro)[9068]: TCPv4_CLIENT WRITE [133] to [AF_INET]217.6.252.116:443: P_DATA_V1 kid=0 DATA len=132
Fri Jun 24 15:34:13 2016 daemon.notice openvpn(MedCarePro)[9068]: TCPv4_CLIENT READ [133] from [AF_INET]217.6.252.116:443: P_DATA_V1 kid=0 DATA len=132
Fri Jun 24 15:34:14 2016 daemon.notice openvpn(MedCarePro)[9068]: TCPv4_CLIENT WRITE [133] to [AF_INET]217.6.252.116:443: P_DATA_V1 kid=0 DATA len=132
Fri Jun 24 15:34:15 2016 daemon.notice openvpn(MedCarePro)[9068]: TCPv4_CLIENT WRITE [133] to [AF_INET]217.6.252.116:443: P_DATA_V1 kid=0 DATA len=132
Fri Jun 24 15:34:16 2016 daemon.notice openvpn(MedCarePro)[9068]: TCPv4_CLIENT WRITE [133] to [AF_INET]217.6.252.116:443: P_DATA_V1 kid=0 DATA len=132
Fri Jun 24 15:34:17 2016 daemon.notice openvpn(MedCarePro)[9068]: TCPv4_CLIENT WRITE [133] to [AF_INET]217.6.252.116:443: P_DATA_V1 kid=0 DATA len=132
Fri Jun 24 15:34:18 2016 daemon.notice openvpn(MedCarePro)[9068]: TCPv4_CLIENT WRITE [133] to [AF_INET]217.6.252.116:443: P_DATA_V1 kid=0 DATA len=132
Fri Jun 24 15:34:19 2016 daemon.notice openvpn(MedCarePro)[9068]: TCPv4_CLIENT WRITE [133] to [AF_INET]217.6.252.116:443: P_DATA_V1 kid=0 DATA len=132
Fri Jun 24 15:34:20 2016 daemon.notice openvpn(MedCarePro)[9068]: TCPv4_CLIENT WRITE [133] to [AF_INET]217.6.252.116:443: P_DATA_V1 kid=0 DATA len=132
Fri Jun 24 15:34:21 2016 daemon.notice openvpn(MedCarePro)[9068]: TCPv4_CLIENT WRITE [133] to [AF_INET]217.6.252.116:443: P_DATA_V1 kid=0 DATA len=132
colinardo
Lösung colinardo 24.06.2016 aktualisiert um 18:41:32 Uhr
Goto Top
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.
BirdyB
BirdyB 24.06.2016 aktualisiert um 18:53:34 Uhr
Goto Top
Ich habe die Link-MTU jetzt auf 1400 gesetzt. Bei einer TCP-Verbindung dürfte das aber nicht so viele Probleme bringen, oder?

Das jetzige Setup ist: OpenWRT ---> HeimRouter (auch OpenWRT) ---> Internet ---> Sophos

Die einzige Stelle, an der ich mit Wireshark lauschen könnte wäre zwischen OpenWRT und meinem HeimRouter...

Die beiden Verbose-Logs während des Abbruchs habe ich ja schon zur Verfügung gestellt.

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...
colinardo
Lösung colinardo 24.06.2016 aktualisiert um 19:30:09 Uhr
Goto Top
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:
https://forums.untangle.com/openvpn/4214-openvpn-client-disconnects-afte ...
Das jetzige Setup ist: OpenWRT ---> HeimRouter (auch OpenWRT) ---> Internet ---> Sophos
OK
Die 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...
Du solltest halt prüfen ob beide auf die Pings kurz vor dem Abbruch gegenseitig antworten, deswegen Wireshark.
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.
BirdyB
BirdyB 24.06.2016 um 19:45:12 Uhr
Goto Top
Nachdem ich die MTU reduziert habe funktioniert es jetzt auch scheinbar. Ich werde das jetzt mal weiter beobachten und mich mit tcpdump beschäftigen.
Danke erstmal für die Hilfe.
BirdyB
BirdyB 24.06.2016 um 21:21:46 Uhr
Goto Top
Also es war die MTU, die die Probleme verursacht hat. Mit dem OpenWRT läuft es jetzt einwandfrei. Ich werde bald auch nochmal den Mikrotik auspacken und hier die MTU anpassen.
Allen Beteiligten vielen Dank für die Unterstützung!