Hallo an Alle,
ich habe Probleme mit der Firewall bei DENY-ALL Strategie an einem 1781VA Router:
Ich habe folgendes für einen REJECT unter "Actions-Objekte -> Action-Set" eingestellt:
-------------------------------------------------------------------------------------------------
Trigger:
0 ; kbit ; pro Sekunde ; Pro Session
Paket-Aktion: Zurückweisen
Sonstige Maßnahmen: SNMP + E-Mail-Nachricht senden
-------------------------------------------------------------------------------------------------
Laut "LANCOM Support Knowledgebase" gilt "Die Einstellung Pro Session und Global hat
bei einem Trigger Wert von 0 keine Auswirkung."
Nun stelle ich fest, dass öfters Pakete zurückgewiesen werden wie hier als Beispiel:
-------------------------------------------------------------------------------------------------
Date: 7/4/2013 13:41:30
The packet below
Src: 192.168.100.126:49759 {ich-pc} Dst: 178.236.4.85:843 (TCP)
MAC-Header (14 Bytes)
00 a0 57 1b a9 4a 00 25 22 7f 6a 61 08 00 | ..W..J.% ".ja..
IP-Packet (52 Bytes):
45 00 00 34 0f 75 40 00 80 06 0e e7 c0 a8 64 7e | E..4.u@. ......d~
b2 ec 04 55 c2 5f 03 4b 70 98 42 f1 00 00 00 00 | ...U._.K p.B.....
80 02 20 00 f9 79 00 00 02 04 05 b4 01 03 03 02 | .. ..y.. ........
01 01 04 02 | ....
matched this filter rule: DENY-ALL
and exceeded this limit: more than 0 kilobits transmitted or received on a connection during last second
because of this the actions below were performed:
reject
send SNMP trap
send email to administrator
-------------------------------------------------------------------------------------------------
Übrigens die IP: 178.236.4.85 gehört zum Amazone-Data-Service.
Also kann mit der Regel etwas nicht stimmen, nur weis ich nicht was...?
Vielleicht kann mir jemand auf die Sprünge helfen und mir das mal genauer erklären.
Vielen Dank
Cpuprofi
Hilfe!!! Probleme mit der Firewall bei DENY-ALL Strategie...
Moderator: Lancom-Systems Moderatoren
Re: Hilfe!!! Probleme mit der Firewall bei DENY-ALL Strategi
Hi cpuprofi,
wo ist dein Problem... es passiert doch genau das, was du konfiguriert hast: sobald ein Paket auf die Regel matcht, wird es verworfen...
oder hast du das
Diese Aussage bedeutet, daß es bei einem Triggerwert 0 völlig egal ist, was da sonst noch dransteht... 0 Pakete, 0 Kilobits pro Session oder global, alles völlig egal, weil der Trigger beim ersten übetragenen Bit zuschlägt....
Gruß
Backslash
wo ist dein Problem... es passiert doch genau das, was du konfiguriert hast: sobald ein Paket auf die Regel matcht, wird es verworfen...
oder hast du das
etwa falsch verstanden?Laut "LANCOM Support Knowledgebase" gilt "Die Einstellung Pro Session und Global hat
bei einem Trigger Wert von 0 keine Auswirkung."
Diese Aussage bedeutet, daß es bei einem Triggerwert 0 völlig egal ist, was da sonst noch dransteht... 0 Pakete, 0 Kilobits pro Session oder global, alles völlig egal, weil der Trigger beim ersten übetragenen Bit zuschlägt....
Gruß
Backslash
Re: Hilfe!!! Probleme mit der Firewall bei DENY-ALL Strategi
Hallo Backslash,
ich habe die Sache mit dem Trigger so verstanden, dass bei einem Trigger-Wert von 0 der Trigger ausgeschaltet ist.
Wobei ich nicht verstehe, wofür ich den Trigger bei einer Standart-Firewall-Einstellung benötige, ich mache ja keine Bandbreitenbeschränkung...?
Oder sehe ich das alles falsch?
Grüße
Cpuprofi
ich habe die Sache mit dem Trigger so verstanden, dass bei einem Trigger-Wert von 0 der Trigger ausgeschaltet ist.
Wobei ich nicht verstehe, wofür ich den Trigger bei einer Standart-Firewall-Einstellung benötige, ich mache ja keine Bandbreitenbeschränkung...?
Oder sehe ich das alles falsch?
Grüße
Cpuprofi
Re: Hilfe!!! Probleme mit der Firewall bei DENY-ALL Strategi
Hi cpuprofi,
bei Aktionen, die sofort ausgeführt werden, kannst du dir den Trigger auch sparen - deshalb haben die Default-Aktions-Objekte "ACCEPT", "REJECT" und "DROP" auch keinen Trigger. Aber spätestens, wenn du die Firewall mit LANconfig bearbeitest, wird LANconfig den 0-Trigger hinzufügen - es sei denn du nutzt die Default-Aktions-Objekte.
Intern macht das alles aber keinen Unterschied.
Gruß
Backslash
bei Aktionen, die sofort ausgeführt werden, kannst du dir den Trigger auch sparen - deshalb haben die Default-Aktions-Objekte "ACCEPT", "REJECT" und "DROP" auch keinen Trigger. Aber spätestens, wenn du die Firewall mit LANconfig bearbeitest, wird LANconfig den 0-Trigger hinzufügen - es sei denn du nutzt die Default-Aktions-Objekte.
Intern macht das alles aber keinen Unterschied.
Gruß
Backslash
Re: Hilfe!!! Probleme mit der Firewall bei DENY-ALL Strategi
Hallo Backslash,
ok, dann bin ich ja nicht ganz dumm
Aber wieso weist die Firewall die Pakete zurück? Ist doch ein Paket von innen ( Mein PC) nach außen (Amazon-Data-Server),k das sollte doch die Firewall automatisch (per Default) passieren dürfen.
Außerdem stellte ich fest, das VoIP-Pakete auch zurückgewiesen werden (von außen nach innen):
-------------------------------------------------------------------------------------------------
Date: 7/4/2013 16:18:46
The packet below
Src: 217.10.77.23:44067 Dst: 192.168.150.2:22235 {lancom1722} (UDP)
IP-Packet (96 Bytes):
45 00 00 60 00 00 40 00 36 11 c6 09 d9 0a 4d 17 | E..`..@. 6.....M.
c0 a8 96 02 ac 23 56 db 00 4c b9 c2 81 c8 00 0c | .....#V. .L......
55 f9 7c 73 d5 80 02 c6 9d 9f 94 d8 20 88 4d 78 | U.|s.... .... .Mx
00 00 3f 7a 00 27 ac 40 80 dd 54 c2 00 00 00 00 | ..?z.'.@ ..T.....
00 00 3f 6b 00 00 00 00 00 00 00 00 00 00 00 00 | ..?k.... ........
81 ca 00 03 55 f9 7c 73 01 04 53 4e 4f 4d 00 00 | ....U.|s ..SNOM..
matched this filter rule: DENY-ALL
and exceeded this limit: more than 0 kilobits transmitted or received on a connection during last second
because of this the actions below were performed:
reject
send SNMP trap
send email to administrator
-------------------------------------------------------------------------------------------------
Ich dachte der SIP-ALG vermerkt in der Firewall, das die VoIP-Paket passieren dürfen?
Grüße
Cpuprofi
ok, dann bin ich ja nicht ganz dumm
Aber wieso weist die Firewall die Pakete zurück? Ist doch ein Paket von innen ( Mein PC) nach außen (Amazon-Data-Server),k das sollte doch die Firewall automatisch (per Default) passieren dürfen.
Außerdem stellte ich fest, das VoIP-Pakete auch zurückgewiesen werden (von außen nach innen):
-------------------------------------------------------------------------------------------------
Date: 7/4/2013 16:18:46
The packet below
Src: 217.10.77.23:44067 Dst: 192.168.150.2:22235 {lancom1722} (UDP)
IP-Packet (96 Bytes):
45 00 00 60 00 00 40 00 36 11 c6 09 d9 0a 4d 17 | E..`..@. 6.....M.
c0 a8 96 02 ac 23 56 db 00 4c b9 c2 81 c8 00 0c | .....#V. .L......
55 f9 7c 73 d5 80 02 c6 9d 9f 94 d8 20 88 4d 78 | U.|s.... .... .Mx
00 00 3f 7a 00 27 ac 40 80 dd 54 c2 00 00 00 00 | ..?z.'.@ ..T.....
00 00 3f 6b 00 00 00 00 00 00 00 00 00 00 00 00 | ..?k.... ........
81 ca 00 03 55 f9 7c 73 01 04 53 4e 4f 4d 00 00 | ....U.|s ..SNOM..
matched this filter rule: DENY-ALL
and exceeded this limit: more than 0 kilobits transmitted or received on a connection during last second
because of this the actions below were performed:
reject
send SNMP trap
send email to administrator
-------------------------------------------------------------------------------------------------
Ich dachte der SIP-ALG vermerkt in der Firewall, das die VoIP-Paket passieren dürfen?
Grüße
Cpuprofi
Re: Hilfe!!! Probleme mit der Firewall bei DENY-ALL Strategi
Hi cpuprofi,
Gruß
Backslash
ich kenn deinen Regelsatz nicht, aber wenn du keine Regel hast, die den TCP-Zielport 843 durchläßt, dann ist es korrekt, daß die DENY-ALL-Regel anschlägt - siehe Ursprungs-Post: Src: 192.168.100.126:49759 {ich-pc} Dst: 178.236.4.85:843 (TCP)...Aber wieso weist die Firewall die Pakete zurück? Ist doch ein Paket von innen ( Mein PC) nach außen (Amazon-Data-Server).
das ist mit Sicherheit kein direktes VoIP-Paket (RTP), denn die haben immer gerade Portnummern - ungerade Nummern sind RTCP...Außerdem stellte ich fest, das VoIP-Pakete auch zurückgewiesen werden (von außen nach innen):
-------------------------------------------------------------------------------------------------
Date: 7/4/2013 16:18:46
The packet below
Src: 217.10.77.23:44067 Dst: 192.168.150.2:22235 {lancom1722} (UDP)
IP-Packet (96 Bytes):
45 00 00 60 00 00 40 00 36 11 c6 09 d9 0a 4d 17 | E..`..@. 6.....M.
c0 a8 96 02 ac 23 56 db 00 4c b9 c2 81 c8 00 0c | .....#V. .L......
55 f9 7c 73 d5 80 02 c6 9d 9f 94 d8 20 88 4d 78 | U.|s.... .... .Mx
00 00 3f 7a 00 27 ac 40 80 dd 54 c2 00 00 00 00 | ..?z.'.@ ..T.....
00 00 3f 6b 00 00 00 00 00 00 00 00 00 00 00 00 | ..?k.... ........
81 ca 00 03 55 f9 7c 73 01 04 53 4e 4f 4d 00 00 | ....U.|s ..SNOM..
matched this filter rule: DENY-ALL
and exceeded this limit: more than 0 kilobits transmitted or received on a connection during last second
because of this the actions below were performed:
reject
send SNMP trap
send email to administrator
-------------------------------------------------------------------------------------------------
zum SIP-ALG kann ich herzlich wenig sagen - außer, daß es Sessioneinträge für das Telefonat erstellt und Bandbreiten reserviert. Ob es RTCP korrekt behandelt, weiss ich nicht.Ich dachte der SIP-ALG vermerkt in der Firewall, das die VoIP-Paket passieren dürfen?
Gruß
Backslash
Re: Hilfe!!! Probleme mit der Firewall bei DENY-ALL Strategi
Hallo Backslash,
Ok, danke für die Aufklärung, das wusste ich noch nicht. Gibt es denn eine Lösung (außer SIP-ALG), dass die RTP und RTCP-Pakete passieren dürfen? Denn auch Pakete mit geraden Portnummern wurden zurückgewiesen:
-------------------------------------------------------------------------------------------------
Date: 7/4/2013 16:26:03
The packet below
Src: 217.10.77.23:44066 Dst: 192.168.150.2:22234 {lancom1722} (UDP)
IP-Packet (128 Bytes):
45 00 00 c8 00 00 40 00 36 11 c5 a1 d9 0a 4d 17 | E.....@. 6.....M.
c0 a8 96 02 ac 22 56 da 00 b4 d2 75 80 08 e5 4a | ....."V. ...u...J
20 bd a5 18 55 f9 7c 73 55 55 55 d5 55 55 d5 d5 | ...U.|s UUU.UU..
d4 d5 d5 55 d5 55 54 54 54 54 54 54 54 54 54 54 | ...U.UTT TTTTTTTT
54 54 54 55 d5 55 d5 d5 d4 d5 d5 d5 55 55 55 55 | TTTU.U.. ....UUUU
55 d5 d5 d5 55 d5 d5 d5 d5 d5 55 55 54 55 54 54 | U...U... ..UUTUTT
55 d5 55 d5 55 d5 d5 d5 d5 d4 d5 d5 55 55 55 d5 | U.U.U... ....UUU.
d5 55 d5 55 d5 55 54 55 55 d5 55 d5 d5 d5 d5 d5 | .U.U.UTU U.U.....
matched this filter rule: DENY-ALL
and exceeded this limit: more than 0 kilobits transmitted or received on a connection during last second
because of this the actions below were performed:
reject
send SNMP trap
send email to administrator
-------------------------------------------------------------------------------------------------
Gruß
Cpuprofi
Ok, da muß ich nochmal meine ganzen Regeln durchschauen, was da falsch ist....aber wenn du keine Regel hast, die den TCP-Zielport 843 durchläßt, dann ist es korrekt, daß die DENY-ALL-Regel anschlägt...
...das ist mit Sicherheit kein direktes VoIP-Paket (RTP), denn die haben immer gerade Portnummern - ungerade Nummern sind RTCP...
Ok, danke für die Aufklärung, das wusste ich noch nicht. Gibt es denn eine Lösung (außer SIP-ALG), dass die RTP und RTCP-Pakete passieren dürfen? Denn auch Pakete mit geraden Portnummern wurden zurückgewiesen:
-------------------------------------------------------------------------------------------------
Date: 7/4/2013 16:26:03
The packet below
Src: 217.10.77.23:44066 Dst: 192.168.150.2:22234 {lancom1722} (UDP)
IP-Packet (128 Bytes):
45 00 00 c8 00 00 40 00 36 11 c5 a1 d9 0a 4d 17 | E.....@. 6.....M.
c0 a8 96 02 ac 22 56 da 00 b4 d2 75 80 08 e5 4a | ....."V. ...u...J
20 bd a5 18 55 f9 7c 73 55 55 55 d5 55 55 d5 d5 | ...U.|s UUU.UU..
d4 d5 d5 55 d5 55 54 54 54 54 54 54 54 54 54 54 | ...U.UTT TTTTTTTT
54 54 54 55 d5 55 d5 d5 d4 d5 d5 d5 55 55 55 55 | TTTU.U.. ....UUUU
55 d5 d5 d5 55 d5 d5 d5 d5 d5 55 55 54 55 54 54 | U...U... ..UUTUTT
55 d5 55 d5 55 d5 d5 d5 d5 d4 d5 d5 55 55 55 d5 | U.U.U... ....UUU.
d5 55 d5 55 d5 55 54 55 55 d5 55 d5 d5 d5 d5 d5 | .U.U.UTU U.U.....
matched this filter rule: DENY-ALL
and exceeded this limit: more than 0 kilobits transmitted or received on a connection during last second
because of this the actions below were performed:
reject
send SNMP trap
send email to administrator
-------------------------------------------------------------------------------------------------
Gruß
Cpuprofi
Re: Hilfe!!! Probleme mit der Firewall bei DENY-ALL Strategi
Hi cpuprofi,
ich schätze mal, du hat für VoIP eine Regel der Form:
erstellt. Das Problem mit dieser Regel ist, daß sie auf Antworten ohne DSCP EF nicht matcht und das Paket dummerweise dann in die Deny-All-Regel läuft, obwohl die Regel beim abgehenden Paket gematcht hat... Das ist ein Bug, der mit der nächsten Firmware gefixt ist...
Du kannst dir helfen, din dem du als Quelle "alls Stationen im lokalen Netz" einträgst und in der Aktion die Bedingung "DSCP = EF" wegläßt, also
Dann matcht auch eine Antwort, die kein EF gesetzt hat, auf die Session. Leider erlaubt diese Regel allen abgehenden UDP-Traffic... Daher ist die Nutzung des SIP-ALG eigentlich die bessere Variante - so das SIP-ALG auch wirklich alles richtig macht...
Bei RTCP solltest du darauf achten, daß du dessen Pakete nicht mit EF markierst, denn sonst belegt obige Regel die doppelte Bandbreite. Markier RTCP z.B. mit AF11 und erstell eine Regel die daraufhin triggert:
Noch schöner wäre es, wenn du am Telefon einstellen kannst, welche Ports es für RTP und RTPC nutzt, denn dann kannst du diese Ports als Quell-Ports in die Regeln einbauen - was zumindest das Loch in der Firewall deulich verkleinert.
Gruß
Guido
ich schätze mal, du hat für VoIP eine Regel der Form:
Code: Alles auswählen
Aktion: Übertragen, wenn DSCP = EF
QoS: Mindsetbandbreite, wenn DSCP = EF
Quelle alle Stationen
Ziel alle Stationen
Dienste: UDPDu kannst dir helfen, din dem du als Quelle "alls Stationen im lokalen Netz" einträgst und in der Aktion die Bedingung "DSCP = EF" wegläßt, also
Code: Alles auswählen
Aktion: Übertragen
QoS: Mindsetbandbreite, wenn DSCP = EF
Quelle alle Stationen im lokalen Netz - oder noch besser: IP deines Telefons
Ziel alle Stationen
Dienste: UDPBei RTCP solltest du darauf achten, daß du dessen Pakete nicht mit EF markierst, denn sonst belegt obige Regel die doppelte Bandbreite. Markier RTCP z.B. mit AF11 und erstell eine Regel die daraufhin triggert:
Code: Alles auswählen
Aktion: Übertragen
QoS: Mindsetbandbreite, wenn DSCP = AF11
Quelle alle Stationen im lokalen Netz - oder noch besser: IP deines Telefons
Ziel alle Stationen
Dienste: UDPGruß
Guido
Re: Hilfe!!! Probleme mit der Firewall bei DENY-ALL Strategi
Hallo Backslash,
die Idee mit DiffServ (DSCP) ist gut, hatte ich zwar auch schon mal daran gedacht, aber noch nicht ausprobiert, könnte ich ja mal machen.
Vielleicht sollte mal der SIP-ALG Entwickler nochmal ein paar Stunden an einer Verbesserung arbeiten, kannst ja mal an die zuständige Person so weiter geben.
Tja, da haben wir ein anderes Problem... die Firma Dus.net (als einer der genutzten Provider) sagt folgendes zu den genutzten Ports:
-------------------------------------------------------------------------------------------------
IP-Adressen und verwendete Ports unserer Systeme für Ihre Firewall regeln.
Server Dienst Server IP Protokoll Ports von-bis
SIP Server 83.125.8.71 TCP+UDP 5060-5061
RTP Media-Relay 83.125.8.150 UDP 10000-65535
-------------------------------------------------------------------------------------------------
Ich denke mal ein noch größeres Loch in der Firewall gibt es dann kaum, außer gar keine Firewall.
Viele Grüße
Cpuprofi
die Idee mit DiffServ (DSCP) ist gut, hatte ich zwar auch schon mal daran gedacht, aber noch nicht ausprobiert, könnte ich ja mal machen.
Im Moment ist im 1781VA für die Klassifizierung und Bandbreitenregelung des VoIP-Verkehrs alleinig der SIP-ALG zuständig, aber diese Aufgabe erledigt er nachweislich (!) nicht korrekt.Daher ist die Nutzung des SIP-ALG eigentlich die bessere Variante - so das SIP-ALG auch wirklich alles richtig macht...
Vielleicht sollte mal der SIP-ALG Entwickler nochmal ein paar Stunden an einer Verbesserung arbeiten, kannst ja mal an die zuständige Person so weiter geben.
Noch schöner wäre es, wenn du am Telefon einstellen kannst, welche Ports es für RTP und RTPC nutzt, denn dann kannst du diese Ports als Quell-Ports in die Regeln einbauen - was zumindest das Loch in der Firewall deulich verkleinert.
Tja, da haben wir ein anderes Problem... die Firma Dus.net (als einer der genutzten Provider) sagt folgendes zu den genutzten Ports:
-------------------------------------------------------------------------------------------------
IP-Adressen und verwendete Ports unserer Systeme für Ihre Firewall regeln.
Server Dienst Server IP Protokoll Ports von-bis
SIP Server 83.125.8.71 TCP+UDP 5060-5061
RTP Media-Relay 83.125.8.150 UDP 10000-65535
-------------------------------------------------------------------------------------------------
Ich denke mal ein noch größeres Loch in der Firewall gibt es dann kaum, außer gar keine Firewall.
Viele Grüße
Cpuprofi
Re: Hilfe!!! Probleme mit der Firewall bei DENY-ALL Strategi
Hi cpuprofi,
Und wenn deine Telefone das RTP-Media-Relay nutzen, dann ist das Loch auch nicht wirklich groß, denn du hast ja eine IP-Adresse, die du in den Regeln verwenden kannst (OK für die mußt du dann alle Ports öffnen, aber eben nur für die eine Adresse...)
Gruß
Backslash
da rennst du aber in das Problem, daß die Internet-Provider mittlerweile DiffServ-Tags löschen und du somit bei den RTP-Antworten in den genannten Bug rennst...die Idee mit DiffServ (DSCP) ist gut, hatte ich zwar auch schon mal daran gedacht, aber noch nicht ausprobiert, könnte ich ja mal machen.
Das Problem dürften dabei aber die konkreten Fehler sein - ihm einfach nur zu sagen: "schau mal ins Lancom-Forum, da gibt es jede Menge Meldungen zum SIP-ALG" hilft nicht wirklich weiter...Im Moment ist im 1781VA für die Klassifizierung und Bandbreitenregelung des VoIP-Verkehrs alleinig der SIP-ALG zuständig, aber diese Aufgabe erledigt er nachweislich (!) nicht korrekt.
Vielleicht sollte mal der SIP-ALG Entwickler nochmal ein paar Stunden an einer Verbesserung arbeiten, kannst ja mal an die zuständige Person so weiter geben.
ich meinte deine Telefone, nicht den SIP-Provider. Schließlich wählt das Telefon aus, auf welchem Port es die RTP-Pakete der Gegenseite erwartet. Wenn du diesen Port als Quellport zusammen mit der IP-Adresse des Telefons als Quell-Adresse in der Regel verwendest, ist das Loch nicht allzu groß. Die RTCP-Pakete kommen auf dem darauf folgenden Port.Noch schöner wäre es, wenn du am Telefon einstellen kannst, welche Ports es für RTP und RTPC nutzt, denn dann kannst du diese Ports als Quell-Ports in die Regeln einbauen - was zumindest das Loch in der Firewall deulich verkleinert.
Tja, da haben wir ein anderes Problem... die Firma Dus.net (als einer der genutzten Provider) sagt folgendes zu den genutzten Ports:
-------------------------------------------------------------------------------------------------
IP-Adressen und verwendete Ports unserer Systeme für Ihre Firewall regeln.
Server Dienst Server IP Protokoll Ports von-bis
SIP Server 83.125.8.71 TCP+UDP 5060-5061
RTP Media-Relay 83.125.8.150 UDP 10000-65535
-------------------------------------------------------------------------------------------------
Ich denke mal ein noch größeres Loch in der Firewall gibt es dann kaum, außer gar keine Firewall.
Und wenn deine Telefone das RTP-Media-Relay nutzen, dann ist das Loch auch nicht wirklich groß, denn du hast ja eine IP-Adresse, die du in den Regeln verwenden kannst (OK für die mußt du dann alle Ports öffnen, aber eben nur für die eine Adresse...)
Gruß
Backslash
Re: Hilfe!!! Probleme mit der Firewall bei DENY-ALL Strategi
Hallo Backslash,
erstmal Danke für Deine Unterstützung! Werde das mal austesten. Das einzige Problem ist, das ich hier nicht nur einen SIP-Provider und nur ein Telefon habe... sondern 12 verschiedene Provider mit zig Accounts und zig Telefone...
Grüße
Cpuprofi
erstmal Danke für Deine Unterstützung! Werde das mal austesten. Das einzige Problem ist, das ich hier nicht nur einen SIP-Provider und nur ein Telefon habe... sondern 12 verschiedene Provider mit zig Accounts und zig Telefone...
Bitte teile mir doch mal mit, wenn Du den Bug gefixt hast.da rennst du aber in das Problem, daß die Internet-Provider mittlerweile DiffServ-Tags löschen und du somit bei den RTP-Antworten in den genannten Bug rennst...
Ok, ich mache mal ein Support-Ticket wegen der Problematik auf, mal sehen wann ich eine Antwort bekomme.Das Problem dürften dabei aber die konkreten Fehler sein - ihm einfach nur zu sagen: "schau mal ins Lancom-Forum, da gibt es jede Menge Meldungen zum SIP-ALG" hilft nicht wirklich weiter...
Grüße
Cpuprofi
Re: Hilfe!!! Probleme mit der Firewall bei DENY-ALL Strategi
Hallo Backslash,
ich habe eben gesehen, das die Firewall auch internen Datenverkehr zurückweist...?
Ich dachte bei internen Datenaustausch in lokalen Netz (in diesem Fall ist dass das Intranet:192.168.100.x) greift die Firewall nicht ein. Oder liege ich da falsch?
-------------------------------------------------------------------------------------------------
Date: 7/5/2013 18:21:29
The packet below
Src: 192.168.100.249:40060 {diskstation} Dst: 192.168.100.126:55865 {ich-pc} (UDP)
MAC-Header (14 Bytes)
00 a0 57 1b a9 4a 00 11 32 12 40 b6 08 00 | ..W..J.. 2.@...
IP-Packet (128 Bytes):
45 00 01 99 00 00 40 00 40 11 ee 8b c0 a8 64 f9 | E.....@. @.....d.
c0 a8 64 7e 9c 7c da 39 01 85 fd 5d 48 54 54 50 | ..d~.|.9 ...]HTTP
2f 31 2e 31 20 32 30 30 20 4f 4b 0d 0a 43 41 43 | /1.1 200 OK..CAC
48 45 2d 43 4f 4e 54 52 4f 4c 3a 20 6d 61 78 2d | HE-CONTR OL: max-
61 67 65 3d 31 39 30 30 0d 0a 44 41 54 45 3a 20 | age=1900 ..DATE:
46 72 69 2c 20 30 35 20 4a 75 6c 20 32 30 31 33 | Fri, 05 Jul 2013
20 31 36 3a 32 32 3a 33 35 20 47 4d 54 0d 0a 45 | 16:22:3 5 GMT..E
58 54 3a 0d 0a 4c 4f 43 41 54 49 4f 4e 3a 20 68 | XT:..LOC ATION: h
matched this filter rule: DENY-ALL
and exceeded this limit: more than 0 kilobits transmitted or received on a connection during last second
because of this the actions below were performed:
reject
send SNMP trap
send email to administrator
-------------------------------------------------------------------------------------------------
Grüße
Cpuprofi
ich habe eben gesehen, das die Firewall auch internen Datenverkehr zurückweist...?
Ich dachte bei internen Datenaustausch in lokalen Netz (in diesem Fall ist dass das Intranet:192.168.100.x) greift die Firewall nicht ein. Oder liege ich da falsch?
-------------------------------------------------------------------------------------------------
Date: 7/5/2013 18:21:29
The packet below
Src: 192.168.100.249:40060 {diskstation} Dst: 192.168.100.126:55865 {ich-pc} (UDP)
MAC-Header (14 Bytes)
00 a0 57 1b a9 4a 00 11 32 12 40 b6 08 00 | ..W..J.. 2.@...
IP-Packet (128 Bytes):
45 00 01 99 00 00 40 00 40 11 ee 8b c0 a8 64 f9 | E.....@. @.....d.
c0 a8 64 7e 9c 7c da 39 01 85 fd 5d 48 54 54 50 | ..d~.|.9 ...]HTTP
2f 31 2e 31 20 32 30 30 20 4f 4b 0d 0a 43 41 43 | /1.1 200 OK..CAC
48 45 2d 43 4f 4e 54 52 4f 4c 3a 20 6d 61 78 2d | HE-CONTR OL: max-
61 67 65 3d 31 39 30 30 0d 0a 44 41 54 45 3a 20 | age=1900 ..DATE:
46 72 69 2c 20 30 35 20 4a 75 6c 20 32 30 31 33 | Fri, 05 Jul 2013
20 31 36 3a 32 32 3a 33 35 20 47 4d 54 0d 0a 45 | 16:22:3 5 GMT..E
58 54 3a 0d 0a 4c 4f 43 41 54 49 4f 4e 3a 20 68 | XT:..LOC ATION: h
matched this filter rule: DENY-ALL
and exceeded this limit: more than 0 kilobits transmitted or received on a connection during last second
because of this the actions below were performed:
reject
send SNMP trap
send email to administrator
-------------------------------------------------------------------------------------------------
Grüße
Cpuprofi
Re: Hilfe!!! Probleme mit der Firewall bei DENY-ALL Strategi
Hallo Backslash,
noch zur Ergänzung des Verhaltens (Bug?) der Firewall im Lancom 1781VA (8.82.0067-RC2), dass auch interne Datenpakete verworfen werden:
Lokales NAS (diskstation) mit IP 192.168.100.249 sendet Pakete über den Lancom 1781VA an lokalem PC (ich-pc) mit 192.168.100.126, von denen manche von der Firewall verworfen werden, andere werden direkt an den PC gesendet, sonst könnte ich ja gar nicht auf das NAS zugreifen.
Der ARP-Proxy im LANCOM ist aktiv (entfernte Stationen mit Proxy-ARP einbinden) und der IP-Adressbereich für Einwahl-Zugänge ist zwischen 192.168.100.101-192.168.100.125.
Warum sendet das NAS den Paket über den Lancom zum PC? Ist doch alles nur intern und keine externe Verbindung oder VPN?
Vielen Dank für eine Antwort
Cpuprofi
noch zur Ergänzung des Verhaltens (Bug?) der Firewall im Lancom 1781VA (8.82.0067-RC2), dass auch interne Datenpakete verworfen werden:
Lokales NAS (diskstation) mit IP 192.168.100.249 sendet Pakete über den Lancom 1781VA an lokalem PC (ich-pc) mit 192.168.100.126, von denen manche von der Firewall verworfen werden, andere werden direkt an den PC gesendet, sonst könnte ich ja gar nicht auf das NAS zugreifen.
Der ARP-Proxy im LANCOM ist aktiv (entfernte Stationen mit Proxy-ARP einbinden) und der IP-Adressbereich für Einwahl-Zugänge ist zwischen 192.168.100.101-192.168.100.125.
Warum sendet das NAS den Paket über den Lancom zum PC? Ist doch alles nur intern und keine externe Verbindung oder VPN?
Vielen Dank für eine Antwort
Cpuprofi
Re: Hilfe!!! Probleme mit der Firewall bei DENY-ALL Strategi
Hi cpuprofi,
normalerewise greift die Fierwall in lokalen Traffic nicht ein, weil dieser gar nicht am LANCOM vorebei kommt - die Beteiligten reden direkt miteinander. Wenn aber einer der Beteiligten seine Pakete an das LANCOM schgickt, dann greifen auch die Regeln der Firewall... Aber selbst, wenn du jetzt eine Allow-Regel dafür erstellen würdest, würde es dir nicht viel weiterhelfen, denn spätestens der Router würde das Paket mit einem "back route error" verwerfen...
Warum das NAS die Pakete an das lANCOM schickt, kann ich dir nicht sagen, es sollte es nicht machen - es sei denn du hättest eine Route, die die Adresse dieses PC auf eine WAN-Verbindung weiterleitet (=> Stichwort Proxy-ARP). Oder du hats auf dem NAS eine Route eingetragen, die diese Adresse über das LANCOM leitet. Oder, oder, oder...
Du solltest dir deinen Aufbau mal ganz genau anschauen.
Gruß
Backslash
normalerewise greift die Fierwall in lokalen Traffic nicht ein, weil dieser gar nicht am LANCOM vorebei kommt - die Beteiligten reden direkt miteinander. Wenn aber einer der Beteiligten seine Pakete an das LANCOM schgickt, dann greifen auch die Regeln der Firewall... Aber selbst, wenn du jetzt eine Allow-Regel dafür erstellen würdest, würde es dir nicht viel weiterhelfen, denn spätestens der Router würde das Paket mit einem "back route error" verwerfen...
Warum das NAS die Pakete an das lANCOM schickt, kann ich dir nicht sagen, es sollte es nicht machen - es sei denn du hättest eine Route, die die Adresse dieses PC auf eine WAN-Verbindung weiterleitet (=> Stichwort Proxy-ARP). Oder du hats auf dem NAS eine Route eingetragen, die diese Adresse über das LANCOM leitet. Oder, oder, oder...
Du solltest dir deinen Aufbau mal ganz genau anschauen.
Gruß
Backslash