![](https://seccdn.libravatar.org/avatar/e525c3860a5bb22edb8ae76e11a5e1cf.jpg?s=120&d=mm&r=g)
At 22:01 01.03.03 +0100, Thorsten D. Marsen wrote:
Hallo Matthias,
Das Firewall log zeigt, daß es NUR Probleme bei den ausgehenden TCP- Paketen gibt.
Aus dem Log müßte man die Regel, die Du benötigst, sofort ableiten können. Mail sie sonst doch mal rüber.
In=eth0 out=ppp0 src=192.168.10.61 DST=123.123.123.123 LEN=48 TOS=0x00 PREC=0x00 ttl=127 id=9058 DF PROTO=TCP SPT=6699 DPT=3777 WINDOW=8472 RES=0x00 ACK SYN URGP=0 (von hand abgetippt, daraus lese ich: .10.61 versucht die Anfrage von .123 zu beantworten (6699 an 3777) ist dann der Rückkanal. Der Effekt tritt übrigens dann auf, wenn der Client hier die Verbindung fr den Upload aktivieren will, also wenn ein externer dann Daten kriegen soll.
Etwa so: $IPTABLES -A FORWARD -s 192.168.10.61 -o ppp0 -p tcp \ --dport 6699 -j ACCEPT Das würde ja ausgehenden Traffic betreffen. Aber hier geht es um die Antwort-Pakete der eingehenden Verbindung...
Wenn ich das richtig sehe, wird der Client einen anderen Port als 6699 zum Senden benutzen - auf 6699 horcht er nur auf eingehende Verbindungen.
Klar, 6699 wird nur gebraucht, wenn ich eine Datei suche
Ganz davon abgesehen, hast Du nicht Regeln der folgenden Art?
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
Damit wird generell jeder Rücktransfer auf einem TCP/IP Link erlaubt - das ist generell nicht gefährlich.
Nein, nicht grundsätzlich, sondern nur auf bestimmten Ports. Die Firewall ist hier ganz fürchterlich dicht gezogen, so daß wirklich nur der Traffic durchgeht der ausdrücklich gewünscht ist. Grundsätzlich wird nichts und niemand getraut. ;-) Gruß Matthias