Securepoint Support Forum

Hallo alle zusammen!

Ich habe seit einigen Tagen mit einer etwas älteren RC100 (C7, 1GB RAM, 80 GB HDD) das Problem, dass im Live Log recht häufig folgender Eintrag zu finden ist:

Firewall DROP DROP(default) IN=eth1 OUT=ppp0 MAC=00:30:18:4a:5c:68:c8:60:00:c8:b1:21:08:00 SRC=192.168.0.213 DST=74.125.232.141 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=3051 DF PROTO=TCP SPT=59536 DPT=80 WINDOW=16425 RES=0x00 ACK FIN URGP=0

und

Firewall ALERT ALERT IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=1563 TOS=0x00 PREC=0x00 TTL=64 ID=27050 DF PROTO=TCP SPT=49221 DPT=41461 WINDOW=3073 RES=0x00 ACK PSH URGP=0

Mit diesem Fehler kann ich nicht wirklich etwas anfangen.

Hintergrund ist folgender:
(die SP dient nur zum Testen u. Lernen, läuft also nicht produktiv!)
Ich habe die RC100 auf die v10 10.6.5 geupdatet. Seitdem können eine Handvoll Webseiten nicht oder nicht vollständig geladen werden, z. B. laufen YT-Videos überhaupt nicht mehr. Ansonsten klappt alles einwandfrei (L2TP-VPN usw.). Manche Webseiten müssen auch mehrmals per F5 neu geladen werden, bevor sie angezeigt werden (wenn das dann überhaupt klappt).

Der telefonische SP-Support gab mir den Tipp, dass nach einem Update noch Reste des "Alt-Systems" auf der Platte sein können, welche den Betrieb einschränken können.
Unter anderem könnte die DNS-DB fehlerhaft sein.

Mit einem passenden Adapter habe ich auf einer Linux-Maschine alle 4 Partitionen der SP-HDD entfernt und das System via USB-Stick neu installiert und komplett neu konfiguriert ==> gleiches Problem!

Ich stehe vor einem Rätsel...

Restliche Konfiguration:

LAN1: DSL-Modem (T-Online 16000)
LAN2: 192.168.0.254
LAN3:

HideNAT Tabelle:
Internal Network eth0 Private-Class-A Exclude
Internal Network eth0 Private-Class-B Exclude
Internal Network eth0 Private-Class-C Exclude
Internal Network eth0 Internet Include

Netzwerkkonfiguration Schnittstellen:
eth0 [ppp0]
eth1 192.168.0.254 24 internal, firewall-internal
eth2 dmz1, firewall-dmz1
ppp0 123.456.789.000 external, vpn-ipsec, vpn-...
tun0 192.168.250.1 24 vpn-openvpn

Ich hoffe, Ihr könnt mir auf die Sprünge helfen!

Danke & Gruß!

Nachtrag:
Ich habe jetzt folgendes herausgefunden:

Wenn ich den betreffenden Host (192.168.0.213) im HTTP-Proxy als Ausnahme eingetragen habe (mit Ziel 0.0.0.0/0.0.0.0) klappt alles fehlerfrei.

Der Host soll aber gerade eben über den Proxy ins Internet.
Hat vielleicht jemand eine Erklärung dafür?

Ich wäre für jede Hilfe dankbar!

Gruß

Nachtrag:
Auch nach kompletter Neuinstallation mit der v.11.2.5 keine Änderung!

Die "nackte" Konfiguration nur mit Internetzugang und Standard-Einstellung zeigt den gleichen Effekt.
Der absolut kompetente SP-Support-Mitarbeiter stand heute Nachmittag auch vor einem Rätsel... nach fast einer Stunde kamen wir überein, dass mit der v11 das Problem behoben sein müsste/sollte.

Nur mit der etwas "unsauberen any-stateless" (O-Ton) Regel lässt sich dies umgehen. Das ist aber sicher nicht im Sinne des Firewall-Erfinders :-)

Nichtsdestotrotz nehm ich diese Story mal mit nach Hüllenhorst zur Schulung am 27. übernächste Woche. Ist bestimmt ein spannendes Thema!

Jede Idee bzw. jeder Denkanstoss ist trotzdem willkommen!

Danke und schöne Pfingsten Euch allen!

Gruß
Thorsten

Das Problem dürfte eine Webseite sein, die irgendwas in Richtung "Long-Polling" verwendet. Also eine HTTP-Verbindung die künstlich offen gehalten wird, um Daten in beide Richtungen zu übertragen.
Irgendwann killt der Squid allerdings diese Verbindung. Schickt der Client weiterhin Pakete, passen die zu keinem Eintrag im Connection-Tracking mehr und werden deshalb verworfen.
Das erklärt auch, warum es ohne Proxy (besser) funktioniert: die TCP-Verbindungstimeouts des Betriebssystems sind höher, als die HTTP-Timeouts im Proxy. Ganz vermeiden lassen sich die Probleme damit aber auch nicht... sie treten nur später oder nicht so häufig auf.

Andere Möglichkeit: Ihr Client/Netzwerk macht... Dinge... Zum Beispiel: Erst Verbindung schließen und dann noch versuchen Daten hinterher zu schicken.

Hätten wir bloss mal einen Tick weiter vorn angesetzt:

über einen LANCOM 821+ baut die SP via PPPoE die Verbindung ins Internet auf.

Der LANCOM-Router ist laut dieser Anleitung als DSL-Modem konfiguriert.

Mit einem Speedport W701V als Einwahlgerät klappt das ganze wie gewünscht, also ohne den Host als Ausnahme im HTTP-Proxy einzutragen.
Beim Einstellen des Speedport auf "PPPoE Pass-Trough = EIN" schaltet dieser automatisch die Firewall aus.

Auch wenn ich die Firewall, IDS und dergleichen des LANCOM deaktiviere, ändert sich nichts an dem Problem, dass beispielsweise YT-Videos nicht laufen.

Die Securepoint kann somit wohl als "Verursacher" ausgeschlossen werden. An irgendeiner Stelle bleiben Pakete im LANCOM hängen und/oder können nicht (mehr) zugestellt werden...

Any ideas?

Danke für den klasse Support!

Schöne Pfingsten!
Gruß
Thorsten