[Problem] Regel für VPN und Telefonanlage

[Nambis]

Moin,

ich habe ein kleines Problem mit einer Telefonanlage und einem Softphone (Client Telefonsoftware), wenn ich mich per VPN einwähle. Sporadisch scheint es zu funktionieren, aber dann gibt es immer wieder Verbindungsabbrüche, laut Hersteller Diagnose, wurde beim Support mitgeteilt, dass Datenpakete nicht korrekt am Client ankommen.

Folgendes Szenario:

Im lokalen Netzwerk selbst funktioniert alles so weit, allerdings über das VPN kommt es noch zu Problemen.

Netze:

Opnsense:

192.168.0.1
192.168.1.1
192.168.100.1

Telefonanlage:

192.168.1.100 (Standart-Gateway 192.168.1.10)
192.168.0.100

FritzBox:

192.168.1.10

VPN-Netz:

192.168.100.0




Firewall Konfiguration:

Ich habe eine NAT Regel erstellt, von Host 192.168.100.20 (VPN-Client) auf das Netz 192.168.1.0, die Software scheint sich damit mit der Anlage verbinden zu können. Allerdings vermute ich, dass die Telefonanalage stateless ebenfalls mit dem VPN Client kommunizieren möchte?

Nun meine Frage, sollte ich für die Telefonanlage (Ansitel) eine Route ins 100 er Netz geben oder reicht eine einfache FW- oder NAT-Regel dafür? Möglicherweise sollte die Verbindung von Telefonanlage zu Client Stateless sein?

Hoffe es könnte mir jemand einen Tipp geben, Danke im Voraus!

[Reiner030]

Hi, eigentlich sollte die Telefonanlage auch ohne NAT den VPN Client "finden" können, denn die Default Route liegt im allgemeinen ja auf der Firewall IP und damit weiss die Firewall - sofern die Ports entsprechend geöffnet sind, wie von dem einen zum anderen Netz gerouted werden muss, um eine Kommunikation zu ermöglichen.

Bei unserer noch verwendeten pfSense ist aber unbekannterweise ebenfalls ein NAT eingerichtet worden, bei dem - erstaunlicherweise nur bei ein Teil der Mitarbeiter - ebenso ein solches Problem auftritt.

Ich hatte das mit dem sehr guten und hier auch hilfreichen PhonerLite ausprobiert (größerer Bruder wäre Phoner), bei dem man die Diagnose aktivieren und so die Kommunikation zwischen VPN Client und Telefonanlage mitlesen kann.

In diesen Headern war der Client lt. Status der Telefonanlage nicht mit seiner IP, sondern der der FW angemeldet;
Frage ist dann natürlich, wie die Telefonanlage wissen wollte, auf welchem der x Clients sie Anfragen zustellen soll, zumindest wenn die UDP Session TTL zu groß ist
Dazu gab es hier schon Fragen/Lösung:
Man muss die FW irgendwo in den Fiirewall Advanced Settings auf "Moderate" states setzen, damit die UDP TTL länger ist.
Und man sollte zusätzlich die beim Client eingestellte Registrationsintervalle überprüfen und ggf. auch verringern, damit diese z.B. alle 60 bis spätestens 90s die UDP Verbindung refreshen und somit auch die UDP Session in der Firewall.

[Nambis]

Ich hatte das mit dem sehr guten und hier auch hilfreichen PhonerLite ausprobiert (größerer Bruder wäre Phoner), bei dem man die Diagnose aktivieren und so die Kommunikation zwischen VPN Client und Telefonanlage mitlesen kann.

In diesen Headern war der Client lt. Status der Telefonanlage nicht mit seiner IP, sondern der der FW angemeldet;
Frage ist dann natürlich, wie die Telefonanlage wissen wollte, auf welchem der x Clients sie Anfragen zustellen soll, zumindest wenn die UDP Session TTL zu groß ist
Dazu gab es hier schon Fragen/Lösung:
Man muss die FW irgendwo in den Fiirewall Advanced Settings auf "Moderate" states setzen, damit die UDP TTL länger ist.

Hallo,

danke schön für die Infos, ich werde das Testen und mir diese Konfiguration anschauen. Mittels Firewallregel kann dies nicht gelöst werden?

[Reiner030]

Wenn eine NAT Regel von OpenVPN=> SIP Netz vorhanden ist, kann die nicht "reverse" in die andere Richtung funktionieren ohne Aktive NAT Verbindung des Clients zur PBX, da die FW selber nur die Session kennt und keine PBX<=> Client Zuordnungen.
Daher muss auch auf eine hohe "moderate" TTL geachtet werden und kurze Registrierungs-Intervalle am Client.

Und durch die NAT Regel wird in der Regel ja die entsprechende FW Regel angelegt, die dann auch für die "Antwortpakete" gültig ist (bzw. was auch noch zu der Session gehört)

Wenn möglich, würde ich eher das NAT abschaffen, da dies über allgemeines Routing der FW regelbar ist.