[Pascom 18] Interne IP der Telefonanlage in 'Contact' Information SIP Paket

german
bug

#1

Hallo,

Ich habe folgende Problematik entdeckt, die aus meiner Sicht nicht korrekt ist.
Die SIP Pakete die durch den Session Border Controller verschickt werden, haben im Contact die interne IP Adresse der Telefonanlage wie . z.B. 10.0.3.117 und nicht die Adresse der Schnittstelle zum Netzwerk wie z.B. 192.168.0.12.

Soll dass so sein?! Aus meiner Sicht nicht korrekt. Ich habe auch dass Gefühl das dass der Grund ist wieso mein Firewall Probleme mit eingehenderen SIP Paketen macht. Weil er sich denkt eine Netzwerk mit 10.0.3.117 habe ich nicht und somit leite ich das Paket nicht weiter.

Gruß

Reinhard


#2

Hallo Reinhard,

wenn die Firewall den SIP-Header ließt dann ist an der Firewall ein SIP-Helper oder SIP-ALG an würde ich sagen.

was genau geht denn nicht richtig?

Gruß Markus


#3

Hallo @MarkusSachs,

Firewall ist ein Fortigate, mit SIP-ALG aktiv / SIP-Helper deaktiviert.
Das aktuelle Problem ist das eigehende SIP Pakete (nur BYE und INVITE) nicht weitergegeben werden.
Der Rest (Rufaufbau, Anruf) funktioniert tadellos. Ein entsprechender SupportCase ist auch bei Fortinet schon offen.

Gruß Reinhard


#4

Hallo Reinhard,

kannst Du den SIP-ALG mal deaktieren und probieren ob es dann geht?
Meistens machen die alles schlechter.

Gruß Markus


#5

Hallo @MarkusSachs,

Das Thema ist ich brauche den SIP-ALG um den SIP Contact auf die öffentliche IP umzuschreiben, da der SIP Provider nur den SIP Contact in folgender Form akzeptiert. “Rufnummer:PublicIP@5060”. Mit einem reinen Routing funktioniert das nicht. Oder ich kriege den SIP Contact gleich korrekt aus der Pascom mit der öffentlichen IP. Dann würde es auch ohne SIP-ALG gehen. Was ja eben leider nicht der Fall ist.

Gruß Reinhard


#6

Ah verstanden,

Okay und das Interface in der Pascom ist mit FQDN eingerichtet?
Oder ist das mit IP-Adresse eingerichtet?


#7

Hallo Markus,

das Pascom Interface ist mit FQDN und Lets encrypt eingerichtet bzw. die Namensauflösung funktioniert auch korrekt.

Gruß Reinhard


#8

Hm,

komisch dann sollte eigentlich der Kamailio (das Interface) die korrekte externe IP auflösen und diese in den Contact Header packen, dachte ich.

Hast Du denn Support bei Pascom?
Dann solltest Du da mal ein Ticket aufmachen oder anrufen.

Gruß Markus


#9

Hallo Markus,

haben nur die BASIC Lizenz, deshalb meine Frage hier im Forum.

Gruß Reinhard


#10

Hallo Reinhard,

welcher SIP-Anbieter ist das denn den du da hast?


#11

Hallo Markus,

der Anbieter ist UPC Österreich.

Gruß Reinhard


#12

Hallo Reinhard,

also gut und was hast du für eine Vorlage an der Anlage ausgewählt?
bzw kannst Du mal die Einstellungen im Tab Accounts posten?


#13

Hallo Markus,

anbei die Einstellungen.
Die “Durchwahl reg.” entspricht der Rufnummer des Anschlusses.
Die Optionen entsprechen der Community Vorlage mit einem Unterschied das ich zusätzlich den registertimeout ergänzt habe entsprechend den Vorgaben von UPC.


Pascom 18 & NFON Sip Trunk Vorlage
#15

Also versuche mal folgendes

Unter Appliance -> Systemeinstellungen eine neu Systemeinstellung hinzufügen.

sys.asterisk.configure.sip.file.externip und als Wert die externe IP von dir.

dann die Telefonie anwenden und mal nen Trace machen ob dann die richtige IP im Contact Header steht


#16

Leider nein. Steht immer noch die 10.x.x.x Adresse drin.
Habe zusätzlich auch noch den Telefonserver neu gestartet bzw. den gesamten Server. Keine Veränderung im Verhalten.


#17

Hallo @rinal13,

manche Provider munieren in der Tat die private IP an der Stelle, auch wenn wir die Information mit senden das die hier verwendete IP nicht gültig ist, sondern die des IP Headers (was bei den meisten Providern ja klappt).

Neben der von Markus erwähnten externip benötigst du noch ein weiteres Setting sys.asterisk.configure.sip.file.localnet mit Wert 10.0.3.0/255.255.255.0 damit der Asterisk weiß wann er die externip zu setzen hat (nämlich wenn mit Hosts/Peers außerhalb des localnet kommuniziert wird.

Was hier vielleicht etwas missverständlich ist/war, ist das die Kommunikation zum SIP Provider aktuell noch nicht über den SessionBorderController bzw InterfaceContainer abläuft sondern vom Asterisk im Telfonie Container direkt über über den pascom Host (mit SourceNAT/Masquerading) aufgebaut wird.
Bei externip ist deswegen auch die IP des pascom Hosts selbst (am primären/ersten Interface) gemeint, nicht die öffentliche WAN IP am Router (also z.B. 192.168.0.12).

Grüße,
Steve


#18

Hallo @Steve,

mit den Einstellungen bekommen ich nun die interne IP Adresse im contact Feld korrekt.
Da aber mein Provider zwingend die öffentliche IP sehen will “muss” ich trotzdem den ALG des Firewall nutzen,
der jedoch bei der Kommunikation wie beschrieben Probleme macht.
Gibt es irgendeine Möglichkeit das die Pascom 18 trotzdem die öffentliche IP mitgibt. Dies sollte ja über dem SessionBorderController möglich sein.
Somit wäre es auch möglich den Firewall ohne ALG zu betreiben


#19

Hi,

das sollte eigentlich das ALG des Routers dann übernehmen. Du kannst aber als externip auch die WAN IP eintragen. Wie erwähnt wird der SBC für die Ämter aktuell noch nicht verwendet.

Grüße,
Steve


#20

Hallo Zusammen.

Ich möchte hier kurz einige Dinge klar stellen:

  • die Interface Einstellungen gelten ausschließlich für Endpunkte, nicht für Trunks
  • ein Trunk wird generell aus der Instanz heraus über das Management-Interface ge-NATed. Das Verhalten ist dann sehr ählinch wie in deiner pascom Classic.
  • Trunk Traffic wird mit “loose Routing” gerouted. Die IP Adressen in den Paketen spielen keine Rolle solange der Provider den “;lr” Parameter unterstützt und der Router ein sauberes Connection-Tracking macht.

Zu dem ALG Problem:

  • wenn das Interface auf TLS gesetzt ist, kommunizieren alle Endpunkte per SSL und Deine Firewall kann kein ALG machen (das ist gut!)
  • Dein Trunk Traffic ist nicht TLS sondern sicher TCP oder gar UDP und somit “darf” der Router ALG darauf anwenden.
  • Nun kann es sein das das Router-ALG-Modul kein “;lr” kennt und den IP Adressen im SIP Paket vertraut. Somit versanden dann Replies.

Wir werden in der kommenden 18.03 release auch ein ALG Modul für das Management Interface mitbringen. Die SIP Pakete werden dann die IP Nummern des Management Interfaces zeigen, was ggf. in Deinem Fall das Verhalten verbessert. Du hättest dann 2x ALG: Instance-zu-Host und Host-zu-Router.

Du kannst Dich beim Support melden und ggf. vorher schon testen.

Gruß,

Thomas


#22

Hallo @Steve,

die SIP Kommunikation funktioniert erst nachdem ich noch den Parameter “autodomain = yes” gesetzt habe. Dadurch wird die extenip auch in die Liste der domains automatisch aufgenommen und somit werden auch SIP Pakete akzeptiert die von der öffentlichen IP Adresse kommen.

Trotzdem werden aber die RTP Pakete welche von der öffentlichen IP Adresse kommen nicht akzeptiert. Eine Idee was hier eventuell noch freizuschalten ist. Eventuell besteht hier eine Blockade vom Management Interface zur Asterisk Instanz?

Gruß Reinhard