Hallo Leute,
Hab ein kleines Problemchen bei meiner Test Securepoint Zuhause.
Hab auf eth1 folgende IP's angelegt:
=> 10.10.0.0/24
=> 10.10.1.0/24
=> 10.10.2.0/24
Möchte gerne eine NAS mit der IP 10.10.0.200/32 erwischen.
aus dem 10.10.0.0/24 => natürlich kein Problem
aus den beiden anderen Netzen komme ich nicht hin !? :?
Regelwerk sollte soweit passen => ANY in jeweils beide Richtungen der Netze!
Hab ich noch was vergessen???
Schönen Dank schon mal!
Gruss
Rene
Problem // Virtuelle IP's auf einem Interface
Moderator: Securepoint
Problem // Virtuelle IP's auf einem Interface
Opinions are like watches. Everyone\'s watch shows different time from others. But, Every one believes that their time is CORRECT...
Hier noch ein kleiner Auszug aus dem Log:
Firewall DROP
IN=eth1 OUT=eth1 SRC=10.10.1.50 DST=10.10.0.200 LEN=566 TOS=0x00 PREC=0x00 TTL=63 ID=2675 DF PROTO=TCP SPT=49225 DPT=8081 WINDOW=65535 RES=0x00 ACK PSH FIN URGP=0
...verstehe nicht das die FW DROPT, obwohl im Regelwerk alles freigeschaltet ist ???
Firewall DROP
IN=eth1 OUT=eth1 SRC=10.10.1.50 DST=10.10.0.200 LEN=566 TOS=0x00 PREC=0x00 TTL=63 ID=2675 DF PROTO=TCP SPT=49225 DPT=8081 WINDOW=65535 RES=0x00 ACK PSH FIN URGP=0
...verstehe nicht das die FW DROPT, obwohl im Regelwerk alles freigeschaltet ist ???
Opinions are like watches. Everyone\'s watch shows different time from others. But, Every one believes that their time is CORRECT...
Guten Morgen,
sehen Sie noch DROPs vor dem Auszug von oben? In Ihrem letzten Post ist lediglich der Verbindungsabbau zu sehen.
Stellen Sie unter Netzwerk -> Aplliance-Einstellungen das Default-Logging auf "Long". Das Gleiche machen Sie für die Regel, die den Traffic von 10.10.1.0/24 nach 10.10.0.0/24 erlaubt. Jetzt sehen Sie im Livelog auch den Verbindungsaufbau(-versuch).
Sollten Sie sicher sein, dass alle Zonen in den Netzwerkobjekten korrekt sind, erstellen Sie einen Dienst und nennen ihn "any-stateless" (Protokoll: ip). Den packen Sie dann in eine eigene Dienstgruppe (am besten ebenfalls "any-stateless") und bauen ihre Regeln dann mit dieser Dienstgruppe.
Jetzt lässt die Firewall auch Verbindungen zu, die nicht vollständig bei ihr ankommen.
Sollte das immernoch nicht gehen, würde ich Sie bitten sich einmal telefonisch bei uns zu melden, sodass wir uns das Gerät mal live anschauen können. Sie erreichen uns von 08 Uhr bis 18 Uhr unter der Nummer: 0049 4131 24010
sehen Sie noch DROPs vor dem Auszug von oben? In Ihrem letzten Post ist lediglich der Verbindungsabbau zu sehen.
Stellen Sie unter Netzwerk -> Aplliance-Einstellungen das Default-Logging auf "Long". Das Gleiche machen Sie für die Regel, die den Traffic von 10.10.1.0/24 nach 10.10.0.0/24 erlaubt. Jetzt sehen Sie im Livelog auch den Verbindungsaufbau(-versuch).
Sollten Sie sicher sein, dass alle Zonen in den Netzwerkobjekten korrekt sind, erstellen Sie einen Dienst und nennen ihn "any-stateless" (Protokoll: ip). Den packen Sie dann in eine eigene Dienstgruppe (am besten ebenfalls "any-stateless") und bauen ihre Regeln dann mit dieser Dienstgruppe.
Jetzt lässt die Firewall auch Verbindungen zu, die nicht vollständig bei ihr ankommen.
Sollte das immernoch nicht gehen, würde ich Sie bitten sich einmal telefonisch bei uns zu melden, sodass wir uns das Gerät mal live anschauen können. Sie erreichen uns von 08 Uhr bis 18 Uhr unter der Nummer: 0049 4131 24010
Hallo,
Vorerst mal schönen Dank für die schnelle Antwort.
Das Logging kann ich erst später nachreichen wenn ich im HomeOffice bin.
Zu den Zonen => sind bei eth1 (internal , firewall-internal) und somit auch bei allen Virtuellen IP's, da NICHT physikalisch getrennt!
Werde das mit der stateless Dienstegruppe probieren,.. /*denke laut* scheint mir auch plausibel.. da, wie schon oben erwähnt nur eine Logische Trennung der Netze eingerichtet ist. Somit wäre es möglich das die Firewall einige Packete nicht sieht, da eine direkte Kommunikation der Akteure NAS & Client (über MAC-Adresse) möglich ist...*denk Fehler* ? :roll:
Auf jeden Fall nochmal Danke,.. bis später!
Gruss
Rene
Vorerst mal schönen Dank für die schnelle Antwort.
Das Logging kann ich erst später nachreichen wenn ich im HomeOffice bin.
Zu den Zonen => sind bei eth1 (internal , firewall-internal) und somit auch bei allen Virtuellen IP's, da NICHT physikalisch getrennt!
Werde das mit der stateless Dienstegruppe probieren,.. /*denke laut* scheint mir auch plausibel.. da, wie schon oben erwähnt nur eine Logische Trennung der Netze eingerichtet ist. Somit wäre es möglich das die Firewall einige Packete nicht sieht, da eine direkte Kommunikation der Akteure NAS & Client (über MAC-Adresse) möglich ist...*denk Fehler* ? :roll:
Auf jeden Fall nochmal Danke,.. bis später!
Gruss
Rene
Zuletzt geändert von rene am Di 21.07.2009, 10:10, insgesamt 1-mal geändert.
Opinions are like watches. Everyone\'s watch shows different time from others. But, Every one believes that their time is CORRECT...
Hallo nochmal,...
mit dem "any-stateless" Dienst funzt es ??! :?
Ist von der Config ident (bis auf Bezeichnung) mit dem Default ANY Dienst, bitte um Aufklärung :shock:
gruss
Rene
mit dem "any-stateless" Dienst funzt es ??! :?
Ist von der Config ident (bis auf Bezeichnung) mit dem Default ANY Dienst, bitte um Aufklärung :shock:
gruss
Rene
Opinions are like watches. Everyone\'s watch shows different time from others. But, Every one believes that their time is CORRECT...
Guten Abend,
der TCP-Verbindungsaufbau geschieht in drei Schritten:
1: A schickt ein SYN an B
2: B antworter A mit SYN+ACK
3: A bestätigt den Erhalt dieses Paketes bei B mit einem einfachen ACK
Standardmäßig hat die Securepoint jetzt eine sogenannte "Stateful Packet Inspection" kurz SPI aktiviert. Das heißt es wird geprüft ob diese drei Pakete genau in dieser Reihenfolge ankommen und erst dann wird die Verbindung als legitim angesehen und akzeptiert.
In Ihrem Szenario wurde das erste Paket (SYN) offenbar direkt zugestellt (ging also nicht durch die Securepoint bzw A hat eine direkte Route zu B). Das zweite Paket (SYN+ACK) ging dann an das Default-Gateway von B, weil B keine direkte Route zu A hat. Jetzt schlägt die SPI zu und verwirft weitere Pakete, weil die Verbindung nicht ordnungsgemäß (SYN -> SYN+ACK -> ACK) aufgebaut wurde.
Indem Sie jetzt einen Dienst "XXX-stateless" anlegen, wird die SPI für Regeln mit diesem Dienst deaktiviert. Et voilà die Securepoint schert sich nicht mehr um das fehlende SYN.
der TCP-Verbindungsaufbau geschieht in drei Schritten:
1: A schickt ein SYN an B
2: B antworter A mit SYN+ACK
3: A bestätigt den Erhalt dieses Paketes bei B mit einem einfachen ACK
Standardmäßig hat die Securepoint jetzt eine sogenannte "Stateful Packet Inspection" kurz SPI aktiviert. Das heißt es wird geprüft ob diese drei Pakete genau in dieser Reihenfolge ankommen und erst dann wird die Verbindung als legitim angesehen und akzeptiert.
In Ihrem Szenario wurde das erste Paket (SYN) offenbar direkt zugestellt (ging also nicht durch die Securepoint bzw A hat eine direkte Route zu B). Das zweite Paket (SYN+ACK) ging dann an das Default-Gateway von B, weil B keine direkte Route zu A hat. Jetzt schlägt die SPI zu und verwirft weitere Pakete, weil die Verbindung nicht ordnungsgemäß (SYN -> SYN+ACK -> ACK) aufgebaut wurde.
Indem Sie jetzt einen Dienst "XXX-stateless" anlegen, wird die SPI für Regeln mit diesem Dienst deaktiviert. Et voilà die Securepoint schert sich nicht mehr um das fehlende SYN.
Zuletzt geändert von Erik am Di 21.07.2009, 19:49, insgesamt 1-mal geändert.
Ok, schönen Dank nochmal für die Nachschulung 
Am besten ich trenne die beiden Netzwerke physikalisch, dann hab ich einen sauberen Verbindungsaufbau und kann dann auch ein Regelwerk erstellen das Sinn macht.
Oder gibt es noch eine andere Möglichkeit??!
Gruss
Rene
Am besten ich trenne die beiden Netzwerke physikalisch, dann hab ich einen sauberen Verbindungsaufbau und kann dann auch ein Regelwerk erstellen das Sinn macht.
Oder gibt es noch eine andere Möglichkeit??!
Gruss
Rene
Opinions are like watches. Everyone\'s watch shows different time from others. But, Every one believes that their time is CORRECT...