[1781VAW] SIP-ALG und firewall

[shrike]

Hallo,
nach meinem Verständnis sollten mit SIP-ALG keine Firewall-Einträge für die VOIP-Anlage dahinter (Auerwald 5020) notwendig sein. Ich beobachte jedoch, dass (manchmal) beim Aufbau eines abgehenden Rufes die Firewall die ersten reinkommenden RTP/RTCP Pakete zurückweist:

Unbenannt.PNG

Ich hab diesen Umstand als Ursache für meine sporadischen Probleme bei abgehende Rufe (Angerufener hört mich nicht) festmachen können. Das Problem war reproduzierbar mit der BlueSIP Echo-Testnummer. Wenn ich dann explizit einen Firewallregel für diese kommenden Pakete eintrage war das Problem verschwunden.

Provider ist Telekom; Lancom-Firmware ist 9.10.0530 (ist aber bei der 9.10.0426RU3 genauso)

Ist eine solche Firewall-Regel bei laufenden SIP-ALG tatsächlich notwendig? Oder ist die Ursache woanders zu suchen?

Gruß,
Shrike

[5624]

Im Regelfall wirkt die Firewall auch auf Verbindungen, die über das SIP-ALG laufen. Es gibt aber eine Einstellung am SIP-ALG, die die Firewallprüfung dieser Verbindungen umgeht.

[shrike]

Hallo,
ich dachte, das läuft eher umgekehrt. Der SIP-ALG automatisiert die notwendigen Firewall-Regeln, so dass man selber nichts eintragen muss. Deshalb bin ich da etwas verwirrt.

Gruß,
Shrike

[backslash]

Hi shrike,

nach meinem Verständnis sollten mit SIP-ALG keine Firewall-Einträge für die VOIP-Anlage dahinter (Auerwald 5020) notwendig sein

das ist korrekt. Das SIP-ALG erstellt pasende Sessions für die RTP-Streams...

Ich beobachte jedoch, dass (manchmal) beim Aufbau eines abgehenden Rufes die Firewall die ersten reinkommenden RTP/RTCP Pakete zurückweist:

Ich will jetzt nicht sagen, daß das fast schon normal ist, aber... RTP wird i.A. bevorzugt übertragen, was letztendlich dazu führen kann, daß die RTP-Pakete vor dem SIP-Signalisierungs-Paket ankommen, in dem die Gegenseite ihre Ports mitteilt - da kann das SIP-ALG noch keine Session eingetragen haben...

Wenn dich die Meldungen der Firewall stören, bleibt dir nur übrig, eine Regel aufzunehmen, die diese Pakete meldungsfrei verwirft, z.B.:

Code: Alles auswählen

Name:      DROP-UNKNOWN-RTP
Aktion:    verwerfen (*keine* Meldung per SNMP, Mail oder Syslog)
Quelle:    alle Stationen
Ziel:      IP der TK-Anlage
Dienste:   UDP

Gruß
Backslash

[backslash]

Hi 5624

Im Regelfall wirkt die Firewall auch auf Verbindungen, die über das SIP-ALG laufen. Es gibt aber eine Einstellung am SIP-ALG, die die Firewallprüfung dieser Verbindungen umgeht.

das bezieht sich aber nur auf die Signalisierungs-Session... Auf die RTP-Sessions hat dieser Schalter keinen Einfluß. Er dient letztendlich halt nur dazu, die User einchränken zu können, die SIP machen dürfen...

Gruß
Backslash

[shrike]

Hallo backslash,
ich habe Probleme bei gehenden Gesprächen, wenn ich eben nicht eine ACCEPT-Firewall-Regel für die kommenden RTP-Pakete eintrage. Hier ein Fall mit explizit eingetragener ACCEP-Regel (hier funktioniert alles):

Unbenannt2.png

Der Angerufene schickt ca 10ms nachdem er auf meinem SIP:INVITE mit SIP:TRYING antwortet, das erste RTP/RTCP-Paket. Die Portnummer steht ja schon in meinem INVITE drin.

Trage ich keine ACCEPT-Regel ein, werden dir ersten 2-4 kommenden RTP/RTCP Pakete geblockt (zurückgewiesen). Vermutlich wegen dieser Zurückweisung klappt die Verbindung dann nicht (Angerufener hört mich nicht, ich ihn aber schon). Ich habe beobachtet, dass während dieser einseitigen Audioverbindung der Angerufene immer wieder ein SIP:RINGING schickt und kein SIP:OK (vermutlich deswegen schaltet die Auerswald mein Audiosignal nicht durch).

Diese explizite Regel würde ich aber gerne vermeiden, da der mögliche Portbereich für RTP bei der Auerswald doch recht groß ist.

Danke und Gruß,
Shrike

[shrike]

Nachtrag:
ich bin nochmal meine Protokolle durchgegangen; es sieht wohl so aus, dass der SIP-ALG erst nach dem kommenden SIP:SESSION_PROGRESS die RTP-Pakete durchlässt.

Da ich das Problem erst seit ein paar Monaten und nur bei bestimmten Zielen habe, hat wohl die Telekom wieder was verdreht.

Gruß,
Shrike

[backslash]

Hi shrike,

Diese explizite Regel würde ich aber gerne vermeiden, da der mögliche Portbereich für RTP bei der Auerswald doch recht groß ist.

daher sagte ich ja, du sollst eine DENY-Regel erstellen, die die Pakete *meldungsfrei* *verwirft*...

meldungsfrei heißt: kein Eintrag im Firelwall-Log
verwerfen heißt: es geht keine ICMP-Fehlermeldung an die Gegenseite zurück.

Die von mir beschriebene Regel macht genau das...

Gruß
Backslash

[shrike]

Ja, es funktioniert mit der DENY-Regel

Vielen Dank für den Tipp.

Gruß,
Shrike