Problem mit Jail und sich ändernder MAC Adresse

[crotchmaster]

Moin Jungs,

ich habe z.Z. ein Problem mit einem FreeBSD Server, der bei einem Provider steht. Der Provider betreibt Switches, die einen Port abschalten, wenn von dem Server eine Verbindung mit einer MAC-Adresse rausgeht, die nicht zu dem Port gehört. Der Server ist danach netzwerktechnisch nicht mehr erreichbar, läuft aber sonst 1a.

Etwas zur Konfiguration. Das System läuft noch mit FreeBSD 6.2. Darauf läuft ein Jail mit einer privaten IP-Adresse (192.168.0.1/32). Die IP-Adresse ist an das Interface lo1 gebunden. Über pf werden Anfragen an die öffentl. IP-Adresse auf den Ports 22, 80 und 443 über redirects an die entsprechenden Ports im Jail weitergeleitet. DNS-Requests und ausgehende Mails gelangen via NAT in die große weite Welt, DNS-Requests nur zu den Nameservern des Providers, SMTP uneingeschränkt. Das gesamte Netzwerkgedöns wird nur auf dem Hostsystem konfiguriert und ist über das Jail nicht veränderbar.

Meine Frage ist nun. Wie ist es möglich, das Ethernet-Frames mit einer verkehrten MAC-Adresse das System verlassen, wodurch die Portsperre ausgelöst wird?

Der Support meint, das taucht auf, wenn eine virtuelle Maschine versucht, mit einer anderen MAC-Adresse eine Verbindung auf zubauen. Das kann ich mir angesicht der o.g. Konfiguration nicht vorstellen.

Ich habe die Logfiles trotzdem durchforstet und finde keine Hinweise auf Veränderungen. Da ich nun mit meinem Latein am Ende bin, habe ich als Akt der Verzweiflung pflog abgeschaltet, wodurch das Interface nicht mehr im promiscous-Mode arbeitet. Ich glaube aber nicht, dass das etwas bewirkt, zumal ich es auch bei anderen System aktiviert habe. Wir haben bei dem gleichen Provider ein identisches System laufen, was die Hardware, die Software und die Konfiguration betrifft, welches keinerlei Probleme bereitet. Bei dem fehlerhaften System hatte ich das Problem schoneinmal vor ca. 8 Wochen.

Ist es denkbar, das es auch ein Hardwareproblem der Netzwerkkarte ist?

Ich wäre für Lösungsvorschläge sehr dankbar, auch für Tipps, wie ich das Problem weiter eingrenzen kann. Wenn Ihr weitere Angaben benötigt, dann lasst es mich wissen.

Danke und Gruß c.

 

[soul_rebel]

Ein Jail auf einem Interface zu betreiben bedeutet gerade nicht, dass der traffic von einer anderen MAC-Adresse kommt sondern nur von einer anderen IP-Adresse.

Woher das bei dir kommt kann ich nicht sagen. Ich würde als Empfehlung Jails die auf lo0 laufen aber Adressen der Form 127.0.0.* geben, da lo0 an sich ja 127.0.0.1 ist.

 

[morph]

Machst du vielleicht irgendwas mit CARP?

 

[crotchmaster]

Machst du vielleicht irgendwas mit CARP?

Nee, überhaupt nicht. Nur die o.g. 'popeligen' redirects und nat. Auch deshalb die Ratlosigkeit.

Gruß c.

 

[troll]

Was hat der Provider davon seine eigenen Kunden zu sperren?

Wenn du tatsächlich dort bleiben möchtest, dann sniffe einfach sämtlichen Netzwerkverkehr mit.
Eventuell kanns ein HW Problem sein, dass manchmal unvollständige Pakete rausgehen. Tja, oder ein karp0tter Switch, oder eine Fehlkonfiguration des Switch.

Und sag dem Provider mal, dass er dir den Grund für das Blocken nennen soll. Und zwar kein Trallalla, sondern konkret aus den logs: "um 25:31 ging ein Paket von der Adresse blablblabla, MAC, Port so und so, Protokoll, Destination..."

 

[Bummibaer]

Hoi,

ich würde einfach mal den ARPWATCH Bären druf ansetzen und mal schauen was der so an`s Licht bringt. Vielleicht findest Du ja so einen Ansatz woher das kommen könnte. An sonsten soll der wo sperren will erstmal 'zeigen' warum.

Gruß Bummibär

 

[fader]

Poste doch bitte einfach mal die komplette Ausgabe von "ifconfig".

Den Hoster zu nerven bringt erst dann was, wenn es nur noch die NIC sein kann. Wenn auf dem Port die falsche MAC reinkommt, faellt der bei billiger "Portsecurity" halt zu. Seine Switche waren scheinbar entweder guenstig oder sie sind es inzwischen (heutzutage gibts da andere Moeglichkeiten, ein MAC Spoofing zu verhindern).

Wir hatten im Studentennetz damals so eine Konfiguration. Da da sind dauernd die Ports zugefallen. Haeufig auch, weil die NIC einfach defekt war. Die RTL Karten warn damals dafuer beruechtigt. Ich hatte selbst eine, bei der hab ich am Ende die (korrekte) MAC gleich vom System setzen lassen, weil die nach dem Booten recht haeufig nur noch aus Nullen bestand. Es gibt auch Karten, die senden immer mal ein paar einzelne Frames mit falschen MACs. Ein Hardwareproblem ist also keineswegs ausgeschlossen und angesichts der Tatsache, dass eine identische Konfiguration auf einem anderen System keine Probleme bereitet, sogar wahrscheinlich. Aber das kann ich Dir sagen, wenn ich die Konfiguration gesehen habe.

Eine weitere Moeglichkeit waere, dass Deine Kiste ger00ted wurde und einer damit so diverse MAC Spoofing stunts versucht (und scheitert).

 

[crotchmaster]

Moin fader,

vielen Dank für Deinen Post. Hier die Ausgabe von 'ifconfig -a':

nve0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 
        inet 1.2.3.4 netmask 0xffffff00 broadcast 1.2.3.255 
        inet 1.2.4.5 netmask 0xffffff00 broadcast 1.2.4.255 
        ether 00:19:99:0d:cd:ca 
        media: Ethernet 100baseTX <full-duplex> (10baseT/UTP) 
        status: active 
pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33160 
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 
        inet6 ::1 prefixlen 128 
        inet 127.0.0.1 netmask 0xff000000 
lo1: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 
        inet 192.168.0.1 netmask 0xffffffff 
lo2: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 
        inet 192.168.0.2 netmask 0xffffffff 
lo3: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 
        inet 192.168.0.3 netmask 0xffffffff

Die Interfaces lo2 und lo3 werden z.Zt. nicht genutzt. media bei nve0 ist händisch gesetzt. Warum das Interface nur mit 10baseT/UTP läuft weiß ich nicht. Die Maschine ist an einem 100MBit-Switch angeschlossen. Die identische Maschine hat diese Phänomen auch. Die tatsächliche Geschwindigkeit stimmt aber bei beiden.

Ich habe nochmal mit dem Support telefoniert. Die können mir leider nicht sagen, was für ein Paket das Portabschalten ausgelöst hat. Ich habe nun ersteinmal den Rat vom Bummibären umgesetzt und arpwatch laufen. Zusätzlich habe ich tcpdump laufen, das rotierend den ganzen Netzwerkverkehr aufzeichnet und durch ifstated gestoppt wird, wenn die Verbindung unterbrochen ist. ifstated sollte eigentlich nicht nötig sein, da ja dann keine Pakete mehr durchkommen, aber sicher ist sicher. So hoffe ich, nach einem neuen Zwischenfall dem Fehler dichter auf die Spur zukommen. Mal schauen, ob ich noch remotes Loggen mittels rsyslog+stunnel einrichte.

Gruß c.