Der Voice-SBC von Lancom ist einer der besten überhaupt. Er kommt mit den schlimmsten Leitungen klar und kann Dinge, davon kann ein anderes Plastederivat nur träumen. Das hat allerdings auch so seine Nebenwirkungen: Das Ding vertrug sich nicht besonders gut mit OpenVPN.
Mir persönlich ist das bislang nicht aufgefallen, da ich in einem früheren Leben grundsätzlich auch den Lancom selbst habe S2S-VPN terminieren lassen. Auch IPSEC als Client hinter einem Lancom war kein Problem, sofern man das in der Firewall desselben denn auch zugelassen hat.
OpenVPN-Tunnel (über UDP) – klassischerweise 1194 oder irgendwas in der Nähe – je nach Konfiguration – waren in den aktuellen Firmwareversionen jedoch nicht stabil hinzubekommen – Teilweise ist ein Verbindungsaufbau gar nicht mehr hinzubekommen. Dass da der Lancom dahinter steckt, war schwer auszumachen. Der verzweifelte Admin schaut natürlich in die Firewallkonfiguration, liegt hier jedoch falsch.
„Hätten Sie’s denn gerne geschnitten oder am Stück“:
Sofern der SBC von Lancom z.B. mit dem Telekom-Setup-Assistenten (egal ob SIP-Trunk oder Einzel-Leitung) konfiguriert wurde, ist o.g. Konfiguration aktiv. Abgehende Pakete werden entsprechend mit „Reduktion der PMTU & Fragmentierung“ behandelt. Das sollte zurück auf „keine Veränderung“ konfiguriert werden, um das Problem mit OpenVPN zu lösen. Zu finden ist die Konfiguration unter //Konfiguration/Voice Call Manager/Erweitert/QoS.
Auf das Problem bin ich gestoßen, als ich selbst OpenVPN via UDP benützt habe und mir die Verbindung bei Telefonaten über den Lancom permanent abgerissen ist. Was in einigen Anwendungen bestimmt Sinn macht (Link), ist Gift für OpenVPN. Nach meinen Tests musste ich den Lancom nach Konfigurationsänderung einmal durchstarten, damit die Änderung griff.
Getestet auf Lancom 1781VA/VAW, sowie Telekom-branded Lancom R883+ Mit Firmwareständen von 10.32.0021 bis 10.32.0092 zwischen Oktober und November 2019, Telekom SIP oder Telekom SIP-Trunk.