Guten Tag zusammen,

ich verwende PhonerLite und habe das Problem, dass nach jedem Erwachen meine Rechners aus dem Ruhezustand extrem viele Registrierungsversuche in minimalen Zeitabständen fehlschlagen, was jedes Mal sofort zu einer Sperrung meiner IP beim Anbieter führt.

Ich habe dies heute zum ersten Mal beobachtet, indem ich PhonerLite direkt nach dem Erwachen geöffnet habe.
Das "Lämpchen Icon" in der Statusleiste blinkt sehr schnell abwechselnd grün und rot. Ebenso schnell wechselt der Statustext. Irgendwann hört PhonerLite auf und in der Statusleiste verbleibt die rote Lampe mit Text ... <Connectivity checks failed>

Das ist extrem lästig, da es sich um meinen Arbeitsrechner handelt und damit jedes Mal für alle Mitarbeiter im Büro die Telefonie ausfällt bis beim Anbieter die Sperre wieder aufgehoben wurde.
Eventuell relevant: auf dem Rechner ist dauerhaft eine VPN-Verbindung aktiv, die aber keinen generischen Webtraffic, sondern lediglich interne IP-Bereiche tunnelt.
Allerdings kommen die Pakete ja offensichtlich beim Anbieter an.. 

Ich habe einen bereinigten Debug Log angehangen. Um 09:29 hatte ich dann die IP-Sperre wieder aufheben lassen und manuell eine erneute Registrierung angestoßen, indem ich auf die rote Lampe im Statusbereich geklickt habe.
Abgesehen von diesem Problem funktioniert die Software stets einwandfrei, keine Registrierungsabbrüche oder sonstige Phänomene. 

Viele Grüße

Das liegt nahe und ich werde beobachten, ob ein fester Zusammenhang mit der über den Ruhezustand "aktiven" VPN Verbindung besteht. Für mich allerdings nicht weniger kurios sollte dem tatsächlich so sein, da über das VPN lediglich lokale Netze a la 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 gepushed werden. Vor allem scheinen die Pakete auch anzukommen sonst würde mein VoIP Provider uns nicht sperren.
Es scheint mir so als würden während des Reconnecting des VPN Tunnels nach dem Aufwachen die Antworten auf meine REGISTER-Pakete nicht korrekt zu meinem Gerät/PhonerLite durchgestellt werden.

PhonerLite erhält nie eine Antwort -> schickt wiederholt erneute REGISTER -> VoIP PBX beim Anbieter intrepretiert das als failed auth (fail2ban) -> nach n-mal wird die IP gesperrt


Wenn man unter Konfiguration -> Server in der Sektion Proxy/Registrar den Haken bei Registrierung entfernt, wird die komplette Registrierung deaktiviert. Der Timeout, der dort einzustellen ist, scheint auch lediglich für das erneuern der Registrierung zu sein.
Wäre es theoretisch möglich ein Timeout nach jedem REGISTER, das keine Antwort erhält, zu setzen?

Ok, danke für die Info bzgl. der SIP RFC.

Unser VoIP Provider (easybell) ist öffentlich erreichbar. Wir nutzen deren Cloud PBX, wo sich die Telefone direkt registrieren (pbx.easybell.de). Der Traffic wird damit auch nicht über den VPN getunnelt. Eventuell war das unklar. 
Ich kann es mal mit der statischen IP versuchen, sehe in dem Kontext allerdings den Sinn dahinter nicht.

Werde versuchen mir die Pakete anzuschauen. Mal schauen, ob ich es hinkriege, dass Wireshark über einen Ruhezustand hinweg "aufnimmt", oder ich extern loggen muss.

Genau das ist der Fall.

Bin bisher noch nicht dazu gekommen der Sache weiter nachzugehen.

Hmm, das klingt tatsächlich sehr naheliegend. Der Rechner wacht auf, der openVPN Client blockiert noch den Netzwerkadapter, während er die Verbindung mit dem VPN wiederherstellt und diverse lokale Routen auf den virtuellen Adapter umlenkt. Das Verhalten, dass alle Anwendungen erst nach Wiederaufbau der VPN Verbindung allgemein kommunizieren können, lässt sich auch tatsächlich aus Nutzerperspektive beobachten, sofern mich mein Gedächtnis gerade nicht täuscht.

Ich habe die Stelle im RFC gefunden und die Sprache ist dort von "IF unreliable transport is being used". Wie du sagst also im Falle von UDP.

Ich habe daher mal die Verbindungsart in PhonerLite auf TCP geändert. Eventuell verhindert das genau dieses Verhalten..? Ich werde weiter beobachten.

Update an der Stelle: leider hat auch die Umstellung auf TCP keine Abhilfe geschaffen.

Ich möchte vorsichtig behaupten, dass das Setzen der Einstellung Abhilfe geschaffen hat.
Allerdings hat in der Zwischenzeit auch ein neuer VPN Server den bisherigen abgelöst. Die config dort ist aber grundsätzlich gleich geblieben.

Ich hatte bisher keine Zeit das ge­naus­tens zu testen. Daher das nur als Vorbehalt für alle, die irgendwie auf diesen Thread stoßen.