Mikro bleibt tot (VCM und routing tags?)

[info103]

Hei,

ich versuche, eine (für mich) knifflige Konfiguration auf die Füße zu stellen und benötige etwas "Entwirrungshilfe" (falls dem überhaupt jemand folgen kann und will ).

Ich hatte folgende Netzwerk-Konfig als Ausgangsbasis:

Internet
|
Lancom 1823 (FW 7.28.0031)
LAN2 (als DMZ): 192.168.9.9
|
interne Firewall (MS ISA2004)
DMZ: 192.168.9.8
Intranet: 192.168.8.1
|
Intranet

Funktioniert soweit seit längerem optimal.

Da der ISA2004 aber leider nicht wirklich mit dem SIP-Protokoll umgehen kann, können sich keine SIP-Clients aus "Intranet" heraus mit dem Lancom verbinden. Nun sollen solche aber verwendet werden. Es soll der externe ISDN-Anschluss angebunden und per CallManager für mehrere SIP-Clients (zum Testen Softphone PhonerLite 1.41) nutzbar gemacht werden und auch ein SIP-Provider-Account (SIPgate) integriert werden.

Meine Idee war nun, einen "Geheimgang" zum Lancom anzulegen, indem ich ihn über die bisher ungenutzte LAN1-Schnittstelle (ja, wirklich LAN1, kein Tippfehler ) zusätzlich zum Mitglied in "Intranet" mache (quasi den ISA2004 umgehe), um aber ausschließlich den SIP-Verkehr über diese Schnittstelle zuzulassen. Die IP von LAN1 ist 192.168.8.9

Wie ist diese Idee - kann das gehen? Mir kommt sie mittlerweile ziemlich blöd vor, denn ich kriege das nicht hin. Ich habe einige Varianten probiert, aber irgendwas geht immer schief.


Der aktuelle Stand konkret (falls sich das einer der Spezialisten antun will):

Mein Lösungsansatz:
Ich habe die beiden Netze mit unterschiedlichen Schnittstellen-Tags (<-nachträglich editiert, war vorher fälschlicherweise "Routing-Tags") versehen (aktuell DMZ=1, Intranet=2; ich hatte es auch schon so, dass ich alles ohne tags hatte und nur die Intranet-LAN-Schnittstelle mit tag=1 versah, führte aber auch nicht zum Erfolg), um sie voneinander zu trennen und sichergehen zu können, dass aus dem Intranet kein Verkehr direkt ins Internet geht, sondern über die interne Firewall muss (deny all-Regel für Pakete mit tag 2). Ich habe zur Sicherheit eine deny all-Regel "DENY_ALL0" für Pakete ohne Routing-Tag (tag=0) angelegt, obwohl eigentlich kein "provozierter" Traffic mit diesem tag anfallen dürfte. Alle anderen Regeln (inkl. port forwardings für div. Dienste) haben tag=1 (sind alle für's DMZ-Netz).

Der "normale" IP-Verkehr funktioniert auch wunschgemäß; deshalb gehe mich mal blauäugig davon aus, dass die routing tags einigermaßen passen müssten. Sowohl auf dem SIPgate-Account als auch auf dem ISDN-Anschluss von extern eingehende Telefonate können von einem SIP-Client angenommen werden und auch welche nach außen aufgebaut werden (via ISDN und auch via SIPgate-"Leitung" zu irgend einem ISDN-Anschluss).

Problem:

Der externe Teilnehmer hört mich nicht, wenn ich über den SIPgate-Account mit ihm telefoniere; ich höre ihn dabei sehr wohl. Interne Telefonate (zB von SIP-Client zu ISDN-Telefon) zeigen das Problem nicht. Auch wenn das Gespräch über den ext. ISDN-Anschluss aufgebaut wird, ist alles OK.

Ich sehe ein für mich unerwartetes Verhalten des Lancoms bei SIP-Anrufen mit externen Terilnehmern, wenn ich mir div. Traces (call sip ip-rou firew) gleichzeitig anschaue. Meine Vermutung: Die Firewall öffnet für die Kommunikation mit dem SIPgate-Server dynamisch den Port 5062, aber nicht den wohl ebenfalls benötigten Port 5063 - was evtl. mit den routing tags zusammenhängt.

Ich habe mal die wesentlichen trace-Abschnitte zusammengestellt, auf denen meine Vermutung beruht.

Folgendes wird eine ganze Weile nach Beginn des Verbindungsaufbaus geloggt:

Code: Alles auswählen

[Firewall] 2008/03/19 11:50:45,410
Packet matched rule DENY_ALL0
DstIP: 192.168.8.34, SrcIP: 217.10.69.7, Len: 200, DSCP/TOS: 0xb8
Prot.: UDP (17), DstPort: 5062, SrcPort: 10042

send SNMP trap
send SNMP trap
packet rejected

"DstIP: 192.168.8.34" ist mein SIP-Client (PhonerLite auf einem Vista-PC), "SrcIP: 217.10.69.7" ist der SIPGate-Server. Hier wundert es mich schon mal, warum meine "catch all" tag=0-Regel greift; der Client hängt doch an der Schnittstelle, die tag=2 hat!? "Weiß" die Firewall hier noch nicht, dass dieses ein "gutes" Paket ist? Aber vielleicht habe ich was bzgl. des taggings auch nicht richtig verstanden?

Dann kommt etwas später mal

Code: Alles auswählen

[Callmanager] 2008/03/19 11:50:52,300 : [VCM] : -----[ CONNECT INDICATION, call-id=586

[...]

[Firewall] 2008/03/19 11:50:52,310
Session opened by rule: internal (SIP)
UDP: 192.168.8.34:5062 => 217.10.69.7:10042

Add Rx minimum of 96 kBit/s to INTERNET (result 1120 kBit/s)
Add Tx minimum of 96 kBit/s to INTERNET (result 96 kBit/s)

und es werden danach zunächst die obigen Pakete nicht mehr durch die DENY_ALL0-Regel rejected:

Code: Alles auswählen

[IP-Router] 2008/03/19 11:50:52,320
IP-Router Rx (INTERNET, RtgTag: 1): 
DstIP: 192.168.8.34, SrcIP: 217.10.69.7, Len: 200, DSCP/TOS: 0xb8
Prot.: UDP (17), DstPort: 5062, SrcPort: 10042
Route: LAN-1 Tx (INTRANET): 

Aber auch hier frage ich mich, warum da "RtgTag: 1" und nicht "RtgTag: 2" steht...?
Und es wird nur der Port 5062 göffnet, 5063 würde aber wohl auch benötigt (s.u.).

So sehen übrigens Beispiele für Nicht-SIP-Pakete aus, die sonst noch so laufen (192.168.9.8 ist, wie schon geschrieben, die DMZ-Schnittstelle des ISA):

Code: Alles auswählen

[IP-Router] 2008/03/19 11:50:56,550
IP-Router Rx (LAN-2, DMZ, RtgTag: 1): 
DstIP: 85.178.219.70, SrcIP: 192.168.9.8, Len: 40, DSCP/TOS: 0x00
Prot.: TCP (6), DstPort: 1944, SrcPort: 4125, Flags: A
Route: WAN Tx (INTERNET)

[IP-Router] 2008/03/19 11:50:56,550
IP-Router Rx (INTERNET, RtgTag: 1): 
DstIP: 192.168.9.8, SrcIP: 85.178.219.70, Len: 40, DSCP/TOS: 0x00
Prot.: TCP (6), DstPort: 4125, SrcPort: 1944, Flags: A
Filter (limited)

[IP-Router] 2008/03/19 11:50:56,560
IP-Router Rx (INTERNET, RtgTag: 1): 
DstIP: 192.168.9.8, SrcIP: 85.178.219.70, Len: 40, DSCP/TOS: 0x00
Prot.: TCP (6), DstPort: 4125, SrcPort: 1944, Flags: A
Route: LAN-2 Tx (DMZ): 

Relativ selten kommt dann während des Gesprächs auf dem Port 5063 immer noch ein reject vor, die Pakete auf 5062 gehen durch:

Code: Alles auswählen

[IP-Router] 2008/03/19 11:51:00,370
IP-Router Rx (INTERNET, RtgTag: 1): 
DstIP: 192.168.8.34, SrcIP: 217.10.69.7, Len: 200, DSCP/TOS: 0xb8
Prot.: UDP (17), DstPort: 5062, SrcPort: 10042
Route: LAN-1 Tx (INTRANET): 

[Firewall] 2008/03/19 11:51:00,370
Packet matched rule DENY_ALL0
DstIP: 192.168.8.34, SrcIP: 217.10.69.7, Len: 92, DSCP/TOS: 0x00
Prot.: UDP (17), DstPort: 5063, SrcPort: 10043

send SNMP trap
send SNMP trap
packet rejected

[IP-Router] 2008/03/19 11:51:00,370
IP-Router Rx (INTERNET, RtgTag: 0): 
DstIP: 192.168.8.34, SrcIP: 217.10.69.7, Len: 92, DSCP/TOS: 0x00
Prot.: UDP (17), DstPort: 5063, SrcPort: 10043
Filter (Port)

[IP-Router] 2008/03/19 11:51:00,390
IP-Router Rx (INTERNET, RtgTag: 1): 
DstIP: 192.168.8.34, SrcIP: 217.10.69.7, Len: 200, DSCP/TOS: 0xb8
Prot.: UDP (17), DstPort: 5062, SrcPort: 10042
Route: LAN-1 Tx (INTRANET): 

Warum wird 5063 nicht geöffnet? Und warum stehen hier wieder "RtgTag: 0" und "RtgTag: 1", aber kein "RtgTag: 2"?
Bleibt wegen der Blockade von Port 5063 das Mikro des SIP-Clients tot?

Was übersehe ich bzw. mache ich falsch? Hat PhonerLite ein Problem mit dieser Konstellation?
Oder fehlt eine Firewall-Regel? Aber die automatische Öffnung der nötigen Ports scheint doch prinzipiell zu funktionieren (siehe "Session opened by rule: internal (SIP)")? Hat diese Funktion vielleicht einen Bug?

Vielleicht hat mir ja jemand einen Tipp. Ich kann auch gerne weitere Infos/Traces liefern, falls nötig.

Gruß,
info103

[Jirka]

Hallo info103,

oh je - hier jede Frage einzeln zu beantworten und zu begründen artet ja fast in Arbeit aus.
Was Du erst mal verschwiegen hast, wie ist das Intranet am LANCOM (also das 192.168.8.9-er Netz) konfiguriert? DHCP aus? Ist das mit dem anderen Intranet hinter der internen Firewall direkt verbunden?

Was direkt auffällt und auch die Ursache Deiner Probleme ist, ist das falsche Verständnis der Firewall(-regeln). Das Routing-Tag arbeitet hier nicht als Filter sondern als Zuweisung. D. h. also mit Hilfe der Firewallregeln kannst Du Routing-Tags zuweisen, aber nicht bestimmte Regeln aufgrund eines Routing-Tags greifen lassen. Wann eine Firewall-Regel greift hängt von den Einstellungen in Stationen und Dienste ab, nicht aber vom Routing-Tag. Du musst jedoch mit Hilfe einer Firewallregel einen bestimmten Routing-Tag zuweisen, wenn Du Netze mit unterschiedlichem Routing-Tag sichtbar machen willst. Der IP-Router (der vom Ablauf her nach der Firewall kommt) hingegen wertet dann das Routing-Tag aus und bestimmt so, ob und nach welchen Routen das Paket weitergeleitet wird.
Deine Fragen wie "Aber auch hier frage ich mich, warum da "RtgTag: 1" und nicht "RtgTag: 2" steht...?" lassen sich somit alle klar beantworten. Denn das liegt daran, dass in den Regeln das Routing-Tag 1 zugewiesen wurde und so kommt es dann im IP-Router auch an.

Viele Grüße,
Jirka

[info103]

oh je - hier jede Frage einzeln zu beantworten und zu begründen artet ja fast in Arbeit aus.

Deshalb bin ich schon froh, dass sich überhaupt jemand das alles durchgelesen hat... vielen Dank schon mal!

Was Du erst mal verschwiegen hast, wie ist das Intranet am LANCOM (also das 192.168.8.9-er Netz) konfiguriert? DHCP aus?

Sorry, hätte nicht gedacht, dass diese Info relevant ist (Posting ist schon lang genug, dachte ich, um noch mehr Details reinzupacken). DHCP macht der ISA-Rechner (für die DMZ und das Intranet, damit alles am selben Ort verwaltet werden kann).

Ist das mit dem anderen Intranet hinter der internen Firewall direkt verbunden?

Ja.

Was direkt auffällt und auch die Ursache Deiner Probleme ist, ist das falsche Verständnis der Firewall(-regeln).

Hm - irgend so was hatte ich zunächst befürchtet...

Das Routing-Tag arbeitet hier nicht als Filter sondern als Zuweisung. D. h. also mit Hilfe der Firewallregeln kannst Du Routing-Tags zuweisen, aber nicht bestimmte Regeln aufgrund eines Routing-Tags greifen lassen. Wann eine Firewall-Regel greift hängt von den Einstellungen in Stationen und Dienste ab, nicht aber vom Routing-Tag.

Ich muss mich bei Dir (und allen anderen, die sich dieses Posting schon angetan haben), entschuldigen, denn ich habe mich an einer entscheidenden Stelle nicht präzise genug ausgedrückt:

Mein Lösungsansatz:
Ich habe die beiden Netze mit unterschiedlichen Routing-Tags versehen

Das muss natürlich heissen:

Mein Lösungsansatz:
Ich habe die beiden Netze mit unterschiedlichen Schnittstellen-Tags versehen


Tut mir leid - habe vor lauter "tags" den Wald nicht mehr gesehen.
Ich werde die Stelle im Original-Posting entsprechend editieren.

Du musst jedoch mit Hilfe einer Firewallregel einen bestimmten Routing-Tag zuweisen, wenn Du Netze mit unterschiedlichem Routing-Tag sichtbar machen willst.

Diese Zuweisung realisiere ich eben mit dem Schnittstellen-Tag (denke ich). Und die Firewall prüft dann, welche Regeln für das (bereits durch die Schnittstelle getaggte) Paket überhaupt in Frage kommen (Stichwort: virtuelle Router, siehe akt. Ref.-Handbuch S.172).

Ich möchte also quasi nur die VoIP-Funktionen (CallManager, Datenaustausch mit SIP-Provider etc.) aus dem Lancom virtuell "ausbauen" und in mein Intranet "einstöpseln"; alles andere soll bitte vor der Türe (in der DMZ) bleiben.

Deine Fragen wie "Aber auch hier frage ich mich, warum da "RtgTag: 1" und nicht "RtgTag: 2" steht...?" lassen sich somit alle klar beantworten. Denn das liegt daran, dass in den Regeln das Routing-Tag 1 zugewiesen wurde und so kommt es dann im IP-Router auch an.

Normale (Nicht-SIP-) Pakete aus dem Intranet kommen (in meiner Theorie), falls sie sich wider Erwarten doch zum Lancom verirren (seine aus dem Intranet sichtbare Schnittstelle .8.9 ist nicht das Standard-Gateway der Clients), durch das Schnittstellen-tag "2" an nur einer einzigen FW-Regel an: "DENY_ALL2" (also diejenige meiner drei DENY_ALL-Regeln mit dem tag 2 (die anderen beiden DENY_ALL0 und DENY_ALL1 haben das tag 0 und das tag 1). Alle anderen Regeln (außer DENY_ALL0) haben das tag 1 für die DMZ.

Ich bin nun der Meinung, dass bei einem ausgehenden Anruf, der über den SIP-Provider gehen soll, folgender Ablauf stattfindet:

• 1. SIP-Client meldet sich beim Lancom/VCM an
  
  2. SIP-Client "beantragt" beim Lancom einen Verbindungsaufbau über den SIP-Provider (das hat der CallManager herausbekommen anhand seiner Regeln)
  
  3. Lancom erstellt dynamisch Firewall-Regeln, dass die Pakete dieses Clients auch zum SIP-Provider gehen können (siehe "Session opened by rule: internal (SIP)" in meinem Trace)

Beim Anschauen der Traces scheinen mir aber die Schnittstellen-tags, die für mein Verständnis eigentlich "2" sein müssten (da der SIP-Client ja in einem Netz liegt, dessen Netzwerkbuchse mit dem tag "2" versehen ist), nicht zusammenzupassen. Dies ist aber wohl nur "unschön", denn die Pakete kommen ja trotzdem beim SIP-Client an.

Und es sieht für mich so aus, also würde die Firewall zum einen erst relativ spät die dynamische Regel für Port 5062 anlegen (was mir aber zunächst egal ist, denn SIP-Client und -Server bringt es wohl nicht aus dem Tritt, da die Verbindung ja nicht völlig abreißt), und zum anderen - und da vermute ich das eigentliche Problem mit meinem stummen Mikro - zu "vergessen" (Bug?), eine dynamisch erzeugte Regel für den Port 5063 anzulegen, woraufhin die Daten dieses "Mikrofon-Kanals" nicht hinauskommen.

Vielleicht muss ich da aber doch noch was mit fixen Regeln und/oder port forwarding hinzirkeln? Aber dies wäre das ja wohl nur halb gut, denn das will ich ja genau vermeiden.

Genau deshalb wollte ich das ja mit diesem Lancom-"Geheimgang" realisieren, weil ich davon ausging, dass er die passenden SIP-Regeln dynamisch und korrekt (also inkl. Berücksichtigung der tags) anlegt (und nach dem "Auflegen" auch wieder entsorgt).

Sorry für das erneut lange Posting, aber ich glaube, das Thema ist einfach zu komplex, um in drei Sätzen korrekt dargestellt werden zu können. Die Möglichkeiten des Lancoms sind einfach pervers (im besten/positivsten Sinne!).

Ich wäre schon mal froh, wenn jemand signalisieren würde:
Ja, ich habe das (also das "Umschiffen" einer internen Firewall für die SIP-Funktionen mittels zweitem LAN-Zugang und Schnittstellen-tags) auch so gemacht, und das funktioniert bei mir!
Dann würde ich es nochmals probieren...

Momentan vermute ich aber eher einen FW-Bug im Routing und Freischalten der SIP-Pakete in Zusammenhang mit dem Handling der tags, dass also zB diese tags im Lancom intern zur Laufzeit nicht überall konsequent mitgeführt/ausgewertet werden.

Vielleicht warte ich besser auf die kommenden, neuen Gateway-Funktionen - evtl. bessert sich dadurch ja was.

PS: Danke für die Geduld!

[info103]

Mann Mann Mann - ich bin zu blöd...

Ich hatte im VCM der SIP-Leitung das falsche tag zugewiesen (1 statt richtigerweise 2). Ich bin nochmal alle Einstellungen durchgegangen und da ist es mir aufgefallen; hätte ich anhand der Traces aber auch gleich draufkommen können, da nochmal nachzuschauen... blöd.

Jetzt jedenfalls funktioniert das Mikro!!!

Nachmals: Danke für die Geduld!

Und was ich an dieser Stelle mal loswerden will: Ich liebe die Lancom-Geräte! Was hier mit einem sensationellen Preis-Leistungsverhältnis geliefert wird, ist nicht zu toppen - auch wenn man sich manchmal in der Funktionsfülle ganz schön verirren kann!
Und dieses Forum mit sensationell kompetenten Schreibern ist mitverantwortlich für diesen Eindruck! Danke und bitte weiter so...

[Jirka]

Hallo info103,

Und die Firewall prüft dann, welche Regeln für das (bereits durch die Schnittstelle getaggte) Paket überhaupt in Frage kommen (Stichwort: virtuelle Router, siehe akt. Ref.-Handbuch S.172).

Nein, nein und nochmals nein. Die Firewall weist zu, ein Schnittstellen- oder Routing-Tag wird hier nicht zur Filterung verwendet. Was Du meinst ist der IP-Router, der wertet das Schnittstellen- oder Routing-Tag aus und so können virtuelle Router entstehen (wenn denn entsprechende Routen für bestimmte Routing-Tags erfasst sind).

Jetzt jedenfalls funktioniert das Mikro!!!

Wenn Du mich fragst ist das jetzt Zufall. Oder Du hast für das Routing-Tag 2 entsprechende Routen erfasst und das Paket wird von der Firewall nicht erfasst.

Auf alle Fälle hauen Deine Firewall-Regeln so nicht hin. Du musst die nochmal überarbeiten. Lies Dir nochmal mein letztes Posting genau durch!

Viele Grüße,
Jirka

[info103]

Wenn Du mich fragst ist das jetzt Zufall.

Hast recht - es funktionierte so doch nicht. Ich war zu voreilig, sorry für die zusätzliche Verwirrung; der "funktionierende" Anruf ging auf der ISDN-Leitung raus - ich hatte das falsche Wahl-Prefix genommen und nicht im Lanmonitor kontrolliert, wie der Anruf erfolgte. Auf ISDN ging es aber ja schon immer.

Im Gegenteil, das Ändern des tags der SIP-Leitung auf das Intranet-tag 2 hatte zur Folge, dass keine Registrierung der SIP-Leitung mehr bei SIPgate erfolgen konnte. Insoweit passt das gesehene Verhalten sogar zu meiner Denkhaltung (tag 1 gehört zur DMZ, tag 2 ins Intranet, von dem aus das Internet bzw. die Default-Route ja nicht direkt ansprechbar sein soll, denn die hat von mir in der Routing-Tabelle ja manuell tag=1 bekommen).

Lies Dir nochmal mein letztes Posting genau durch!

OK, dass die Firewall-Regeln vom Schnittstellen-tag unbeeindruckt bleiben, habe ich jetzt gefressen. Meine DENY_ALLx-Regeln bringen demnach also nicht wirklich zusätzliche Sicherheit (wenn ich ihnen neben dem tag nicht auch noch Adressen mitgebe, für die sie gültig sein sollen).

Das erklärt aber das im Tracing sichtbare Verhalten und das (meiner Meinung nach) daraus resultierende stumme Mikro leider noch nicht.

Das Routing-tag der Intranet-Pakete an das SIP-Gateway wird übrigens durch die Schnittstelle richtig gesetzt:

Code: Alles auswählen

[SIP-Packet] 2008/03/20 13:11:35,470
Receiving datagram with length 2 from 192.168.8.34:5060 to 192.168.8.9:5060 rtg-
tag:2

Es muss jedenfalls durch die Schnittstelle gesetzt worden sein, denn sonst kommt in der ganzen Router-Konfig kein tag=2 vor.

Auf alle Fälle hauen Deine Firewall-Regeln so nicht hin. Du musst die nochmal überarbeiten.

Warum wird der Port 5062 dynamisch (siehe Tracing) freigeschaltet (ich fahre ja eine deny all-Strategie und habe keine Firewall-Regel für Port 5062 an SIPgate oder sonst irgend jemanden angelegt!), der Port 5063 bleibt aber weiterhin blockiert? Es gibt auch im Router keine Einträge mit einem tag 2 (=Intranet), also keine hierfür zugehörigen Routen; alle Routen (inkl. natürlich der Default-Route) tragen das tag 1.

Diese Durchleitung der vom SIP-Client ausgehenden und für ihn wieder ankommenden SIP-Pakte an und zu SIPgate muss doch der CallManager einrichten, inkl. der Öffnung des Ports 5062 (und nicht ich mittels einer manuellen Firewall-Regel), oder? Der SIP-Client unterhält sich ja mit dem Lancom, nicht mit dem SIPgate-Server (zumindest nicht initiell; sorry, falls ich da daneben liege, aber ich stecke im SIP-Protokoll nicht tief genug drin). Warum wird dann nicht auch der Port 5063 dynamisch geöffnet?

Oder hat der gar nichts mit meinem Mikrofon-Kanal-Problem zu tun, und ich muss zB SIP-Ports doch manuell in der Firewall vom Intranet direkt ins Internet freigeben? Falls ja: welche? Auch Port-Forwardings?

Wenn ich aber eine entsprechende Firewall-Regel (vom Intranet an alle Stationen zB mit dem Range 5060-5080 TCP und UDP) probiere, bekomme ich bei einem Verbindungsversuch vom IDS leider eine "intruder detection" gemeldet, offenbar weil ein 5062-Paket vom SIPgate-Server in mein Intranet (direkt an den SIP-Client) geschickt werden soll - was ich auch irgendwie verstehen kann. Ohne diese manuelle Firewall-Regel gehen diese Pakete problemlos am IDS vorbei!

[backslash]

Hi info103

Ich habe die beiden Netze mit unterschiedlichen Routing-Tags versehen (aktuell DMZ=1, Intranet=2; ich hatte es auch schon so, dass ich alles ohne tags hatte und nur die Intranet-LAN-Schnittstelle mit tag=1 versah, führte aber auch nicht zum Erfolg), um sie voneinander zu trennen und sichergehen zu können, dass aus dem Intranet kein Verkehr direkt ins Internet geht, sondern über die interne Firewall muss (deny all-Regel für Pakete mit tag 2). Ich habe zur Sicherheit eine deny all-Regel "DENY_ALL0" für Pakete ohne Routing-Tag (tag=0) angelegt, obwohl eigentlich kein "provozierter" Traffic mit diesem tag anfallen dürfte. Alle anderen Regeln (inkl. port forwardings für div. Dienste) haben tag=1 (sind alle für's DMZ-Netz).

Hier macht du glaube ich einen Denkfehler... Das Routing-Tag, das du in der Firewall angeben kannst, ist *nicht* Bestandteil der Bedingung, sondern Bestandteil der Aktion! D.h. wenn die Regel matcht, wird dem jeweiligen Paket das angegebene Tag zugewiesen (=> Stichwort "policy based routing")

Ich sehe ein für mich unerwartetes Verhalten des Lancoms bei SIP-Anrufen mit externen Terilnehmern, wenn ich mir div. Traces (call sip ip-rou firew) gleichzeitig anschaue. Meine Vermutung: Die Firewall öffnet für die Kommunikation mit dem SIPgate-Server dynamisch den Port 5062, aber nicht den wohl ebenfalls benötigten Port 5063 - was evtl. mit den routing tags zusammenhängt.

Das ist der RTCP-Port (der zum RTP-Port 5062 gehört) und der wird eigentlich nicht benötigt. Das das SIP-Modul im LANCOM schaltet daher den Port auch nicht in der Firewall frei.

DstIP: 192.168.8.34" ist mein SIP-Client (PhonerLite auf einem Vista-PC), "SrcIP: 217.10.69.7" ist der SIPGate-Server. Hier wundert es mich schon mal, warum meine "catch all" tag=0-Regel greift; der Client hängt doch an der Schnittstelle, die tag=2 hat!? "Weiß" die Firewall hier noch nicht, dass dieses ein "gutes" Paket ist? Aber vielleicht habe ich was bzgl. des taggings auch nicht richtig verstanden?

siehe oben: Routing-Tags sind halt nicht Bestandteil der Bedingung...

Session opened by rule: internal (SIP)
UDP: 192.168.8.34:5062 => 217.10.69.7:10042

Add Rx minimum of 96 kBit/s to INTERNET (result 1120 kBit/s)
Add Tx minimum of 96 kBit/s to INTERNET (result 96 kBit/s)

und es werden danach zunächst die obigen Pakete nicht mehr durch die DENY_ALL0-Regel rejected:

klar, weil nun ein Sesseion-Eingtrag existiert, der die Pakete zuläßt...

Aber auch hier frage ich mich, warum da "RtgTag: 1" und nicht "RtgTag: 2" steht...?

Hier hast du nun ein Problem... Du hast einmal ein Interface mit Tag 2 *UND* eine Route mit Tag 0 (die auf ein Ziel - den ISA - im 1 getaggten Interface verweist) die für das 192.168.8.x Netz zuständig sind. Tagge mal die Route auf den ISA mit Tag 1...

Und es wird nur der Port 5062 göffnet, 5063 würde aber wohl auch benötigt (s.u.).

(...)

Warum wird 5063 nicht geöffnet?

Weil der RTCP-Port halt unnötig ist und nicht geöffnet wird...

Und warum stehen hier wieder "RtgTag: 0"

Weil das Pakt aus dem Internet kommt und WAN-Verbindungen stets das Tag 0 beitzten - es sei denn, du erstellst eine Regel, die dem Interface ein anderes Tag zuweist:

Code: Alles auswählen

Quelle:  Gegenstelle INTERNET
Ziel:    alle Stationen
Aktion:  übertragen
Rtg-Tag: 1
Prio:    100

[x] weitere Regeln beachten

Diese Regel muß als erste Regel in der Filterliste stehen, weshalb du sie mit einer hohen Priorität versiehst (hier z.B. 100). Achte darauf daß auch wirklich das Häkchen bei "weitere Regeln beachten" gesetzt ist, da du sonst etwaige Deny-Regeln aushebeln würdest

Was übersehe ich bzw. mache ich falsch?

Dein Hauptproblem ist, daß du

a) Die Routing-Tags in der Firewall falsch verstanden hast und
b) Die Problematik zweier gleichnamiger Netze (ok in deinem Fall ein Netz und eine Route für dieses Netz) nicht gesehen hast.

Oder fehlt eine Firewall-Regel?

ja, die, die allen eingehenden Traffic aus dem Internet passend taggt...

Aber die automatische Öffnung der nötigen Ports scheint doch prinzipiell zu funktionieren (siehe "Session opened by rule: internal (SIP)")? Hat diese Funktion vielleicht einen Bug?

nein, für RTCP wird halt kein Port geöffnet...

Gruß
Backslash

[info103]

Hallo zusammen,

danke für die detaillierte Rückmeldung, backslash.

Hier macht du glaube ich einen Denkfehler... Das Routing-Tag, das du in der Firewall angeben kannst, ist *nicht* Bestandteil der Bedingung, sondern Bestandteil der Aktion!

Das mit den Firewall-Regeln und den tags habe ich nun, wie oben schon geschrieben, wohl kapiert. Danke nochmals an Jirka.

Ich habe nun mal die von Dir vorgeschlagene tagging-Regel für jeglichen eingehenden Traffic angelegt, und sie hat auch schön alle eingehenden Pakete mit 1 (=DMZ) getaggt. Das hat aber nichts am Problem geändert.

Ich habe danach versuchsweise eine zusätzliche, spezielle tagging-Regel "TAG_SIP" für das Intranet angelegt - also: "Gegenstelle INTERNET: tag=2, Ziel 192.168.8.x, für alle Dienste, keine weitere Regel anwenden" (sicherheitstechnisch nicht so glücklich, schon klar). Hat aber auch nichts geholfen, obwohl auch sie tatsächlich greift:

Code: Alles auswählen

[Firewall] 2008/03/20 21:40:24,970
Packet matched rule TAG_SIP
DstIP: 192.168.8.34, SrcIP: 217.10.67.8, Len: 92, DSCP/TOS: 0x00
Prot.: UDP (17), DstPort: 5063, SrcPort: 16819

Dann habe ich mich mal ein bisschen in das SIP-/RTP-Protokoll eingelesen (OK, hätte ich auch früher machen können) und nun einigermaßen verstanden, was da passiert (bzw. passieren sollte).

Aber dieses Wissen hat mich bzgl. des stummen Mikrofons auch nicht wirklich erhellt - außer, dass ich nun weiß, dass dessen Traffic auf dem (dynamisch ausgehandelten) RTP-Port rausgehen müsste.

Bei meinen Tests sind mir mit diesem neuen Wissen zwei Dinge in den Traces aufgefallen (die mir aber nicht sonderlich problematisch erscheinen):

Während der INVITE-Phase kamen folgende zwei Einträge vor:

Code: Alles auswählen

[SIP-Packet] 2008/03/20 21:40:20,500
Receiving datagram with length 2 from 192.168.8.34:5060 to 192.168.8.9:5060 rtg-tag:2

[SIP-Packet] 2008/03/20 21:40:20,500
Receiving datagram with length 2 from 192.168.8.34:5062 to 192.168.8.9:5060 rtg-tag:2

Dabei wundert mich, dass offenbar Pakete von den beiden unterschiedlichen Ports (5060/SIP und 5062/RTP) des SIP-Clients an ein und demselben Port (5060) empfangen werden.

Und das zweite ist:
Sobald die Verbindung in den Status ACK geht, wird ja die automatische Firewall-Regel generiert:

Code: Alles auswählen

[Firewall] 2008/03/20 21:40:25,960
Session opened by rule: internal (SIP)
UDP: 192.168.8.34:5062 => 217.10.67.8:16818
removing tx port opened by rule: TAG_SIP

Hier frage ich mich: Bedeutet die letzte Zeile "removing tx port opened by..." nun, dass diese neue Regel die bestehende Regel "TAG_SIP" für diese Session quasi außer Kraft setzt? Falls ja: Wie geht es dann mit dem tagging weiter, wenn meine manuelle tagging-Regel "abgelöst" wird?

Ansonsten finde ich nichts in den Traces, das mich der Lösung des Mikrofon-Problems näher bringen könnte. Werde das Thema wohl anders angehen müssen.

Nochmals herzlichen Dank für Eure Bemühungen und schöne Feiertage,
info103