VPN: Verbindungsprobleme

[heisenberg]

Hallo zusammen,

Ist jetzt nicht hauptsächlich Debian, aber vielleicht interessiert es Euch doch, weil es ein VPN mit OpenVPN und mit Debian als ein Client ist.

ich habe gerade hier eine Standortvernetzung und dabei kleinere Verbindungsprobleme mit VPN. Das VPN ist von einer Securepoint auf Basis von OpenVPN. Ich habe gelegentliche VPN-Verbindungsaussetzer, welche sich in kurzzeitig eingefrorenen RDP-Sitzungen zeigen(2 - 20 pro Tag).

Der Hersteller(Securepoint) sagt nun, dass das Leitungsprobleme sind.

Ich bin da skeptisch und habe etwas getestet. Nachdem der Kunde erst nach der Installation neuer Geräte mit einhergehender Änderung der Firmwareversion(=OS) die Verbindungsabbrüche berichtet hat frage ich mich, ob es dann doch an der neuen HW oder SW liegt.

Mich würde ...

a) mal Eure Meinung dazu interessieren: Ist das plausibel dass es an der Leitung liegt?
b) Wie kann man Leitungsprobleme noch besser testen(Datenintegrität auf Dauer mit geringer Datenlast auf den Verbindungen)?

Zum VPN:

* VPN über TCP
* MTU Testweise heruntergestellt auf 1200 für den Testbetrieb(ist bei einfachen Pings sowieso ohne Belang)
* Keine Kompression

Der Aufbau

Code: Alles auswählen

[ A lokale VM(Rechenzentrum) ]
     |
     | ( 1 GBit Anbindung )
     |
[ Internet ]
     |
     | ( 250 MBit/s Download / 100 MBit/s Upload Anbindung  )
     |
[ B Internetrouter(public ip) ]     
     |
[ C Standort-VPN-Server(public ip) ]     
     |
     |  
     |
[ D VM im Standort-LAN ]  (freigegeben über VPN)

Ich habe jetzt mit einem Script (https://codeberg.org/megabert/script-pa ... /pingcheck) die Verbindung mit folgenden Strecken getestet:

Von A -> B
Von A -> C
Von A -> D

So sehen die Verbindungsprotokolle aus:

Von A -> B (Entfernter Router)

Code: Alles auswählen

Wed 24 Jun 2020 01:13:37 PM UTC : 
Wed 24 Jun 2020 01:13:37 PM UTC : Checking public-ip-router every 1 Seconds timeout 6 seconds
Wed 24 Jun 2020 01:13:37 PM UTC : 
Wed 24 Jun 2020 01:13:39 PM UTC : Inital state: OK
Wed 24 Jun 2020 02:13:40 PM UTC : state still OK
Wed 24 Jun 2020 03:13:43 PM UTC : state still OK
Wed 24 Jun 2020 04:13:44 PM UTC : state still OK
Wed 24 Jun 2020 05:13:47 PM UTC : state still OK
Wed 24 Jun 2020 06:13:48 PM UTC : state still OK
Wed 24 Jun 2020 07:13:49 PM UTC : state still OK
Wed 24 Jun 2020 08:13:51 PM UTC : state still OK
Wed 24 Jun 2020 09:13:52 PM UTC : state still OK
Wed 24 Jun 2020 10:13:54 PM UTC : state still OK
Wed 24 Jun 2020 11:13:56 PM UTC : state still OK
Thu 25 Jun 2020 12:13:58 AM UTC : state still OK
Thu 25 Jun 2020 01:14:00 AM UTC : state still OK
Thu 25 Jun 2020 02:14:02 AM UTC : state still OK
Thu 25 Jun 2020 03:14:04 AM UTC : state still OK
Thu 25 Jun 2020 04:14:07 AM UTC : state still OK
Thu 25 Jun 2020 05:14:09 AM UTC : state still OK
Thu 25 Jun 2020 06:14:12 AM UTC : state still OK
Thu 25 Jun 2020 07:14:15 AM UTC : state still OK
Thu 25 Jun 2020 08:14:18 AM UTC : state still OK
Thu 25 Jun 2020 09:14:21 AM UTC : state still OK
Thu 25 Jun 2020 10:14:24 AM UTC : state still OK
Thu 25 Jun 2020 11:14:26 AM UTC : state still OK
Thu 25 Jun 2020 12:14:29 PM UTC : state still OK
Thu 25 Jun 2020 01:14:30 PM UTC : state still OK
Thu 25 Jun 2020 02:14:32 PM UTC : state still OK
Thu 25 Jun 2020 03:14:34 PM UTC : state still OK
Thu 25 Jun 2020 04:14:36 PM UTC : state still OK
Thu 25 Jun 2020 05:14:38 PM UTC : state still OK
Thu 25 Jun 2020 06:14:40 PM UTC : state still OK
Thu 25 Jun 2020 07:14:42 PM UTC : state still OK
Thu 25 Jun 2020 08:14:44 PM UTC : state still OK
Thu 25 Jun 2020 09:14:47 PM UTC : state still OK
Thu 25 Jun 2020 10:14:49 PM UTC : state still OK
Thu 25 Jun 2020 11:14:51 PM UTC : state still OK
Fri 26 Jun 2020 12:14:53 AM UTC : state still OK
Fri 26 Jun 2020 01:14:55 AM UTC : state still OK
Fri 26 Jun 2020 02:14:57 AM UTC : state still OK
Fri 26 Jun 2020 03:14:59 AM UTC : state still OK
Fri 26 Jun 2020 04:15:00 AM UTC : state still OK
Fri 26 Jun 2020 05:15:02 AM UTC : state still OK
Fri 26 Jun 2020 06:15:04 AM UTC : state still OK
Fri 26 Jun 2020 06:28:31 AM UTC : Statechange to FAIL 
Fri 26 Jun 2020 06:28:38 AM UTC : Statechange to OK (after DOWNTIME of 7 seconds)
Fri 26 Jun 2020 07:28:39 AM UTC : state still OK
Fri 26 Jun 2020 08:28:41 AM UTC : state still OK
Fri 26 Jun 2020 09:28:42 AM UTC : state still OK
Fri 26 Jun 2020 10:28:43 AM UTC : state still OK
Fri 26 Jun 2020 11:28:45 AM UTC : state still OK
Fri 26 Jun 2020 12:28:47 PM UTC : state still OK
Fri 26 Jun 2020 01:28:50 PM UTC : state still OK
Fri 26 Jun 2020 02:28:53 PM UTC : state still OK
Fri 26 Jun 2020 03:28:55 PM UTC : state still OK
Fri 26 Jun 2020 04:28:56 PM UTC : state still OK
Fri 26 Jun 2020 05:28:58 PM UTC : state still OK
Fri 26 Jun 2020 06:29:00 PM UTC : state still OK
Fri 26 Jun 2020 07:29:01 PM UTC : state still OK
Fri 26 Jun 2020 08:29:03 PM UTC : state still OK
Fri 26 Jun 2020 09:29:05 PM UTC : state still OK

Von A -> C (VPN-Server)

Code: Alles auswählen

$ ./pingtest vpn-server-public-ip 2>&1
Fr, 26. Jun 2020 14:16:18 :
Fr, 26. Jun 2020 14:16:19 : Checking vpn-server-public-ip every 1 Seconds timeout 6 seconds
Fr, 26. Jun 2020 14:16:20 :
Fr, 26. Jun 2020 14:16:24 : Inital state: OK
Fr, 26. Jun 2020 15:16:27 : state still OK
...(wiederholte Zeilen entfernt)...
Mi,  1. Jul 2020 13:22:05 : state still OK

Von A -> D (Entfernte VM): Ausschnitt

Code: Alles auswählen

./pingtest 172.31.30.65
Fr, 26. Jun 2020 14:14:40 :
Fr, 26. Jun 2020 14:14:41 : Checking 172.31.30.65 every 1 Seconds timeout 6 seconds
Fr, 26. Jun 2020 14:14:42 :
Fr, 26. Jun 2020 14:14:47 : Inital state: OK
Fr, 26. Jun 2020 14:23:37 : Statechange to FAIL
Fr, 26. Jun 2020 14:23:43 : Statechange to OK (after DOWNTIME of 6 seconds)
Fr, 26. Jun 2020 15:23:48 : state still OK
Fr, 26. Jun 2020 15:23:58 : Statechange to FAIL
Fr, 26. Jun 2020 15:24:05 : Statechange to OK (after DOWNTIME of 8 seconds)
Fr, 26. Jun 2020 16:24:12 : Statechange to FAIL
Fr, 26. Jun 2020 16:24:24 : Statechange to OK (after DOWNTIME of 12 seconds)
Fr, 26. Jun 2020 17:24:29 : state still OK
Fr, 26. Jun 2020 17:24:39 : Statechange to FAIL
Fr, 26. Jun 2020 17:24:46 : Statechange to OK (after DOWNTIME of 7 seconds)
Fr, 26. Jun 2020 18:24:49 : Statechange to FAIL
Fr, 26. Jun 2020 18:25:04 : Statechange to OK (after DOWNTIME of 14 seconds)
Fr, 26. Jun 2020 19:25:10 : state still OK
Fr, 26. Jun 2020 19:25:19 : Statechange to FAIL
Fr, 26. Jun 2020 19:25:24 : Statechange to OK (after DOWNTIME of 4 seconds)
Fr, 26. Jun 2020 20:25:32 : Statechange to FAIL
Fr, 26. Jun 2020 20:25:49 : Statechange to OK (after DOWNTIME of 16 seconds)
Fr, 26. Jun 2020 21:25:58 : Statechange to FAIL
Fr, 26. Jun 2020 21:26:04 : Statechange to OK (after DOWNTIME of 6 seconds)
Fr, 26. Jun 2020 21:59:54 : Statechange to FAIL
Fr, 26. Jun 2020 22:00:02 : Statechange to OK (after DOWNTIME of 8 seconds)
Fr, 26. Jun 2020 22:26:11 : Statechange to FAIL
Fr, 26. Jun 2020 22:26:24 : Statechange to OK (after DOWNTIME of 14 seconds)
Fr, 26. Jun 2020 23:26:31 : Statechange to FAIL
Fr, 26. Jun 2020 23:26:44 : Statechange to OK (after DOWNTIME of 12 seconds)
Fr, 26. Jun 2020 23:43:42 : Statechange to FAIL
Fr, 26. Jun 2020 23:43:56 : Statechange to OK (after DOWNTIME of 14 seconds)
Sa, 27. Jun 2020 00:44:00 : state still OK
Sa, 27. Jun 2020 01:44:01 : state still OK
Sa, 27. Jun 2020 02:44:06 : state still OK
Sa, 27. Jun 2020 03:44:08 : state still OK
Sa, 27. Jun 2020 04:44:12 : state still OK
Sa, 27. Jun 2020 05:44:15 : state still OK
Sa, 27. Jun 2020 06:00:13 : Statechange to FAIL
Sa, 27. Jun 2020 06:00:20 : Statechange to OK (after DOWNTIME of 9 seconds)
Sa, 27. Jun 2020 07:00:24 : state still OK
Sa, 27. Jun 2020 08:00:28 : state still OK
Sa, 27. Jun 2020 09:00:29 : state still OK

Ganzes Log: 41081

Für D habe ich noch weitere Alternative Ziele um gleichzeitige Aussetzer zu entdecken. Auch für A habe ich einmal eine Windows-VM und zusätzliich eine Linux-VM mit openvpn als client. Das Script läuft auf Windows unter Cygwin. Die Aussetzer auf den verschiedenen VMs sind manchmal zeitgleich, manchmal aber auch nicht.

VPN-Client-Config

Code: Alles auswählen

client
dev tun
tun-mtu 1200
mssfix
proto tcp
float
remote public-ip-vpn-server 1295
nobind
persist-key
persist-tun
ca /etc/openvpn/xxx/ca.crt
cert /etc/openvpn/xxx/X.crt
key /etc/openvpn/xxx/X.key
verb 3
mute 20
auth-user-pass
route-method exe
route-delay 2
auth-user-pass /etc/openvpn/login.conf
script-security 3

VPN-Server Befehlszeile(keine Komplettconfig)

Code: Alles auswählen

openvpn 
     --config /etc/openvpn/openvpn.conf 
     --management /tmp/openvpn_management_D9261295.sock unix 
     --dev tun11 
     --mode server 
     --tls-server 
     --proto tcp 
     --tun-mtu 1200 
     --ca /etc/openvpn/homeoffice-test.ca 
     --crl-verify /etc/openvpn/homeoffice-test.crl 
     --cert /etc/openvpn/homeoffice-test.cert 
     --key /etc/openvpn/homeoffice-test.cert 
     --syslog openvpn-homeoffice-test 
     --plugin /usr/lib/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn_local 
     --username-as-common-name --server 172.29.12.0 255.255.255.0 
     --topology subnet --client-config-dir /var/openvpn/homeoffice-test 
     --lport 1295 
     --reneg-sec 28800 
     --cipher AES-128-CBC 
     --auth SHA256 
     --push route 172.31.0.0 255.255.0.0 
     --keepalive 10 120

zugehörige openvpn.conf

Code: Alles auswählen

iproute "/sbin/ip"
plugin  "/usr/lib/openvpn/plugins/openvpn-session.so"
persist-tun
persist-key
verb 4
dev-type tun
tls-version-min 1.0
tls-version-max 1.2
tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA384:TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA384:TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA:TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA256:TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA256:TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA:TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHA256:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-ECDHE-RSA-WITH-3DES-EDE-CBC-SHA:TLS-ECDHE-ECDSA-WITH-3DES-EDE-CBC-SHA:TLS-DHE-RSA-WITH-3DES-EDE-CBC-SHA:TLS-RSA-WITH-AES-256-GCM-SHA384:TLS-RSA-WITH-AES-128-GCM-SHA256:TLS-RSA-WITH-AES-256-CBC-SHA256:TLS-RSA-WITH-AES-256-CBC-SHA:TLS-RSA-WITH-AES-128-CBC-SHA256:TLS-RSA-WITH-AES-128-CBC-SHA:TLS-RSA-WITH-3DES-EDE-CBC-SHA
dh /rootdisk/config/dhparams2048.pem

[MSfree]

...welche sich in kurzzeitig eingefrorenen RDP-Sitzungen zeigen(2 - 20 pro Tag)...
a) mal Eure Meinung dazu interessieren: Ist das plausibel dass es an der Leitung liegt?

Ich hatte auch mal unerklärliche Probleme mit mit OpenVPN-Aussetzern, bei denen der Tunnel einfach eingefroren ist und sich nicht selbst neu etabliert hat. In meinem Fall war die Fragmentgröße die Ursache. Ich mußte

Code: Alles auswählen

fragment 750
mssfix 750

in die Konfigurationen von Client und Server eintragen, bis es stabil lief. Die 750 habe ich allerdings experimentell ermittelt. Warum das trotz 1492 Byte großer DSL-Pakete nicht mit größeren Werten ging, kann ich dir aber nicht sagen. Ich war froh, daß es mit der kleineren Größe endlich stabil war.

[heisenberg]

Danke für den Tip.

Laut Dokumentation ist das nur im Zusammenhang mit UDP als Protokoll nutzbar. (ob das hilft, wenn ich dafür wieder auf UDP zurückstelle?)

https://openvpn.net/community-resources ... envpn-2-4/

[MSfree]

Laut Dokumentation ist das nur im Zusammenhang mit UDP als Protokoll nutzbar.

OK, der von mir erwähnte Tunnel war von vorn herein als UDP geplant. Ob UDP oder TCP scheint soweiso eher eine Glaubens- als eine Technikfrage zu sein. Mir schien es logischer, UDP zu verwenden.

Dieses Einfrierverhalten habe ich aber auch schon mit SSH-Tunneln (also TCP) erlebt, wo es ebenfalls an der MTU lag.

Ich würde vorschlagen, du probierst mit nochmals deutlich kleineren MTU-Werten, wenn du bei TCP bleiben willst. Ich konnte das Einfrieren jedenfalls ziemlich einfach provozieren, in dem ich mich über den VPN-Tunnel auf einer Remote-Maschine per SSH eingelogt habe und dann einfach eine große Menge Text, wie mit

Code: Alles auswählen

find /

habe anzeigen lassen.

[heisenberg]

Danke nochmals. Werde ich ausprobieren.

Ob TCP oder UDP ist mir eigentlich wurscht. Wichtig ist, dass das VPN-stabil ist. Da dachte ich mir, dass TCP aufgrund der Verbindungssicherung weniger anfällig ist.

[mat6937]

Da dachte ich mir, dass TCP aufgrund der Verbindungssicherung weniger anfällig ist.

Das Gegenteil kann der Fall sein. Z. B.:

Note that the upper and the lower layer TCP have different timers. When an upper layer connection starts fast, its timers are fast too. Now it can happen that the lower connection has slower timers, perhaps as a leftover from a period with a slow or unreliable base connection.
Imagine what happens when, in this situation, the base connection starts losing packets. The lower layer TCP queues up a retransmission and increases its timeouts. Since the connection is blocked for this amount of time, the upper layer (i.e. payload) TCP won't get a timely ACK, and will also queue a retransmission. Because the timeout is still less than the lower layer timeout, the upper layer will queue up more retransmissions faster than the lower layer can process them. This makes the upper layer connection stall very quickly and every retransmission just adds to the problem - an internal meltdown effect.
TCPs reliability provisions backfire here. The upper layer retransmissions are completely unnecessary, since the carrier guarantees delivery - but the upper layer TCP can't know this, because TCP always assumes an unreliable carrier.

Quelle: http://sites.inka.de/~W1011/devel/tcp-tcp.html
(oder Gleichwertiges im Internet).

[TomL]

* VPN über TCP

Das ist keine so gute Idee, wenn man die Performance im Auge behalten muss. Der primäre Unterschied zwischen UDP und TCP ist, dass UDP zustandslos ist, also keine 'Mechanismen' zur Fehlerkorrektur beinhaltet. Dieses Manko behebt OpenVPN durch ein Protokoll auf dem Control-Channel, was funktional dem DTLS entspricht. Das bedeutet, wenn Du TCP für OpenVPN wählst, findet die Fehlerbehandlung mit vollem Overhead auf dem Network-Stack zweimal statt, was sich natürlich zwangsläufig auf die Performance auswirkt. OpenVPN und TCP sollte imho nur 'ne Notlösung sein.

Ich würde außerdem
tun-mtu 1200
ersetzen durch
link-mtu 1432

tun-mtu mit nur 1200 erzwingt zu vorschnell eine Fragmentierung der Pakete.....der Default-Wert ist 1500, ich würde den nicht verkleinern, um eben nicht unter der regulären Paketgröße zu landen, die im Regelfall höher ist, als 1200. Ich könnte mir schon vorstellen, dass das ein Problemverursacher ist.

[heisenberg]

Zum Thema TCP

Das habe ich erst auf TCP umgestellt, nachdem die Problem auf UDP aufgetreten waren um zu schauen, ob's damit besser wird.

Zum Thema MTU

Die habe ich mal auf 750 heruntergesetzt. Das hat auch keine Änderung gebracht.

Mein Verdacht war anfangs und ist jetzt auch wieder, dass es ein Softwarefehler des VPN-Servers(Securepoint) ist, weil ich anfangs und jetzt auch wieder eine relative Regelmässigkeit in den Aussetzern sehe. Ungefähr alle Stunde gibt es Aussetzer:

Code: Alles auswählen

Tue 30 Jun 2020 05:30:19 PM UTC : 
Tue 30 Jun 2020 05:30:19 PM UTC : Checking 172.31.30.65 every 1 Seconds timeout 6 seconds
Tue 30 Jun 2020 05:30:19 PM UTC : 
Tue 30 Jun 2020 05:30:21 PM UTC : Inital state: OK
...
Wed 01 Jul 2020 09:13:09 PM UTC : Statechange to FAIL 
Wed 01 Jul 2020 09:13:23 PM UTC : Statechange to OK (after DOWNTIME of 14 seconds)
Wed 01 Jul 2020 10:13:24 PM UTC : state still OK
Wed 01 Jul 2020 10:14:26 PM UTC : Statechange to FAIL 
Wed 01 Jul 2020 10:14:43 PM UTC : Statechange to OK (after DOWNTIME of 17 seconds)
Wed 01 Jul 2020 11:14:44 PM UTC : state still OK
Wed 01 Jul 2020 11:15:40 PM UTC : Statechange to FAIL 
Wed 01 Jul 2020 11:15:57 PM UTC : Statechange to OK (after DOWNTIME of 17 seconds)
Thu 02 Jul 2020 12:15:59 AM UTC : state still OK
Thu 02 Jul 2020 12:16:58 AM UTC : Statechange to FAIL 
Thu 02 Jul 2020 12:17:11 AM UTC : Statechange to OK (after DOWNTIME of 13 seconds)
Thu 02 Jul 2020 01:07:24 AM UTC : Statechange to FAIL 
Thu 02 Jul 2020 01:07:29 AM UTC : Statechange to OK (after DOWNTIME of 5 seconds)
Thu 02 Jul 2020 01:18:13 AM UTC : Statechange to FAIL 
Thu 02 Jul 2020 01:18:30 AM UTC : Statechange to OK (after DOWNTIME of 17 seconds)
Thu 02 Jul 2020 02:18:31 AM UTC : state still OK
Thu 02 Jul 2020 02:19:30 AM UTC : Statechange to FAIL 
Thu 02 Jul 2020 02:19:47 AM UTC : Statechange to OK (after DOWNTIME of 17 seconds)
Thu 02 Jul 2020 03:19:48 AM UTC : state still OK
Thu 02 Jul 2020 03:20:44 AM UTC : Statechange to FAIL 
Thu 02 Jul 2020 03:20:56 AM UTC : Statechange to OK (after DOWNTIME of 12 seconds)
Thu 02 Jul 2020 04:20:57 AM UTC : state still OK
Thu 02 Jul 2020 04:21:58 AM UTC : Statechange to FAIL 
Thu 02 Jul 2020 04:22:15 AM UTC : Statechange to OK (after DOWNTIME of 17 seconds)
Thu 02 Jul 2020 05:22:18 AM UTC : state still OK
Thu 02 Jul 2020 05:23:13 AM UTC : Statechange to FAIL 
Thu 02 Jul 2020 05:23:30 AM UTC : Statechange to OK (after DOWNTIME of 17 seconds)
Thu 02 Jul 2020 06:23:33 AM UTC : state still OK
Thu 02 Jul 2020 06:24:31 AM UTC : Statechange to FAIL 
Thu 02 Jul 2020 06:24:48 AM UTC : Statechange to OK (after DOWNTIME of 17 seconds)
Thu 02 Jul 2020 07:24:51 AM UTC : state still OK
Thu 02 Jul 2020 07:25:49 AM UTC : Statechange to FAIL 
Thu 02 Jul 2020 07:26:06 AM UTC : Statechange to OK (after DOWNTIME of 17 seconds)
Thu 02 Jul 2020 08:26:08 AM UTC : state still OK
Thu 02 Jul 2020 08:27:04 AM UTC : Statechange to FAIL 
Thu 02 Jul 2020 08:27:21 AM UTC : Statechange to OK (after DOWNTIME of 17 seconds)
Thu 02 Jul 2020 09:27:24 AM UTC : state still OK
Thu 02 Jul 2020 09:28:22 AM UTC : Statechange to FAIL 
Thu 02 Jul 2020 09:28:35 AM UTC : Statechange to OK (after DOWNTIME of 13 seconds)
Thu 02 Jul 2020 09:36:15 AM UTC : Statechange to FAIL 
Thu 02 Jul 2020 09:36:25 AM UTC : Statechange to OK (after DOWNTIME of 10 seconds)

Grundsätzlich frage ich mich, wie bei Verlusten von Ping-Paketen von 56 Bytes Paketgrösse eine MTU von 1400 eine Rolle spielen kann?

[eggy]

Kannst Du das Logging von Client weiter hochdrehen? Ich würd bei dem sauberen Muster in Richtung periodische Erneuerung such, also vpn re-keying, dhcp lease renew, etc. Mal den Traffic für die paar fraglichen Minuten mitschneiden und schauen, was da dann grad über die Leitung geht, irgendwelche timeouts? Evtl noch nen zusätzlichen Eintrag ins If-up/down Script tun (nicht das vom Tunnel, sondern das von der nic über die der Tunnel läuft), wäre interessant zu wissen, obs vielleicht daran liegt, dass dem Tunnel das drunterliegende device kurz wegspringt (wahrscheinlich nicht, aber eh man ewig an der falschen Stelle sucht).

[heisenberg]

Ich habe das Problem mit dem Securepoint Support weiter erörtert und die Ursache gefunden.

Die Ursache war die regelmässige Re-Authentifizierung. Die Authentifizierung läuft auf dem System über eine AD-Domäne. Das benötigt auf der Firewall eine funktionsfähige Vorwärts- und Rückwärtsauflösung der Firewallhostnamen (Host->IP,IP->Host). Die Rückwärtsauflösung hat gefehlt. Demzufolge gab es da timeouts und kurzfristige Verzögerungen bei der regelmässigen Re-Authentifzierung.

[eggy]

Danke für die Info