VOIP über VPN funktioniert unter 20.7 nicht mehr

Started by h4p4t3, August 27, 2020, 09:12:48 AM

Previous topic - Next topic
August 27, 2020, 09:12:48 AM Last Edit: September 07, 2020, 07:57:48 AM by h4p4t3
Hallo zusammen,

nach einem etwas holprigen Update und der daraus resultierenden Neuinstallation funktioniert der Zugriff auf eine interne Telefonanlage über OpenVPN nicht mehr zuverlässig. Unter 20.1 lief es noch problemlos. Die Konfiguration von 20.1 wurde in die Neuinstallation von 20.7 eingespielt.

Das Netz sieht so aus: DSL---Fritz.Box-192.168.178.1---192.168.178.4-OPNsense-192.168.20.0/24---Clients

Die OpenVPN-Clients sind im Netz 10.10.0.0/24, die Telefonanlage ist unter 192.168.20.253 zu erreichen.

Es existiert eine Floating rule für die Schnittstellen OpenVPN,intern, die in jede Richtung ohne Einschränkung der Ports Verkehr zwischen 192.168.20.192/26 und 10.10.0.0/24 zulässt.

Das Telefonieren aus dem 192.168.20.0/24-Netz funktioniert ohne Einschränkungen. Das Telefonieren über Softclients aus dem 10.10.0.0/24-Netz funktioniert nicht mehr stabil. Die Verbindung zur Telefonanlage bricht unregelmäßig ab, der Status der Clients aus dem 192.168.20.0/24-Netz wird nicht mehr angezeigt. Sonstige Zugriffe über VPN auf das 192.168.20.0/24-Netz sind nicht eingeschränkt.

Irgendetwas(TM) hat sich durch 20.7 verändert, dass den Zugriff auf die Telefonanlage schwächt.

Mir ist noch folgendes aufgefallen: Die Liveansicht der Firewall-Protokolle wird nicht mehr aktualisiert.  :-\


August 27, 2020, 04:11:17 PM #1 Last Edit: August 27, 2020, 04:13:27 PM by micneu
Kannst du mal bitte einen grafischen netzwerkplan errstellen, das ist aber kein privates jetzt laut rfc192.18.20.0/24?

Gesendet von iPad mit Tapatalk Pro
Internet: Willy.tel Down: 1Gbit/s, UP: 250Mbit/s Glasfaser  |
Router/Firewall: pfSense+ 23.09  |
Hardware: Netgate 6100

Die 192.18.20.0/24 macht mich auch extrem stutzig. Dass die hinter der Sense steht noch mehr. Das sind Public IPs, die da eigentlich nichts zu suchen haben IMHO. :)
"It doesn't work!" is no valid error description! - Don't forget to [applaud] those offering time & brainpower to help you!
Better have some *sense as no(n)sense! ;)

If you're interested in german-speaking business support, feel free to reach out via PM.

August 28, 2020, 10:50:47 AM #3 Last Edit: August 28, 2020, 10:54:43 AM by h4p4t3
Quote from: JeGr on August 28, 2020, 09:37:10 AM
Die 192.18.20.0/24 macht mich auch extrem stutzig. Dass die hinter der Sense steht noch mehr. Das sind Public IPs, die da eigentlich nichts zu suchen haben IMHO. :)
Das ist ein Druckfehler. Ist latürnich 192.168.20.0/24

Präziser im Anhang

Die Fritzbox verfügt nach außen über eine statische IP.

Die Telefonanlage hat sich nicht verändert, der DSL-Zugang wurde aufgebohrt, technisch aber auch unverändert und laut Provider und der Fritzbox stabil.

Aus lauter Verzweiflung habe ich die OPNsense nochmal neu installiert und mit der Konfiguration /vor/ dem Update versehen. Logs aktualisieren sich wieder, keine relevanten Einträge. Auch die Systemlogs vermelden nichts unerwartetes.

Keiner eine Idee?

Ich hab mal versucht, die VPN-Verbindung auf TCP umzustellen. Leider hat das den Zugriff dermaßen verlangsamt, dass kein vernünftiges Arbeiten mehr möglich war.

Mir ist klar, dass das total unspezifisch ist, aber leider spucken die Logs auch nichts aus, was mir mehr Anhaltspunkte liefern könnte.  :'(

Tatsächlich überlege ich, zu 20.1 zurückzukehren. Was natürlich keine sonderlich zufriedenstellende (und auch nur mäßig nachhaltige) Lösung ist.

OpenVPN auf TCP umzustellen bringt eigentlich eher einen Performancegewinn, das würde dann für mich heissen die Pakete sind zu gross, bzw. müssen fragmentiert werden.

Was genau heisst telefonieren geht nicht stabil? Können manche tel und manche nicht, gehts für alle manchmal nicht oder gehts für alle garnicht?

September 02, 2020, 12:06:28 PM #7 Last Edit: September 02, 2020, 12:09:04 PM by h4p4t3
Quote from: mimugmail on September 02, 2020, 10:58:43 AM
OpenVPN auf TCP umzustellen bringt eigentlich eher einen Performancegewinn, das würde dann für mich heissen die Pakete sind zu gross, bzw. müssen fragmentiert werden.
Das ist seltsam. Ich habe unter OpenVPN/Server den bestehenden Eintrag kopiert, auf TCP und Port 1195 geändert, die entsprechende Regel an der externen Schnittstelle ergänzt und an der Fritzbox eine weitere Portweiterleitung eingerichtet.
Quote from: mimugmail on September 02, 2020, 10:58:43 AMWas genau heisst telefonieren geht nicht stabil? Können manche tel und manche nicht, gehts für alle manchmal nicht oder gehts für alle garnicht?
Die Verbindung der Softclients aus dem 10.10.0.0/24-Netz zur Telefonanlage bricht nach ein paar Minuten ab, der Status der Softclients (an-/abgemeldet/abwesend) aus dem 192.168.20.0/24-Netz wird im  10.10.0.0/24-Netz nicht mehr angezeigt, umgekehrt aber schon.
Letzteres lässt mich eigentlich schon eine fehlende Pass-Regel vermuten, aber 1. funktionierte es unter 20.1, 2. schweigt sich das Log der Firewall in diesem Punkt aus. Keine Block-Einträge der Firewall zu Datenverkehr aus dem 10.10.0.0/24-Netz. Was mich nicht wundert, da i.W. zzt. bei diesen Verbindungen alles erlaubt ist.

Bei allen Clients ist als Gateway die 192.168.20.61 eingetragen. Ist es möglich, dass ich (neuerdings) für den OPenVPN-Server irgendwo vermerken muss, dass er Zugriffe auf 10.10.0.0/24 in den VPN-Tunnel leiten soll?

Denn ich kann in den Firewall-Logs keine Zugriffe der Clients auf das VPN-Netz feststellen.

Und was mich wirklich wundert, ist die Ausgabe von Wireshark (siehe Anhang) auf einem Client (10.10.0.6) beim Versuch, mit mir (Telefon 192.168.20.212) zu telefonieren.
Denn die Regel (siehe 2. Anhang) erlaubt das doch ganz explizit.


Quote from: mimugmail on September 03, 2020, 11:41:22 AM
Gibst du auch _VPN zu _Telefon in den floatings frei?
Bei der Richtung der Regel ist 'any' eingetragen. Sollte das nicht ausreichen? Jenseits dessen würde ich doch mit einem entsprechenden Block-Eintrag im Log rechnen.

Nein, es erlaubt inbound und outbound, aber es vertauscht nicht Quelle und Ziel

Ok, ausprobiert. Leider immer noch Abbrüche. Außerdem hat es ja unter 20.1 noch mit dieser Regel ausgereicht.

Da SIP ja nicht so ganz unkompliziert ist, haben wir uns anhand des Firewall-Logs ja daran gegeben, Regeln als 'Antwort' auf die Block-Vorgänge zu definieren.

Mach doch mal einen Packet Capture auf dem LAN und auf OpenVPN und vergleiche die Pakete, dann müsste man ja schnell sehen ob da was nicht passt.