IPv6 Firewall: ALLOW-SIP Regel funktioniert nicht

[booker]

Hallo zusammen,

ich habe gerade die neue LCOS10.00RU1 getestet. Nachdem nun die IPv6-Unterstützung für den VCM enthalten ist, verbinden sich SIP-Leitungen zu Anbietern mit IPv6 nun über IPv6.

Das neue LCOS liefert passend dazu auch eine ALLOW-SIP Regel für die IPv6-Firewall mit. Aktiviere ich diese Regel um SIP-Traffic für den VCM zuzulassen funktioniert das leider nur sporadisch. Trotz aktivierter ALLOW-SIP Regel werden die eingehenden Pakete von der DENY-ALL Regel geblockt. Verstehe oder mache ich hier was falsch?



Gruß
booker

[booker]

Guten Abend zusammen,

es hat eine Weile gedauert bis ich es geschnallt habe Die ALLOW-SIP Regel erschlägt ankommende SIP-Verbindungen auf Port 5060, nicht aber Verbindungen die von Port 5060 (also hier dem SIP-Provider) ausgehen. Insofern ist wohl korrekt dass die Firewall die eingehenden Pakete verwirft.

Kann mir jemand für mein Verständnis trotzdem erklären, warum die Firewall für die Lancom-eigenen abgehenden Verbindungen nicht automatisch die zugehörigen eingehenden Pakete akzeptiert? Danke!

Gruß
booker

[backslash]

Hi Booker,

Kann mir jemand für mein Verständnis trotzdem erklären, warum die Firewall für die Lancom-eigenen abgehenden Verbindungen nicht automatisch die zugehörigen eingehenden Pakete akzeptiert? Danke!

das tut sie schon - aber halt nur solange bis der UDP-Timeout abläuft. Hier mußt du die SIP-Leitungsüberwachung (Voice Call Manager -> Leitungen -> SIP-Leitungen -> Leitung-> Erweitert -> Leitungsüberwachung -> Überwachungsinterval) und den UDP-Timeout (IP-Router -> Maskierung -> UDP-Aging) synchronisieren... Ich weiss, das ist unschön, da aber nunmal UDP stateless ist, hat die Firewall keine Möglichkeit nachzuhalten, ob ihr Sessioneintrag noch gültig ist. Es bleibt also nur der harte Timeout

Alternativ kannst du SIP über TCP machen (Voice Call Manager -> Leitungen -> SIP-Leitungen -> Leitung-> Allgemein -> Sicherheit -> Signalisierungsverschlüsselung -> keine (TCP)), wenn dein Provider das unterstützt (u.U. nur mit Verschlüsselung) - da hält die Firewall ihre Session solange offen, wie die TCP-Session existiert

Gruß
Backslash

[cpuprofi]

Hallo Backslash,

...Hier mußt du die SIP-Leitungsüberwachung (Voice Call Manager -> Leitungen -> SIP-Leitungen -> Leitung-> Erweitert -> Leitungsüberwachung -> Überwachungsinterval) und den UDP-Timeout (IP-Router -> Maskierung -> UDP-Aging) synchronisieren...

werden die Einstellungen des "Überwachungsintervall" den jetzt übernommen? Soweit wie ich das weiß hatte der VCM damit Probleme...?

Code: Alles auswählen

Das Überwachungsintervall muss mindestens 60 Sekunden betragen und legt fest, nach welcher Zeit die Überwachungsmethode erneut angewendet wird. Wenn die (Re-)Registrierung aktiviert ist, wird das Überwachungsintervall auch als Zeitraum bis zur nächsten Registrierung verwendet.

Denn die Zeiteinstellung für die "(Re-)Registrierung" ging als ich mich damit beschäftigt hatte nicht Egal was man da einstellte, es wurde immer nach 60 Sekunden (re-)registriert.

Grüße
Cpuprofi

[backslash]

Hi cpuprofi,

ob das funktionert, kann ich dir nicht sagen - der VCM ist nicht meine Baustelle. Ich schau nur, was LANconfig anbietet... Wenn es mit Reregistrierungen nicht tut, dann solltest du als Überwachungsmethode "Option" auswählen:

“Options:” Überwachung mittels Options-Requests. Dabei wird wie bei einem Polling regelmäßig eine Anfrage an die Gegenstelle verschickt, je nach Antwort wird die Leitung als verfügbar oder nicht verfügbar angesehen. Diese Einstellung eignet sich z.B. für registrierungslose Leitungen.

Denn die Zeiteinstellung für die "(Re-)Registrierung" ging als ich mich damit beschäftigt hatte nicht Egal was man da einstellte, es wurde immer nach 60 Sekunden (re-)registriert.

nun ja, den UDP-Timeout solltest du möglichst auch nicht viel größer wählen, da dir sonst der Speicher zu schnell vollaufen kann - insbesondere die IPv4-Maskierungstabelle ist davon betroffen

Gruß
Backslash

[booker]

Hallo backslash,

danke für deine Erklärung! Das hat mein Verständnis schon wieder weiter gebracht

Ich habe nun versucht das Überwachungsintervall auf 15 Sekunden zu verringern, UDP-Aging steht auf 20 Sekunden. Somit sollte ja die Überwachung "schneller" sein als das Aging. Die Rückfrage von cpuprofi ist aber offenbar doch gerechtfertigt. Im Sip-Trace sehe ich das im Register ein Expire 480 steht und nach knapp 8 Minuten kommt das nächste Register. Mit dem Erfolg, dass eingehende Verbindungen für ein paar Sekunden nach dem Register klappen, dann für fast 8 Minuten nichtmehr.

Ich habe nun versucht die Überwachungsmethode wie von dir angemerkt von Automatisch auf Options zu stellen. Hier sehe ich im Trace zumindest alle 10 bis 13 Sekunden irgendwelche Pakete (Could not decode SIP message) aber zeitgleich auch dass die Firewall Pakete blockiert. Auch so sind keine Eingehenden Anrufe möglich.

Mein Bauchgefühl (auf was anderes kann ich mich hier leider nicht stützen) sagt mir, dass das aber mehr ein Problem des VCM als der Firewall ist.

Vielleicht hier nicht ganz am richtigen Platz: Beim debuggen einer weiteren Sip-Line (M-Net, da habe ich noch mehr Probleme) habe ich gesehen dass dort der Sip-Server vom Client (also dem Lancom) ein bestimmtes Intervall bis zur erneuten Registrierung anfordert (1200 Sekunden), was dieser soweit ich gesehen habe auch respektiert. In dem Fall würde man dann doch immer in das Problem mit dem UDP-Aging laufen, oder?

Gruß
booker

[backslash]

Hi booker,

Ich habe nun versucht das Überwachungsintervall auf 15 Sekunden zu verringern, UDP-Aging steht auf 20 Sekunden. Somit sollte ja die Überwachung "schneller" sein als das Aging.

Radio Eriwan: Im Prinzip ja, aber...

cpuprofi hat doch schoin aus der LANconfig-Hilfe zitiert, daß das Intervall mindestens 60 Sekunden betragen muß, also mußt du den UDP-Timeout auf z.B. 65 Sekunden stellen...

Und weiter kann ich dir beim Thema VCM wirklich nicht helfen...

Vielleicht hier nicht ganz am richtigen Platz: Beim debuggen einer weiteren Sip-Line (M-Net, da habe ich noch mehr Probleme) habe ich gesehen dass dort der Sip-Server vom Client (also dem Lancom) ein bestimmtes Intervall bis zur erneuten Registrierung anfordert (1200 Sekunden), was dieser soweit ich gesehen habe auch respektiert. In dem Fall würde man dann doch immer in das Problem mit dem UDP-Aging laufen, oder?

ja, 1200 Sekunden sind extrem lange - zumindest für ein UDP-Aging in Firewall und Maskierung...

Hast du es denn schonmal mit TCP versucht?

Gruß
Backslash

[booker]

Hallo backslash,

ups das mit dem Zitat aus dem Manual habe ich nicht überrissen, dachte das war eine Beobachtung von cpuprofi. Mein Fehler!

Ich habe nun das UDP-Aging auf 65 Sekunden gesetzt und das Überwachungsintervall auf dem Standardwert von 60 Sekunden belassen (so wie von dir schon beispielhaft vorgeschlagen). So scheint es jetzt zu gehen, was mich in erster Linie einfach mal freut. Danke für die Unterstützung!

Der Vollständigkeit halber: Das Re-Register kommt trotzdem nur alle 480 Sekunden, das fällt dann wohl aber in die Kategorie

Code: Alles auswählen

Wenn der SIP-Registrar des Providers ein anderes Intervall vorschlägt, übernimmt das Gerät dieses automatisch.

Es kommen dafür alle ca. 15 Sekunden irgendwelche UDP-Pakete vorbei die die Firewall wohl offenhalten.

Noch eine Verständnisfrage: Vor LCOS 10.00 hatte ich diese Leitung auch schon registriert, ohne irgendwelche Probleme. Mit dem Schritt zu LCOS 10.00 hat sich nur geändert, dass nun IPv6 genutzt wird. Unterscheidet sich denn dieses UDP-Aging in irgendeiner Form zwischen IPv4 und IPv6? Oder warum hat es vorher immer funktioniert? An der Config wurde ja zunächst nichts geändert?

Das M-Net-Thema scheint soweit ich es jetzt sehe aber nix mit der Firewall zu tun haben. Ich packe das in einen neuen Thread an dann wohl besser geeigneter Stelle.

Gruß und nochmals Danke,
booker

[backslash]

Hi booker,

Unterscheidet sich denn dieses UDP-Aging in irgendeiner Form zwischen IPv4 und IPv6?

das Aging nicht,

Oder warum hat es vorher immer funktioniert? An der Config wurde ja zunächst nichts geändert?

aber die Firewall... Im IPv4 gibt es keine Inbound-Regeln, d.h. dort ist alles erlaubt und wird nur über die Acesslisten gefiltert - und die gelten nur für die Konfiguration.

Gruß
Backslash

[booker]

Danke backslash für die letzte Erklärung, jetzt gibt das alles Sinn!

Gruß
booker

[beki]

Hallo zusammen,

heute Abend bin ich auf das gleiche Problem gestoßen. Hatte mich gefreut, dass mein neues 1&1 VoIP sofort mit IPv6 zu funktionieren schien, aber war dann schwer ernüchtert dass eingehende Gesrpäche nicht tun. Im Packet-Capture war dann klar ein ICMP "Port Unreachable" des LANCOMs als Antwort auf das INVITE zu sehen, und das deckte sich mit dem IPv6-Firewall Trace im LANCOM.

Es ist verständlich, dass die Firewall dieses Paket herausfischt. Eine sinnvolle Ausnahme ist da die bereits enthaltene Inbound Regel für den SIP Server im VCM. Die brauchen wir sogar für's LAN, korrekt?! Also ich meine dass die IPv6-Firewall sogar LAN Pakete filtert?!

Dieses VCM Problem ist bei der Entwicklung nicht aufgefallen, weil ich offensichtlich keine IPv6 Calls zum LANCOM (über eine Leitung) getestet hatte. Schade. Mit der asterisk hätte ich das prüfen können, die Firewall hätte ja auch im LAN zugeschlagen?!

Wie kann das denn verbessert werden? Sollte der VCM nach Aufbau des Listeners den gerade belegten Port der Firewall melden mit der Bitte UDP Pakete an diesen Port weiterzuleiten?

Nach meiner Auffassung ist das klar ein Bug -- auch wenn es Workarounds gibt. Gibt es dazu ein Issue?

EDIT: Für mich bringt die Einstellung "UDP-Aging-Seconds VALUE: 65" während alle 60 Sekunden OPTIONS Pakete mit dem SIP Provider ausgetauscht werden, keinen Erfolg. Ich finde keinen anderen derartigen Schalter. Außerdem taucht auch unmittelbar nach einem OPTIONS-Dialog mit dem Registrar kein Eintrag in "/Status/IPv6/Firewall/Inbound-Sessions/" auf. Ich hätte erwartet dass dort etwas zu sehen ist...

Gruß,
Bernhard

<rant>Ich hab es nicht geschafft diesen Thread über die Suchfunktion zu finden... Die Begriffe "ipv6 sip voip firewall" haben ihn nicht ausgespuckt. Das ist traurig...</rant>

[Jirka]

Hallo Bernhard,

<rant>Ich hab es nicht geschafft diesen Thread über die Suchfunktion zu finden... Die Begriffe "ipv6 sip voip firewall" haben ihn nicht ausgespuckt. Das ist traurig...</rant>

davon rede ich seit Jahren. Und Google scheint auch daran gehindert zu werden, hier mitzulesen.
Nach SIP brauchst Du gar nicht suchen, das sind nur 3 Buchstaben, das ist zu wenig. Wie bei ARP, DNS, SSH, NAT, NTP, VPI, VCI, VPN, DSL, PPP, MTU, PAP, max, min, RIP, TCP, UDP, ESP, WAN, LAN, BGP, COM, DoS, IDS, QoS, FTP, RDP, SAs, IKE, CRL, RTP, EAP, ALG, VCM, PBX, Fax, RSA, AES, MD5, PSK, SHA, PFS, DES, CID, PCM, CRL, DAA, DSR, GRE, LCR, MLD, TLS, USB, WLC, ACL, WoL, OAP, IAP, XAP, XAC, PoE, VRX, MIB, CLI, PCI (es gab mal eine LANCOM PCI-11), ...

Viele Grüße,
Jirka

[backslash]

Hi beki,

Es ist verständlich, dass die Firewall dieses Paket herausfischt. Eine sinnvolle Ausnahme ist da die bereits enthaltene Inbound Regel für den SIP Server im VCM. Die brauchen wir sogar für's LAN, korrekt?! Also ich meine dass die IPv6-Firewall sogar LAN Pakete filtert?!

ja, die IPv6-Firewall hat einen expliziten Inbound-Pfad, der die Access-Tabellen des IPv4, die nie alles sinnvoll abdecken können, ersetzt. Und natürlich sitzt sie dabei auch auf dem LAN-Interface (genaugenommen sitzt sie auf dem Loopback-Interface, weshalb selbst das abschalten der Firewall auf dem LAN keinen Einfluß hat)

Dieses VCM Problem ist bei der Entwicklung nicht aufgefallen, weil ich offensichtlich keine IPv6 Calls zum LANCOM (über eine Leitung) getestet hatte. Schade. Mit der asterisk hätte ich das prüfen können, die Firewall hätte ja auch im LAN zugeschlagen?!

ja, hätte sie.

Wie kann das denn verbessert werden? Sollte der VCM nach Aufbau des Listeners den gerade belegten Port der Firewall melden mit der Bitte UDP Pakete an diesen Port weiterzuleiten?

Ich weiss nicht wie der VCM die einzelnen Sessions auseinanderhält, aber das Einfachste auch Sicht der Firewall wäre, wenn der VCM den SIP-Port auch als Quellport nutzen würde (statt eines zufälligen Ports), denn dann würde die bereits vorhandene Regel auch für einkommende Rufe greifen. Dabei stellt sich dann nur die Frage, wie gut der VCM abgesichert ist, denn es ist natürlich wahrscheinlicher, daß ein Angreifer versucht über den bekannten SIP-Port einzubrechen, als über einen zufällig ausgewählten, den der Anreifer erstmal kennen müßte.

Nach meiner Auffassung ist das klar ein Bug -- auch wenn es Workarounds gibt. Gibt es dazu ein Issue?

darüber läßt sich nun vortrefflich streiten...

Für mich bringt die Einstellung "UDP-Aging-Seconds VALUE: 65" während alle 60 Sekunden OPTIONS Pakete mit dem SIP Provider ausgetauscht werden, keinen Erfolg.

wie ich schin schrieb, ist der VCM nicht meine Baustelle - aber bei booker hat das offenbar funktioniert...

Außerdem taucht auch unmittelbar nach einem OPTIONS-Dialog mit dem Registrar kein Eintrag in "/Status/IPv6/Firewall/Inbound-Sessions/" auf. Ich hätte erwartet dass dort etwas zu sehen ist...

Der Eintrag hätte schon vor dem OPTIONS-Dialog drin sein müssen, denn der Timeout von 65 Sekunden ist ja länder als das Poll-Intervall von 60 Sekunden, weshalb die Session nie rausaltern sollte. Aber selbst wenn der Eintrag nicht vorher da war, muß er in jedem Fall vorhanden sein, wenn eine Antwort vom Provider kam.

Gruß
Backslash

[beki]

aber das Einfachste auch Sicht der Firewall wäre, wenn der VCM den SIP-Port auch als Quellport nutzen würde (statt eines zufälligen Ports)

Das bricht aber leider einen wichtigen Teil des aktuellen Designs. Das wäre wirklich unangenehm (für Andreas^^). Weil nämlich für jede Line ein Listener erzeugt wird mit einem eindeutigen individuellem Port werden die Nachrichten vom Provider sofort von der korrekte cSipWanLine Instanz verarbeitet. Wenn man nun als SourcePort für jede Leitung 5060 nutzt, dann muss man die eingehenden Nachrichten demultiplexen, was sehr lästig wäre.

darüber läßt sich nun vortrefflich streiten...

Ja, natürlich. Leider kann ich nicht einfach eins erstellen ;P Zur Klarstellung: Ich meinte dass es ein Problem im VCM ist, nicht in der Firewall. Ich sehe die Arbeit im VCM, der für jeden UDP Listener der Firewall Bescheid geben muss dass dieser Port bitte offen sein soll (Inbound-Regel).

Meine Strategie um das Problem zu umgehen ist folgendermaßen: Ich lege einen festen Source-Port für jede Line fest und erstelle passende Firewall-Regeln selbst. Es hat eine Weile gedauert bis ich die Regel auf die Kette bekommen habe, aber tut nun.

Interessant, dass ich keinen Eintrag in /status/ipv6/firewall/inbound-sessions finde... Gibt es einen Trace der etwas ausdrucksstärker ist als "ipv6-firewall", also in dem auch Session Aufbau und Timeouts drin sind?

[backslash]

Hi beki,

Interessant, dass ich keinen Eintrag in /status/ipv6/firewall/inbound-sessions finde...

wenn der VCM sichj registriert, wirst du den Eintrag auch nicht unter "Inbound-Sessions" finden, denn es sind ja ausgehende Sessions. Der Status ist nicht komplett, denn es fehlen letztendlich 3 Listen: Inbound-Open-Ports, Outbound-Sessions und Outbound-Open-Ports.... Nur wenn kein Outbound-Session-Eintrag vorhanden war und es kommt ein Ruf von aussen rein, wirst du - sobald der VCM geantwortet hat - die Sesion unter "Inbound-Sessions" finden (ich denke, wo der von Dir vermisste Eintrag zu finden wäre, wenn die Liste komplett wäre, dürfte damit klar sein)...

Gibt es einen Trace der etwas ausdrucksstärker ist als "ipv6-firewall", also in dem auch Session Aufbau und Timeouts drin sind?

der Firewall-Trace wäre genau der Trace, um die Aktivitäten der Firewall anzuzeigen - nur fehlen z.Zt. zwei Dinge:
[*]Timeouts von Sessions...
[*]Outbound-Sessions...

Gruß
Backslash