suse firewall blockiert broadcast adresse suse9.2

Hallo,
ich habe ein Problem mit meiner Firewall - Suse 9.2 (alle Updates).
Die Broadcast Adresse läßt sich nicht anpingen und das hat zur Folge das der Samba nmb Dienst sich nicht im Netzwerk anmeldet. Ohne Firewall funktioniert alles einwandfrei.
In der var/log/samba/log.nmbd steht folgendes:

nmbd/nmbd_packets.c:send_netbios_packet(163)
send_netbios_packet: send_packet() to IP 192.168.2.255 port 137 failed

- ja ja ja ;-) natürlich ist der Port 137 in der Firewall freigegeben und das für udp, tcp, ext, int
- Broadcast ist in der Firewall auch auf "YES". Versuche mit "int" "ext" brachten auch nichts.

Hier kurz die wichtigsten Zeilen der SuseFirewall2:
FW_DEV_EXT="eth0"
FW_DEV_INT="eth0"
FW_PROTECT_FROM_INTERNAL="yes"
FW_AUTOPROTECT_SERVICES="yes"
FW_SERVICES_EXT_TCP="microsoft-ds netbios-dgm netbios-ns netbios-ssn 137 138 139 445"
FW_SERVICES_EXT_UDP="microsoft-ds netbios-dgm netbios-ns netbios-ssn 137 138 139 445"
FW_SERVICES_EXT_IP="udp tcp"
FW_SERVICES_INT_TCP="microsoft-ds netbios-dgm netbios-ns netbios-ssn 137 138 139 445"
FW_SERVICES_INT_UDP="microsoft-ds netbios-dgm netbios-ns netbios-ssn 137 138 139 445"
FW_SERVICES_INT_IP="udp tcp"
FW_TRUSTED_NETS=""
FW_KERNEL_SECURITY="yes"
FW_ALLOW_FW_BROADCAST="yes"

Verschiedene Versuche nur mit FW_DEV_EXT oder FW_DEV_INT schlugen ebenfalls fehl.
Bei meiner Suse9.0 Installation lief noch alles einwandfrei, aber bei Verwendung gleicher Einstellungen auch keine Lösung. Warscheinlich wegen Umstellung auf iptables.
Ein Zugriff über Samba Freigabe mit der IP des Servers funktioniert, nur mit dem Servernamen bekomm ich keinen Zugriff (nmb). Wie gesagt nur bei eingeschalteter Firewall2.

Mein Netz: DSL Router, Suse9.2 (Suse9.0) Desktop, Laptop XP, Desktop XP

Mit iptables kenne ich mich nicht aus, bin nur geübter Anwender. Vielleicht kann mir jemand auf die Sprünge helfen ?

# route

Kernel IP Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
192.168.2.0 * 255.255.255.0 U 0 0 0 eth0
link-local * 255.255.0.0 U 0 0 0 eth0
loopback * 255.0.0.0 U 0 0 0 lo
default 192.168.2.99 0.0.0.0 UG 0 0 0 eth0

# ifconfig

eth0 Protokoll:Ethernet Hardware Adresse xx:xx:xx:xx:xx:xx inet Adresse:192.168.2.1 Bcast:192.168.2.255 Maske:255.255.255.0 inet6 Adresse: fexx0::2xx:1cxx:fexx:10xx/64 Gültigkeitsbereich:Verbindu

Gruß

Heiko

Das Anpingen der Broadcastadresse erfolgt mit icmp-echo Paketen und wird durch einen Laufzeitparameter des Kernels bestimmt. Mit

echo 0 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

Zum Vergrößern anklicken....

wird das Ignorieren dieser Pakete ausgeschaltet und mit

echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

Zum Vergrößern anklicken....

eingeschaltet. Dieses Verhalten bezieht sich aber nur auf icmp-echo Befehle und ist an sich auch sehr nützlich. Es verhindert das ein Rechner als Verstärker eines Broadcaststurm mißbraucht werden kann. Der Nachteil besteht darin, dass keine Reaktion auf die Broadcastadresse erfolgt wenn der Befehl nicht vom gleichen Rechner stammt. Um mit ping -b Broadcastrufe abzusetzen müssen beide Rechner das Ignorieren auf 0 stehen haben.

Wie gesagt, mit Netbios-Rundrufen hat dieses Verhalten nichts zu tun, sondern erklärt eben warum icmp-echo Broadcast geblockt werden.


mfG
gaw

Wenn ich dich richtig verstanden habe, sollte es auf jeden Fall möglich sein, seine lokale (vom gleichen Rechner) Broadcast Adresse anzupingen. Egal ob ignorieren an- oder ausgeschaltet!?

Das funktioniert (mit eingeschalteter Firewall) bei mir nicht. Der Schalter FW_ALLOW_FW_BROADCAST="yes" in der SuSEfirewall2.conf scheint keine Wirkung zu haben.

Gebe ich den genannten Befehl
echo 0 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
ist ein Ping an die Broadcast möglich.

Wenn das mit den netbios Rundrufen nicht zu tun hat, warum hab ich dann die Fehlermeldung in der /var/samba/log.nmbd ? In meiner Suse9.0 log.nmbd findet sich dieser Fehler nicht :-?

Und als letztes, wie kann ich diese Funktion dauerhaft deaktivieren ohne das die Firewall diese Einstellung wieder überschreibt?

Danke

Heiko

Bestimmte Fragen kann ich nicht beantworten, weil ich nicht der Entwickler der SuSEFirewall bin sondern eigene Firewallskripte schreibe die sich so verhalten -- zumindestens in den meisten Fällen -- wie ich das möchte.

Wenn ich aber das Konzept der SuSEfirewall richtig verstanden haben hat die Variable FW_ALLOW_FW_BROADCAST nichts mit dem icmp-Protokoll zu tun, sie erlaubt zwar Broadcasts aber kein icmp-echo Broadcast und damit kein ping auf eine Broadcastaddrese.

Das Erlauben des Broadcasts bezieht sich wohl nicht auf icmp Pakete. Vielleicht haben die Entwickler das auch anders gemeint. Im SuSEfirewallskript findet sich an einer Stelle der lapidare Kommentar dass icmp-echo Broadcasts nicht notwendig sind.

Ich habe mir tatsächlich einmal die Mühe gemacht die SuSEfirewall2 auf einem Notebook zu starten. Als interne Firewall in einem LAN scheint sie nicht geeignet, es ist zu kompliziert sie auf diese Bedürfnisse einzurichten. Natürlich kannst du versuchen das SuSEfirewallskript umzustricken, ich würde aber davon abraten.


Ich empfehle ein eigenes iptables-Skript.

mfG
gaw

Danke,
ich hab mich mittlerweile ein wenig belesen und werde wohl ein eigenes script schreiben.

Heiko

Also wollte nur mitteilen das ich mein Problem gelöst habe.
1. SuSE Firewall deaktiviert
2. Guarddog installiert ( http://packman.links2linux.de/ )

Ich war dann doch zu faul mich einzuarbeiten ...

Es handelt sich dabei um ein Programm zum Erstellen von Firewall Regeln. Das schöne ist man brauch nur wenig Vorkenntnisse.

Ich bin halt nur Anwender und brauche Linux zum Arbeiten. Andere brauchen Linux um etwas zu arbeiten

Gruß

Heiko

Du musst dich dafür nicht entschuldigen, das ist völlig legitim. Es wäre ebenfalls legitim, gewesen einen Experten kommem zu lassen damit dieser den Linux-Arbeitsrechner einrichtet, falls man sich das leisten kann. Wie weit jeder Einzelne in die Materie einsteigt, bleibt doch jedem selbst überlassen. Ich erwarte auch nicht von einem Windows-User einen ISA-Server, einen Mailserver oder ein Datev System einzurichten oder mit VBscript zu arbeiten und sich in das .NET Frame einzuarbeiten. Ebensowenig erwarte ich von einer Sekräterin eine relationales Datenbankmodell aufzustellen und Views in perl oder php abzubilden.

Derjenige, der das System aber viel stärker selbst kontrollieren- und etwas über Firewalls lernen möchte wird ein eigenes iptables Skript präferieren, sozusagen als master of his own system im Gegensatz zum slave of a black box system. In diesem Sinne as you like it.


Mit freundlichen Grüßen
gaw