1781VAW VoiP ??!

[sleeplessnight]

Hi,

hab seid ein paar Tagen den Router. Nun (wonach ich vergessen hab zu schauen) hat das Teil kein eingebautes VoiP, lediglich nur ein Gateway, richtig?

Mit SIP-ALG kann ich net viel anfangen.
Daher meine Frage: Ist's möglich, über WLAN eine VoiP-Verbindung irgendwie zustande zu bekommen?
Bisher wurde die alte Fritze über eine App @smartphone für sowas genutzt. Das fällt jetzt flach, womit ich auch kein Problem hab.
Was ich allerdings nicht am Nagel hängen möchte, ist das VoiP. Gibt's da net richtig "Haustelefone", die sich per WLAN ins Netz einklinken und anschließend das beides machen, was damals die Fritzbox und die Handyapp gemacht hat?

Ich muss ehrlich gestehen, das ich von VoiP net viel Ahnung hab. Weiß nur, das es Internettelefonie ist und keine Ahnung, was die Fritzbox dazu angestellt hat, damit das funzt.

Danke euch

[Christoph_vW]

Ich habe meine FritzBox einfach hinter den 1781VAW gehängt und Portweiterleitungen für VoIP an die FB eingerichtet. (Der SIP-ALG hat bei mir nicht richtig funktioniert).

[sleeplessnight]

Kannst du des etwas genauerer beschreiben? Portweiterleitung, von, zu?
Weil ich kann schlecht die Fritze mit einem WLAN ins leben rufen. Mehr oder weniger flog sie deswegen raus... und ja, wenn ich teln will, kann ich ja schlecht immer das WLAN wechseln, zumal ich auch nicht erreichbar wäre, wenn ich im Lancom netz hänge...

[pat4fly]

Bei mir funzt der SIP-ALG wunderbar. Geht eigentlich ganz einfach:

- in die Telefone/Tel.anlage oder sonstige Endgeräte werden die Zugangsdaten des Providers eingetragen, also Server, Proxy, Benutzername, Passwort. Wichtig: der STUN-Server wird NICHT eingetragen, bleibt leer!

- im Lancom werden KEINE Portweiterleitungen oder Firewall-Regeln konfiguriert (wenn vorhanden, bitte löschen!), stattdessen einfach SIP-ALG eingeschaltet.

- waren Portweiterleitungen o.ä. konfiguriert, nach dem Wieder-Raus-Konfigurieren Telefonanlage/Endgeräte und Router neu starten.

[sleeplessnight]

- im Lancom werden KEINE Portweiterleitungen oder Firewall-Regeln konfiguriert (wenn vorhanden, bitte löschen!), stattdessen einfach SIP-ALG eingeschaltet.

- waren Portweiterleitungen o.ä. konfiguriert, nach dem Wieder-Raus-Konfigurieren Telefonanlage/Endgeräte und Router neu starten.

Wie generell keine FW Regeln? Wozu hat man dann solch ein teuren Router gekauft?
Das kann schlecht die Lösung sein...
Oder hast du das nur auf das Interface bezogen, auf dem die TK anlage sitzt?

[fildercom]

- im Lancom werden KEINE Portweiterleitungen oder Firewall-Regeln konfiguriert (wenn vorhanden, bitte löschen!), stattdessen einfach SIP-ALG eingeschaltet.

- waren Portweiterleitungen o.ä. konfiguriert, nach dem Wieder-Raus-Konfigurieren Telefonanlage/Endgeräte und Router neu starten.

Wie generell keine FW Regeln? Wozu hat man dann solch ein teuren Router gekauft?
Das kann schlecht die Lösung sein...
Oder hast du das nur auf das Interface bezogen, auf dem die TK anlage sitzt?

Das bezog sich mit Sicherheit nur auf die Ports, die für VoIP genutzt werden. Aber vielleicht kann da nochmal ein VoIPer was dazu sagen, weil ich selbst keine Erfahrungen mit VoIP habe, nutze weiterhin "echtes" ISDN.

[backslash]

Hi sleeplessnight

Wie generell keine FW Regeln? Wozu hat man dann solch ein teuren Router gekauft?
Das kann schlecht die Lösung sein...
Oder hast du das nur auf das Interface bezogen, auf dem die TK anlage sitzt?

es geht darum, daß keine speziellen Regeln für die RTP-Ströme angelegt werden müssen/dürfen...
Wenn du eine Deny-All-Startegie fährst, dann reicht eine einzige Allow-Regel, die den Signalisierungs-Traffic zwischen TK-Anlage und Provider zuläßt:

Code: Alles auswählen

Aktion:  übertragen (ggf. noch QOS: Mindestbandbreite 1kBit/s)
Quelle:  IP der TK-Anlage/des Telefons
Ziel:    alle Stationen
Dienste: UDP, Zielport 5060 

Gruß
Backslash

[pat4fly]

Sorry, das war natürlich ungenau formuliert. Ich habe eigentlich eine deny-all Firewall - bin ja nicht lebensmüde

Ich meinte, daß für VoIP keine Ports weitergeleitet oder geöffnet werden müssen, das erledigt SIP-ALG.

[cpuprofi]

Hallo an Alle,

...Geht eigentlich ganz einfach: - in die Telefone/Tel.anlage...werden die Zugangsdaten des Providers eingetragen...stattdessen einfach SIP-ALG eingeschaltet...Telefonanlage/Endgeräte und Router neu starten.

dieses kann man auch unter http://www.lancom-forum.de/aktuelle-lan ... 13040.html nachlesen, dort hatte ich es damals pat4fly schon erklärt.


Hallo Backslash,

...Wenn du eine Deny-All-Startegie fährst, dann reicht eine einzige Allow-Regel, die den Signalisierungs-Traffic zwischen TK-Anlage und Provider zuläßt...

die Öffnung der Firewall für die Signalisierung (REGISTER) beim SIP-Provider sollte der SIP-ALG "normalerweise" selber machen und somit sollte man auch keine "extra" FW-Regel benötigen... ansonsten ist das ein Fehler...

Grüße
Cpuprofi

[backslash]

Hi cpuprofi

die Öffnung der Firewall für die Signalisierung (REGISTER) beim SIP-Provider sollte der SIP-ALG "normalerweise" selber machen und somit sollte man auch keine "extra" FW-Regel benötigen... ansonsten ist das ein Fehler...

nein. Das SIP-ALG verfolgt nur die SIP-Verhandlung und öffnte die RTP-Ports mit den passenden Mindestbandbreiten. Damit das SIP-ALG das aber kann, darf der zu verfolgedne Traffic nicht durch die Firewall geblockt werden. Daher ist die Regel für die Signalisierung schon notwendig.

Außerdem willst du ja ggf. auch sicherstellen, daß nicht jeder Beliebige da so einfach SIP macht - dann brauchst du eine Allow-Regel, die den SIP-Traffic nur von bestimmten Quell-Adressen zuläßt.

Oder andersherum: SIP soll nur mit deinem Provider gemacht werden - dann brauchst du eine Allow-Regel, die den SIP-Traffic nur zu bestimmten Ziel-Adressen zuläßt

Oder halt eine Kombination von beidem...

Gruß
Backslash

[cpuprofi]

Hallo Backslash,

die Öffnung der Firewall für die Signalisierung (REGISTER) beim SIP-Provider sollte der SIP-ALG "normalerweise" selber machen und somit sollte man auch keine "extra" FW-Regel benötigen... ansonsten ist das ein Fehler...

nein. Das SIP-ALG verfolgt nur die SIP-Verhandlung und öffnte die RTP-Ports mit den passenden Mindestbandbreiten. Damit das SIP-ALG das aber kann, darf der zu verfolgedne Traffic nicht durch die Firewall geblockt werden. Daher ist die Regel für die Signalisierung schon notwendig.

da muß ich Dir widersprechen, der SIP-ALG erkennt "selbständig" Anfragen vom LOCALNET auf Port 5060 (ob auch auf andere Ports, habe ich noch nicht getestet) und öffnet dann "selbständig" die Firewall, was ja auch durchaus für eine einfachere Implementierung von VoIP/SIP Sinn macht.


Siehe auch diesen Trace:

[Firewall] 2014/01/15 17:54:37,326 Devicetime: 2014/01/15 17:54:33,573
Packet matched rule DENY-ALL
DstIP: 83.125.8.71, SrcIP: 192.168.150.2, Len: 554, DSCP/TOS: 0x20
Prot.: UDP (17), DstPort: 5060, SrcPort: 22574

[SIP-ALG] 2014/01/15 17:54:37,326 Devicetime: 2014/01/15 17:54:33,573 [AlTask] :
cAlTask::processUdpRx Src:192.168.150.2:22574, Dst:83.125.8.71:5060

[SIP-ALG] 2014/01/15 17:54:37,326 Devicetime: 2014/01/15 17:54:33,573 [AlTask] :
cAlTask::processUdpRx 2 PayloadSize:526

[SIP-ALG] 2014/01/15 17:54:37,326 Devicetime: 2014/01/15 17:54:33,573 [Sip-UA] : DISPATCH_UDP SrcAddr: 192.168.150.2:22574, DstAddr: 83.125.8.71:5060, ComChan: 80000000, TxChan: 1, RtgTag: 0

[SIP-Packet] 2014/01/15 17:54:37,326 Devicetime: 2014/01/15 17:54:33,573 [PACKET] :
Receiving datagram with length 526 from 192.168.150.2:22574 to 83.125.8.71:5060
REGISTER sip:proxy.dus.net SIP/2.0\r\n
Via: SIP/2.0/UDP 192.168.150.2:22574;branch=...\r\n
From: <sip:000387xxxxxx@proxy.dus.net>;tag=-...\r\n
To: <sip:000387xxxxxx@proxy.dus.net>\r\n
Call-ID: 000387xxxxxx-proxy.dus.net-...\r\n
CSeq: 22673 REGISTER\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS\r\n
Max-Forwards: 70\r\n
Contact: <sip:000387xxxxxx@192.168.150.2:22574>\r\n
Expires: 60\r\n
User-Agent: LANCOM 1722 VoIP (Annex B) / 8.84.0111 / 06.01.2014\r\n
Content-Length: 0\r\n
\r\n

[SIP-ALG] 2014/01/15 17:54:37,326 Devicetime: 2014/01/15 17:54:33,573 [SIP] : DecodeDatagram 1 MessageBufferLength:526

[SIP-ALG] 2014/01/15 17:54:37,326 Devicetime: 2014/01/15 17:54:33,573 [SIP] : Request: REGISTER

[SIP-ALG] 2014/01/15 17:54:37,326 Devicetime: 2014/01/15 17:54:33,573 [SIP] : DecodeDatagram 2 MessageBufferLength:0

[SIP-ALG] 2014/01/15 17:54:37,326 Devicetime: 2014/01/15 17:54:33,573 [Sip-Reg] : SIP_REG_PROCESS_MSG

[SIP-ALG] 2014/01/15 17:54:37,326 Devicetime: 2014/01/15 17:54:33,573 [SIP-CALL] : CreateCall Call-Id: 000387xxxxxx-proxy.dus.net-...

[SIP-ALG] 2014/01/15 17:54:37,326 Devicetime: 2014/01/15 17:54:33,573 [Sip-Reg] : REG_UPDATE_BINDINGS

Außerdem willst du ja ggf. auch sicherstellen, daß nicht jeder Beliebige da so einfach SIP macht - dann brauchst du eine Allow-Regel, die den SIP-Traffic nur von bestimmten Quell-Adressen zuläßt.

Oder andersherum: SIP soll nur mit deinem Provider gemacht werden - dann brauchst du eine Allow-Regel, die den SIP-Traffic nur zu bestimmten Ziel-Adressen zuläßt

Oder halt eine Kombination von beidem...

Dann müsste man den SIP-ALG um einen "Schalter" im SIP-ALG-Menü erweitern, mit dem man die "selbständige" Erkennung von Anfragen auf Port 5060 (bzw. evtl. auch auf anderen Ports) deaktivieren kann. Das wäre ja sogar noch besser, da dann jedem selbst überlassen wird, was man bevorzugt: "selbständige Erkennung von SIP Anfragen" durch den SIP-ALG oder "manuelle Konfiguration".

Die anderen "Aufgaben" vom SIP-ALG (RTP, RTCP, Bandbreitenmanagement, usw.) sollten dann aber nicht von diesem Schalter beeinflusst werden...


Sollte ich was falsch verstanden haben, so kläre mich auf.


Grüße
Cpuprofi

[backslash]

Hi cpuprofi

das halte ich aber für einen ziemlich großen Bug... Denn die Regel heißt ja "DENY-ALL" und nicht "DENY_ASLL except SIP"...

Ich trag's mal in die Bugtracking-Datenbank ein

Gruß
Backslash

[cpuprofi]

Hallo Backslash,

...das halte ich aber für einen ziemlich großen Bug... Denn die Regel heißt ja "DENY-ALL" und nicht "DENY_ASLL except SIP"...

ich widerspreche Dir zwar ungern, aber ein SIP-ALG soll ja die Durchquerung der Firewall für SIP ermöglichen, siehe:

http://en.wikipedia.org/wiki/Application-level_gateway

Ich zietiere mal:

"...For instance, for Session Initiation Protocol (SIP) Back-to-Back User agent (B2BUA), an ALG can allow firewall traversal with SIP. If the firewall has its SIP traffic terminated on an ALG then the responsibility for permitting SIP sessions passes to the ALG instead of the firewall. An ALG can solve another major SIP headache: NAT traversal. Basically a NAT with a builtin ALG can rewrite information within the SIP messages and can hold address bindings until the session terminates..."

Übersetzt:

Zum Beispiel für das Session Initiation Protocol (SIP) Back-to-Back User-Agent (B2BUA), ein ALG kann die Durchquerung der Firewall mit SIP ermöglichen. Wenn die Firewall den SIP-Verkehr unterbindet, dann geht die Verantwortung "SIP-Sitzungen zu ermöglichen" auf den ALG anstelle der Firewall über. NAT-Traversal: Ein ALG kann einen weiteren großen SIP Kopfschmerz lösen. Grundlegend kann ein NAT, mit einem eingebaute ALG, Informationen innerhalb der SIP-Nachrichten umzuschreiben und kann Adressbindungen halten, bis die Sitzung beendet ist.


Somit ist "dieses Feature" = "DENY_ALL except SIP" kein Bug, sondern entspricht der Definition des SIP-ALG's !


Außerdem finde ich "dieses Feature" sehr sinnvoll, da ich auch einen Kunden (mit mehreren Standorten) habe, wo die freien Mitarbeiter per VoIP auf dem Handy (welches über WLAN dann auf jeweils einen Lancom-Router mündet) Ihre Telefonie (Privat: diverse Sip-Provider ; Firma: Cloud-SIP-Provider) abwickeln und ich nicht jedes mal "Lust" habe bei Änderungen bei den Mitarbeiter die Firewall neu zu programmieren !!! Denn der Handy-Empfang ist an den Standorten nur sehr eingeschränkt möglich, daher die Umsetzung über WLan.


Also bitte Backslash, wenn Du schon den SIP-ALG erweitern (ändern) willst, bitte als zusätzlichen "Schalter" im SIP-ALG Menü mit "Firewall-Regeln automatisch durch SIP-ALG anpassen" -> Ja / Nein (Default=Nein)


Zum Thema " ziemlich großen Bug": Wenn dann ist es ein Bug, weil dieser Schalter im SIP-ALG fehlt...


Grüße
Cpuprofi

[backslash]

Hi cpuprofi,

es gibt ab der nächsten Firmware (8.84) im SIP-ALG einen Schalter (Firewall-Overrule) mit dem das Verhalten gesteuert werden kann. Aus Gründen der Abwärtskompatibilität (d.h. damit bestehende Konfigurationen weiterlaufen und es keinen Sturm im Support gibt) steht der Schalter im Default auf "Yes", so daß sich das bisherige Verhalten ergibt.

Sobald man den Schalter auf "No" stellt, werden vom SIP-ALG nur noch Paketer bearbeitet, di in der Firewall auf dein Accept-Regel gematcht haben. Aus Sicherheitsgründen sollte man den Schgalter in jedem Fall umlegen und eine passende Firewallregel erstellen, z.B.

Code: Alles auswählen

Name:    Allow-SIP
Aktion:  übertragen.
Quelle:  alle Stationen im lokalen Netz
Ziel:    alle Stationen
Dienste: UDP, Zielport 5060

Gruß
Backslash

[cpuprofi]

Hallo Backslash,

danke dass Ihr meine Idee vom "Schalter" im SIP-ALG für eine Firewall-Overrule aufgenommen habt, denn dieses ist (je nach gewünschtem Firewall-Szenario) schon sehr sinnvoll.

...Aus Sicherheitsgründen sollte man den Schalter in jedem Fall umlegen und eine passende Firewallregel erstellen, z.B.

Code: Alles auswählen

Name:    Allow-SIP
Aktion:  übertragen.
Quelle:  alle Stationen im lokalen Netz
Ziel:    alle Stationen
Dienste: UDP, Zielport 5060

Deine Sicherheitsbedenken in diesem Punkt teile ich so nicht, denn die "Automatik" im SIP-ALG öffnet nur jeweils eine IP (intern zu extern) mit jeweils nur dem angesprochenen Port für die Zeit der jeweiligen Session, somit bin ich der Meinung, dass die Firewall "weniger" offen ist, als mit Deiner Regel...

Oder aber beziehst Du Dich dabei auf Folgendes: Man möchte nur einzelne Geräte (IP's) für SIP zulassen und alle anderen sollen gesperrt werden, dann sollte man den Schalter auf "No" stellen und eine passende Firewall-Regel manuell erstellen. Denn die "Automatik" im SIP-ALG würde sonst für alle Geräte die Firewall bei Anfragen auf Port 5060 öffnen und das ist ja in diesem Fall nicht gewünscht. Und hierbei stimme ich auch vollkommen mit Deiner Meinung überein.

Grüße
Cpuprofi