Andre Schulze wrote:

Tach Zielgruppe,

um clients an dem internen Interface unseres Servers mit nfs bedienen zu können, habe ich u.a. folgende iptables Regeln:

# stehende und daraus resultierende Verbindungen zulassen -A INPUT -i eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT

# tcp dienste -A INPUT -s 192.168.16.0/255.255.255.0 -i eth1 -p tcp \ -m state --state NEW -m multiport \ --dports ssh,www,sunrpc,netbios-ns,netbios-dgm,netbios-ssn -j ACCEPT

# udp dienste -A INPUT -s 192.168.16.0/255.255.255.0 -i eth1 -p udp \ -m state --state NEW -m multiport \ --dports netbios-ns,netbios-dgm,sunrpc,2049 -j ACCEPT

Nun kann ich auch von einem nfsclient mit rpcinfo -p $SERVER sehen, daß alle rpc Dienste da sind. Trotzdem sagt der client rpc unable to recieve oder so. Erlaube ich kurz mal pauschal den kompletten Zugriff auf das Interface, wo der nfs Server läuft, dann kann ich das share mounten.

Du brauchst noch ein paar hoehere Ports, meist so ab 825 aufwärts. Schalt einfach mal das Logging ein, da zeigt er Dir die Ports an. Das dumme daran ist, dass er für jede Verbindung einen neuen Port braucht. Wenn die Verbindungsanzahl abschätzbar ist kannst Du hier einen Bereich 825:850 freigeben. Der Portmapper || nfsserver läßt sich auch irgendwie auf einen solchen Bereich einschränken.

Nach dem mounten ist scheinbar die Verbindung ESTABLISHED und ich kann

So isses.

die Regel, die pauschal alles auf dem Interface erlaubt wieder entfernen und trotzdem funktierniert alles noch (wegen -m state ... -j ACCEPT).

Interessanter Ansatz. Vielleicht sagst Du dem portmapper, daß er kurz die Firewall aufmacht und wenn er fertig ist wieder zu. ;-)

Warum erkennt iptables denn nun nicht, daß aus der Verbindung zum Portmapper (111) die mountd Verbindung usw. hervorgehen? Gibt es da noch ein anderes modul, das den Trick macht?

Da müßte es ein Tracking-Modul, wie das für FTP bei ipchains geben. Das müßte dann die Portmapper-Verbindung belauschen. Hab aber noch nicht danach gesucht, obs sowas gibt.

Rico