Pascom 18 - Verständnisfragen zum Setup

Support
1

Hallo zusammen,

ich habe in dieser Woche viel Zeit verloren und Ärger gehabt, weil ich wohl ein grundlegendes Verständnisproblem mit der Pascom 18 habe. Vielleicht kann mir ja jemand helfen und den Knoten durchschlagen.

Vorbedingung: Es handelt sich immer im onsite-Installationen und die Smartphones sollen integriert werden.

Zum Setup:

Kunde A:
Internes Netz 192.168.46.0/24, DNS 192.168.46.7 (=DC & DNS), GW: 192.168.46.100 (Lancom-Router)

Pascom läuft auf Hyper-V mit einem Netzwerkinterface, 192.168.46.5, GW; 192.168.46.100, DNS 1.1.1.1 (=externer DNS), FQDN: mycustomer.firma.de

Auf dem Interface alles im Standard belassen und auch noch kein FQDN gesetzt.

Die Telefone habe ich neu provisioniert mit https://192.168.46.5:8884/… Bis zu diesem Punkt funktioniert nun alles, wie bereits mit Pascom 17 seit über einem Jahr.

Doch nun fangen meine (Verständnis-)Probleme an. Für die Smartphone-Integration habe ich das Setup wie folgt angepasst:

  • Einragen eines FQDN-Namen im Netzwerk-Interface der Pascom
  • Nat-Regeln im Router angelegt
  • Let’s Encypt-Zertifikat erstellt
  • auf dem Windows-DC (192.168.46.7 im lokalen Netz einen DNS-Eintrag für den FQDN, der auf die lokale IP der Pascom verweist (damit der interne VoiP-Traffic auch im lokalen Netz bleibt) = Split-DNS
  • Provisionierung der Telefone mit der geänderten URL, die ja jetzt den FQDN enthält

Von extern (also außerhalb des Kunden-Netzwerkes) funktioniert das nun soweit, dass ich mich mit der App oder auch einem Telefon verbinden kann. Gespräche nach extern können sowohl ankommend als auch abgehend geführt werden.

Schwierigkeiten macht die Telefonie innerhalb des Netzwerkes des Kunden. Gesprächsaufbau intern oder nach extern klappt noch, es gibt aber dann kein Audio und ich verstehe den Grund nicht, in erster Linie vermutlich, weil ich nicht blicke, wie die Pascom da arbeitet. Auch der Zugriff auf das Telefonbuch der Pascom über LDAP-S funkttioniert so nicht.

Testweise habe ich dann den DNS auf der Pascom ebenfalls auf den internen DNS 192.168.46.7 eingestellt, dann bekommen ich aber beim Pairen die Meldung, dass eine Interne IP verwendet wird und die App von außerhalb nicht funktioniert. Also wieder zurück auf 1.1.1.1 (extener DNS). Den nutze ich übrigens auch, um schneller Änderungen mitzubekommen, weil die Telekom-DNS-Einträge sich ja doch sehr oft ändern, was dann wieder andere Probleme nach sich zieht.

Warum zur Hölle bekomme ich kein Audio, dann kann doch so schwer nicht sein! Liegt es daran, dass bedingt durch den FQDN in der Pascom und unterschiedliche DNS Probleme beim Routing enstehen?

Ich war bisher immer der Meinung, Split-DNS ist eine legitime Art, sowas zu lösen.

Bin dankbar für jeden Hinweis, der mir Licht ins Dunkel bringt, damit ich nicht länger sinnlos Zeit verbrenne mit Experimenten.

Vielen Dank und eine schönes drittes Advent-Wochenende.

Michael

1 Like
2

Hi Michael,

das Problem ist meiner Meinung nach der Split DNS. Dadurch, dass du bei der Pascom den 1.1.1.1 DNS Server hast, löst der Kamailio deinen FQDN mit der externen IP auf. Die Pakete für die SRTP einhalten damit dann die IP-Adresse der externen Adresse. Dies ist bei der internen Telefonie dann das Problem.
Mein Vorschlag, du fügst deiner Pascom VM ein 2. Netzwerkinterface hinzu mit der IP z.B. 192.168.47.6 und provisionierst die internen Telefone dann über das 2. Interface. Dieses Interface benutzt du nur für interne Telefonie und LDAP.
Alternativ könntest du an deinem Router auch eine Rule für deinen FQDN einrichten, dass dieser den Traffic auf die Pascom schiebt.

Gruss

Flo

3

Meintest Du wirklich 47.6 oder war das ein Versehen und Du wolltest 46.6 schreiben?

Wenn 192.168.46.6, dann wären ja beide im selben Netz und ich kann noch nicht erkennen, wozu. Würde ich den internen DNS dann mit dem FQDN auf das zweite Interface verweisen lassen und auf ein offizielles Zertifikat verzichten? Ich will ja auch erreichen, dass Smartphone-Nutzer im lokalen LAN auch lokal bleiben mit dem erzeugten Traffic.

Wenn es eine abweichendes Netz wäre, müsste ich irgendwo routen, da dann ja das zweite Interface vom internen Netz des Kunden abweicht.

——-
Ich habe auch schon folgenden Konstellation versucht, ebenfalls ohne Audio:

nur ein Interface im selben Subnetz vom Kunden wie auch alle Clients, allerdings mit einem abweichenden Gateway (192.168.46.254) da für den externen Voip-Traffic ein gesonderter Router bereitsteht. Mein Gedanke: Die komplette Netzwerkinfrakstruktur des Kunden mit Ausnahme der Pascom nutzt für Surfen, Mailen und was sonst noch alles den dafür vorgesehen Internetanschluss über das Gateway 192.168.46.1. Und da die Telefone ja im selben Subnetz sind, wird ja auch kein Gateway benötigt.

Scheint so, als ob der Kamailio das dann aber auch nicht mag und ich verstehe wieder nicht wieso, wo sich doch alles im selben Subnetz abspielt und das Gateway in dem Moment doch außen vor ist.

Wieso ist das so? Scheint ja so, als ob die Pascom da intern noch irgendwas anderes macht mit dem Traffic.

Gruß
Michael

4

Ich vermute, dass durch das Split-DNS eine “falsche” IP in den SIP/RTP-Paketen steht und du deswegen nichts hörst. Probier es doch mal ohne Split-DNS und richte für die interne Telefonie Hairpin-NAT ein.

Gruß
Stefan

5

Hi,

wie schon richtig vermutet ist das Problem das folgende:
Beim Start des Interface Containers löst der pascom Host den FQDN auf und parametriert damit den Kamailio (SBC). Das kann man sich ein wenig wie SIP ALG vorstellen, der Kamailio offeriert hier als RTP Ziel die externe IP. Deswegen ist Split-DNS auch problematisch, alle Endgeräte und der pascom Host müssen die FQDN auf die gleiche IP auflösen.
Lösen kann man das auf zweierlei Wege:
A “Ein Interface Lösungsweg”:
Auch die internen Geräte müssen via FQDN mit der externen IP reden. Spätestens wenn die pascom im gleichen Netz wie die Clients ist, muss man sich um ein “hairpinning” (zusätzliches Source NAT) kümmen, damit die Antworten wieder über den Router laufen und korrekt “rückübersetzt” werden. Eine Fritzbox macht das automatisch, ein “Business-Router” macht das nicht von alleine.
B “zwei Interfaces”:
Dadurch das die Interfacecontainer sich das Netzwerkinterface zu “zu sich in den Container ziehen” ist es vollkommen legitim das 2. Interface im gleichen Netz anzusiedeln (mit gleichem oder zumindest einem anderen Defaultgateway). Dann kann eines für die Internen Geräte genutzt werden (als FQDN gerne LAN IP des Interfaces setzen) und das andere zur Andbindung externer/mobile Geräte. Das Portforwarding muss dann natürlich zum “extern genutzten” Interface zeigen. Wichtig ist hier zu bedenken das die SIP Registrierungen zum Provider immer über das erste/primäre Interface erfolgen. Es bietet sich also an das erste für die externen Zugriffe zu konfigurieren und das zweite für die Internen Geräte zu verwenden (muss mann aber nicht).
Anmerkung da es aktuell mit dem Start des DHCP Servers an sekundären Interfaces ein “race condition” Problem gibt, macht es ggf auch mehr Sinn das primäre für die internen und das sekundäre für die externen Geräte zu verwenden. Aktuell muss man häufig den dnsmasq im sekundären Interfacecontainer nochmal “nachstarten”, da der initial Start mangels Interface scheitert.

Grüße,
Steve

6

Euch allen vielen Dank für die Hinweise.

Ich werden das im Januar noch einmal angehen, dann mit einem anderen Router, damit ich Hairpin-NAT nutzen kann, denn - kaum zu glaube - ein LANCOM kann kein Hairpin-NAT. Ich konnte es nicht glauben und habe gezielt beim LANCOM-Support angefragt.

Schöne Feiertage
Michael

7

Hi Michael,

musste gleich an unser letztes Gespräch denken zum Thema Lancom und Einstellungen beschnitten. :wink:

https://forum.pascom.net/t/router-telekom-anschluss/4728/8

Gruss

Flo

8

Ich weiß, was Du meinst. Wobei die Einstellungen ja in dem Fall nicht beschnitten sind sondern überhaupt nicht vorgesehen. Selbst über die Konsole nicht.

Hatte gestern dazu noch ein längeres Gespräch mit meinem Lancom-Vertriebsbeauftragten… mit frustrierendem Ergebnis.

9

Komisch, denn Haipin-NAT ist ja keine exotische Funktion.

Hast du schon einen Plan für dein weiteres Vorgehen?

10

Tja, das dachte ich auch und es gab in der Vergangenheit für mich auch nichts, was sich mit dem LANCOM nicht hätte lösen lassen - auch wenn die Konfig manchmal ein wenig exotisch anmutet.

Eine zu Ende gedachte Idee habe ich noch nicht wirklich, zumal ich mir zweimal so richtig heftig die Finger verbrannt habe und das auch nicht mal eben schnell nachbauen kann und auch keine Lust auf weitere Experimente habe.

Es wird wohl auf einen Mikrotik-Router hinauslaufen, zum einen, weil ich den selbst nutze und halbwegs kenne, also weiß, dass Mikrotik das kann und zu anderen, weil der Pascom Support die Geräte auch ziemlich gut kennt und im Zweifel mal einen Tipp geben kann.

Am liebsten wäre mir natürlich, ich könnte das zuvor einmal komplett durchtesten. Dazu müsste ich mir dann aber die Umgebung des Kunden nachbauen und das scheitert schon daran, dass ich nur einen Internet-Zugang habe, also alles ziemlich theoretisch bleibt.

Aber jetzt ist erstmal Weihnachten und im neuen Jahr werde ich einen neuen Anlauf starten, dann hoffentlich mit weiteren Erkenntnissen.

Gruß
Michael

11

Hallo zusammen,
da ich aktuell beim Aufbau der Pascom 18 bin, hänge ich mich mal an diesen Thread an.

Das System ist grundsätzlich mit ESXi virtualisiert und hat in der VM mehrere Netzwerkinterfaces.

Was will ich erreichen:

  • Interface 1: 192.168.100.X als Management-Interface, erreichbar aus dem internen “PC-Netzwerk”
  • Interface 2: 192.168.99.X als Telefon-Interface, erreichbar nur für die Telefone, hier werden diese provisioniert und erhalten per DHCP eine IP (von der Pascom) zugewiesen
  • Interface 3: 192.168.98.X als Interface für die SIP-Anmeldung (Sipgate Trunking) - Internetleitung explizit nur für Telefonie, physisch nur von der Pascom erreichbar

Mit der Pascom 17 stellt das überhaupt kein Problem dar und aufgrund der hier aufkommenden Aussagen, dass das “erste” Interface für die SIP-Anmeldung genutzt wird. Ist dies dann das Management-Interface? Das würde dann ja mal so garnicht meinen Wünschen entsprechen. Kann ich in dem Fall ein anderes Interface zum Management-Interface auswählen?

Via SSH sehe ich - sobald ich die Netzwerkinterfaces konfiguriere diese auch nicht mehr per ifconfig oder ip addr show, das Management-Interface hingegen schon.

–

Auch wenn das vom reinen Netzwerkthema nun abweicht: Wir haben intern einen Exchange 2016 stehen, dieser soll dann auch entsprechend die Mails versenden, logisch. Aus dem internen Netz nimmt dieser von ganz bestimmten IPs auch Mails ohne Authentifizierung an - so zum Beispiel von der Pascom.
Wenn ich den Mailversand “beim Speichern testen” will, erscheint der dadurch angestoßene Job als fehlgeschlagen mit der Rückmeldung Failed to set mailserver changes. Reason: Command '[‘lxc-attach’, ‘-n’, ‘controller’, ‘–’, ‘python’, '/opt/csmanager/up
Per telnet -mailserverIP- 25 kann ich eine E-Mail aber wie erwartet absenden. Ich habe es schon mit StartTLS, TLS und Einfach als “Sicherheitslevel” versucht - ohne Erfolg. Die Pascom 17 sendet bis heute ohne jegliche Probleme die Mails raus - was ist da los?

Ich hoffe einer von euch kann mir an der Stelle weiterhelfen :confused:

Viele Grüße und Danke im Voraus
Adrian

2 Likes