Ich habe die Firmware 7.60 RC1 auf dem 3850UMTS getestet.
1.
Das wählbare Sessionlimit in der Firewall funktioniert sehr gut!
2.
Leider spinnt der Rest der Firewall sehr.
Alle einstellungen wurden immer mit dem Lanconfig gemacht.
Webintercace benutzte ich nicht.
Bei mehreren Regeln nacheinander wird zb das zurückweisen nicht ausgeführt.
zb.
1. Regel Sessionlimit pro IP (weitere beachten ein)
2. Regel Web,E-Mail,DNS und ICMP erlauben
3. Regel Den Rest verwerfen
Trotzdem waren alle Ports offen!
Also alte Firmware wieder drauf (7.58)
Alle Regeln gelöscht neu eingetragen und gehen dann wieder.
dann zurückschalten zur neuen Firmware und alle Ports sind wieder offen Ohne nur einen eintrag in der Firewall geändert zu haben.
Habe jetzt die alte Firmware draufgelassen.
LCOS 7.60 RC1 Firewall arbeitet nicht richtig
Moderator: Lancom-Systems Moderatoren
Hi ThomasL,
an der Firewall hat sich nichts geändert - außer daß die Session-Limits und pro User-Limits hinzugekommen sind.
Die wirklich Große Änderung (Nutzung der Objekt- und Aktionsliste in der Form, in der sie von Anfang an gedacht waren) ist nur im LANconfig.
Gib doch einfach mal im Telnet show filter ein
Gruß
Backslash
an der Firewall hat sich nichts geändert - außer daß die Session-Limits und pro User-Limits hinzugekommen sind.
Die wirklich Große Änderung (Nutzung der Objekt- und Aktionsliste in der Form, in der sie von Anfang an gedacht waren) ist nur im LANconfig.
Gib doch einfach mal im Telnet show filter ein
Gruß
Backslash
@backslash
Ich habe dir die Telnetausgabe per PN zugeschickt
Sobald eine Regel mit Markieren drin ist werden keine weiteren Regeln beachtet. (In der 7.58 noch OK)
Filter 0005 from Rule LIMIT:
Protocol: 0
Src: 00:00:00:00:00:00 0.0.0.0 0.0.0.0 0-0
Dst: 00:00:00:00:00:00 0.0.0.0 0.0.0.0 0-0
use routing tag 0000
combine actions with next matching filter
conditional: if on default route
Limit per conn.: after transmitting or receiving of 4000 kilobits
actions after exceeding the limit:
accept
set DiffServ to 0x3c
---
conditional: if on default route
Limit per user: after transmitting or receiving of 160000 kilobits per hour
actions after exceeding the limit:
accept
set DiffServ to 0x3c
----------->wird nicht mehr beachtet<----------
Filter 0006 from Rule MAX:
Protocol: 0
Src: 00:00:00:00:00:00 0.0.0.0 0.0.0.0 0-0
Dst: 00:00:00:00:00:00 0.0.0.0 0.0.0.0 0-0
use routing tag 0000
combine actions with next matching filter
conditional: if on default route and DSCP == 60
Limit per conn.: after transmitting or receiving of 0 kilobits per second
actions after exceeding the limit:
drop
usw.....
Ich habe dir die Telnetausgabe per PN zugeschickt
Sobald eine Regel mit Markieren drin ist werden keine weiteren Regeln beachtet. (In der 7.58 noch OK)
Filter 0005 from Rule LIMIT:
Protocol: 0
Src: 00:00:00:00:00:00 0.0.0.0 0.0.0.0 0-0
Dst: 00:00:00:00:00:00 0.0.0.0 0.0.0.0 0-0
use routing tag 0000
combine actions with next matching filter
conditional: if on default route
Limit per conn.: after transmitting or receiving of 4000 kilobits
actions after exceeding the limit:
accept
set DiffServ to 0x3c
---
conditional: if on default route
Limit per user: after transmitting or receiving of 160000 kilobits per hour
actions after exceeding the limit:
accept
set DiffServ to 0x3c
----------->wird nicht mehr beachtet<----------
Filter 0006 from Rule MAX:
Protocol: 0
Src: 00:00:00:00:00:00 0.0.0.0 0.0.0.0 0-0
Dst: 00:00:00:00:00:00 0.0.0.0 0.0.0.0 0-0
use routing tag 0000
combine actions with next matching filter
conditional: if on default route and DSCP == 60
Limit per conn.: after transmitting or receiving of 0 kilobits per second
actions after exceeding the limit:
drop
usw.....
Hi ThomasL
ich sg's mal so: Es wurde niemals garantiert, daß das in dieser Form funktioniert (obwohl ich keinen Grund darin sehe, warum es nicht funktionieren sollte)...
Trotzdem: Wieso wirfst du in der Regel LIMIT nicht einfach die Pakete weg, statt sie zu markieren um sie dann erst in der nächsten Regel (MAX) auf diese Markierung hin zu verwerfen
BTW: Bei der Markierung ist auch in der 7.58 ein Bug drin... Wenn bereits markierte Pakete empfangen werden, dann wird der DSCP nicht gesetzt, sondern hereingeODERt
Gruß
Backslash
ich sg's mal so: Es wurde niemals garantiert, daß das in dieser Form funktioniert (obwohl ich keinen Grund darin sehe, warum es nicht funktionieren sollte)...
Trotzdem: Wieso wirfst du in der Regel LIMIT nicht einfach die Pakete weg, statt sie zu markieren um sie dann erst in der nächsten Regel (MAX) auf diese Markierung hin zu verwerfen
BTW: Bei der Markierung ist auch in der 7.58 ein Bug drin... Wenn bereits markierte Pakete empfangen werden, dann wird der DSCP nicht gesetzt, sondern hereingeODERt
Gruß
Backslash
Die verbindung soll nicht abgebrochen werden sondern langsam weiter laufen.
Ich habe bei UMTS nur 5Gb im Monat. Wenn ich jemanden über meinen Anschluss mitsurfen lasse darf derjenige keine grossen Downloads machen aber zb. Windowsupdates sollen(langsam) durchlaufen. Hat bis jetzt auch immer funktioniert. Und wenn eine markierung reicht damit ein Packet ungehindert durch die Firewall kann. (geht das auch, wenn schon der Windows PC Packete markiert?).
Da hat sich die beta gelohnt(1Fehler weniger in der Final?)
Ich habe bei UMTS nur 5Gb im Monat. Wenn ich jemanden über meinen Anschluss mitsurfen lasse darf derjenige keine grossen Downloads machen aber zb. Windowsupdates sollen(langsam) durchlaufen. Hat bis jetzt auch immer funktioniert. Und wenn eine markierung reicht damit ein Packet ungehindert durch die Firewall kann. (geht das auch, wenn schon der Windows PC Packete markiert?).
Da hat sich die beta gelohnt(1Fehler weniger in der Final?)
Hi ThomasL,
ich habe das gerade mal ausprobiert - und ja: es funktioniert tatsächlich nicht... Es funktioniert aber auch mit früheren Firmwaren genau so wenig...
Das Problem sind die bedingten Aktionen in der Regelkette. Wenn in der ersten Regel eine Bedingung zutraf, dann wird nie wieder eine unbedingte Aktion ausgeführt - auch nicht bei der letzen Regel.
Als Workarround kannst du bis zur nächsten Firmware in der Deny-All-Regel zusätzlich zu unbedingten "Reject" noch ein zusätzliches "Reject" mit der Bedingung "nur auf Default-Route" aufnehmen - dann wird es funktionieren
Gruß
Backslash
ich habe das gerade mal ausprobiert - und ja: es funktioniert tatsächlich nicht... Es funktioniert aber auch mit früheren Firmwaren genau so wenig...
Das Problem sind die bedingten Aktionen in der Regelkette. Wenn in der ersten Regel eine Bedingung zutraf, dann wird nie wieder eine unbedingte Aktion ausgeführt - auch nicht bei der letzen Regel.
Als Workarround kannst du bis zur nächsten Firmware in der Deny-All-Regel zusätzlich zu unbedingten "Reject" noch ein zusätzliches "Reject" mit der Bedingung "nur auf Default-Route" aufnehmen - dann wird es funktionieren
Gruß
Backslash
