Es lag nur an der Promiscuous Mode Einstellung des vSwitch. Nach einem Wochenende mit vielen Test und Wireshark tcp stream Analysen sieht jetzt alles gut aus. Vielen Dank für die Anregungen und die nette Hilfe.
Beiträge von Knockahomer
-
-
Es wird wohl an esxi Einstellungen des vSwitch liegen. Ich werde am Wochenende umstellen und nochmal ausgiebig testen und dann Montag die Ergebnisse posten.
-
Probiers mal mit meiner VM
-> Mache ich noch heuteWas ist den das für eine VMWare Maschine also der Host?
-> Supermicro mit Intel Hardware (vmware zertifiziert)Was für Netzwerkkarten?
-> Intel 82571EBIst für die VMSwitche das promiscuous mode deaktiviert?
-> neinSind die Netzwerkkarte in der VM und am VSwitch auf Auto 100FD/HD,1000FD/HD,Autosensing oder Fest eingestellt? macht bei manchen Konstellationen auch Unterschiede
-> Verhandeln, 1000 Vollduplex -
Ich habe jetzt noch einen tcpdump auf dem Webserver gemacht. Der Traffic im lokalen virtuellem Netzwerk verursacht keine Probleme. Nur alles was von der Firewall weitergeleitet wird enthält BADTCP Traffic.
Ich werde mi jetzt mal das rc.firewall Script ansehen. Deine Firewall habe ich noch nicht testen können. Ich habe allerdings auch selbst eine 2.5c installiert und das Portforwarding exakt so konfiguriert wie Du. -
Nur ein kurzes Update. Die vmxnet3 Treiber in Verbindung mit der 2.5c haben auch keine Besserung gebracht. Ich schaue mir jetzt mal den Switch genauer an.
Parallel würde ich gerne versuchen die BADTCP Chain zu deaktivieren. In den Features der 2.4.1 steht folgendes:Firewall
BADTCP filtering can now be disabled (#3152)Ich suche jetzt seit zwei Tagen und finde nirgendwo auch nur einen Anhaltspunkt wo diese Option aktiviert werden kann. Ich freue mich über jeden Hinweiß.
-
Das kann ich erst morgen mit Sicherheit sagen. Ich möchte auch noch den Netzwerktreiber ausschließen und es einmal mit vmxnet3 versuchen. Ich melde mich wieder sobald ich mehr weiß.
UPDATE:
Vielen Dank für die 2.5C Frank, ich hatte die 2.5 ja vorher schon getestet und meine war exakt so konfiguriert wie die deine. Darum werde ich jetzt erst einmal die anderen Treiber testen. -
Das Angebot würde ich gerne annehmen. Die erste Auswertung mit Wireshark hat gezeigt das es zu duplizierten Paketen kommt. [TCP Dup ACK]
Jetzt habe ich in einem älteren Post im Netz gefunden das es da ein Problem mit dem e1000 Treiber gab. (Ob das noch aktuell ist weiß ich nicht)
Ich würde also die Endian mit vmxnet3 testen und schauen ob es da bei mir auch Probleme gibt. -
Habe da die e1000 genommen da man für die vmxnet2/3 spezielle Treiber braucht die bei einer Firewall meistens nicht dabei sind.
Ich melde mich sobald ich die tcpdumps habe. Wird wohl erst morgen sein. -
Erstmal vielen Dank für eure Hilfe.
Auf dem Webserver läuft ein soap service. Ein nagios check testen den soap service und meldet einen Fehler sobald es ein Verbindungsproblem gibt. Ich werde mir mal einen tieferen Überblick mit tcpdump besorgen.
Das Problem ist ja auch das es nicht mit allen Paketen Probleme gibt. 99,9 % gehen perfekt durch. Ich schreibe ein Update sobald ich mehr habe. -
Ja richtig,
Installiert auf esxi5, Webserver liegt im grünen Bereich. Die Endian soll alles was auf rot Port 80 und 443 ankommt auf dem Webserver weiterleiten.
-
Das Downgrade auf 2.2 hat keine Verbesserung gebracht. Es kommt auf Client Seite noch immer zu vereinzelten Fehlern. Ich werde mir mal die Chains einzeln vornehmen und schauen was ich noch anpassen kann.
Weiß jemand wo die Konfiguration für iptables bei Endian gespeichert wird? Auch in /var/efw/ ? -
Das wird etwas schwer bei virtueller Hardware auf esx5. Es sieht momentan jedoch so aus das die Endian 2.2 keine unerwünschten INPUT:DROP und FORWARD:DROP Logs mehr wirft. Ich habe eben die iptables von 2.2 und 2.5 verglichen und da gibt es schon einige Unterschiede in der INPUT und FORWARD Chain. Ich werde das heute noch beobachten und morgen ein update posten.
-
Moin,
ich bekomme weiterhin INPUT:DROP und FORWARD:DROP Logs. Ich habe das Gefühl das es eine besondere Filterregel in iptables ist die manchen Paketen das Leben nimmt.
In den Release News zur Endian 2.4 steht das man jetzt BADTCP deaktivieren kann. Ich habe aber dazu nichts in der Dokumentation oder über google gefunden. Kennt sich jemand damit aus?
Ich denke mir wird nichts anderes übrig bleiben als mir direkt die iptables rules anzusehen. -
Erstmal danke für die Antworten
Nein, ich weiß das Snort manchmal Probleme macht, darum habe ich das noch nicht aktiviert. Es ist ein Standard Installation. Ich habe nur die Regeln angepasst.
Es laufen nur die Standard Dienste. Ich werde heute Nacht auf die Endian 2.2 umschalten und testen ob ich da auch diese INPUT:DROP und FORWARD:DROP Probleme habe. -
[Blockierte Grafik: http://s1.directupload.net/images/120116/vppdgdun.png]
UPLINK Any bedeutet nur <Jeder Uplink>
Ich hatte vorher auch das Interface direkt ausgewählt. Es waren aber dieselben Fehler.
-
Hallo, ich bin mittlerweile komplett Ratlos.
Ich habe Endian Community 2.5 auf einer virtual maschine auf esxi5.0 laufen.
Die Endian Firewall soll nur Port 80 und 443 auf einen internen Webserver weiterleiten.
Die Inter-Zone Firewall und die Ausgehende Firewall sind mittlerweile deaktiviert.
Die einzigen Regel die ich gesetzt habe sehen so aus:Port forwarding / Destination NAT
Uplink ANY TCP/443 WebserverIP : 443
GESTATTEN von: Uplink ANYUplink ANY TCP/80 WebserverIP : 80
GESTATTEN von: Uplink ANYEingehender gerouteter Datenverkehr
1 <ALLE> WebserverIP TCP/443
2 <ALLE> WebserverIP TCP/80Auszug aus den Firewall logs
Firewall 2012-01-16 12:02:47 FORWARD:DROP TCP (br0) WebserverIP:443 -> xxx.xxx.xxx.xxx:55694 (eth1)
Firewall 2012-01-16 12:02:47 FORWARD:DROP TCP (br0) WebserverIP:443 -> xxx.xxx.xxx.xxx:55694 (eth1)
Firewall 2012-01-16 12:03:01 INPUT:DROP TCP (eth1) xxx.xxx.xxx.xxx:52953 -> UplinkMain:80
Firewall 2012-01-16 12:03:17 INPUT:DROP TCP (eth1) xxx.xxx.xxx.xxx:1107 -> UplinkMain:443Die Firewall lässt 99% der Pakete korrekt durch. Ich kann mir einfach nicht erklären warum einige Pakete geblockt werden.
Hat jemand ein ähnliches Problem?