iptables / ferm

[raiserle]

Hallo Gemeinde.

Ich habe da ein sehr seltsames Verhalten von Teamspeak mit iptables.

Gut, ich nutze ferm zum besseren konfigurieren - aber das sollte keine Rolle spielen.

Der TS-Srv wartet auf dem Port 8767 UDP

- in ferm.conf ahbe ich unter table filter chain INPUT folgendes drin

#ferm.conf auszug

...

policy DROP;

mod state state INVALID DROP;

mod state state (ESTABLISHED RELATED) ACCEPT;

....

proto udp dport 8767 ACCEPT;

nmap localhost -p 8767 -sU zeigt auch, das der port offen ist. Auch nmap 192.....x -> offen. netcat localhost 8767 geht (tcpdump port 8767 spuckt aus.. was ich mit netcat rumwurschtel) (Bei gestartetem TS-Srv. | nectcat schlägt fehl - wenn TS-Srv aus ()) Versuch ich nun mit einem TS-Client zu connecten.. schlägt das fehl. Es kommt nix im tcpdump..... - noch in einem logfile. Schreibe ich in table filter chain INPUT nach policy DROP;

#ferm.conf auszug

....

ACCEPT;

....

Kann ich mit dem TS-Clienten connecten.

So.. viel geschrieben. Ich hoffe, dass es verständlich war, wo das Problemchen liegt.

:confused:Es muss ja was fehlen, bei der ferm.conf - was ich noch eintragen muss. Nur was dort fehlt - ich habe keine Ahnung - und auch GOOGLE will mir nicht helfen.

lG Henrik

[dku]

poste doch mal bitte den output von

iptables --list -v

da kann man vielleicht etwas eher sehen

[raiserle]

Ich habs bei PasteBin reingestellt.

lG

[dku]

Laut dem iptables Output ist Port 8768 tcp/udp geöffnet.

Wenn Teamspeak auf 8767 läuft wäre da wohl der Fehler zu suchen

[raiserle]

Schön, dass du mir jetzt gesagt hast, was ich selbst schon gesehen und oben im Text erwähnt hatte. (Sry, wenn zu schnippig)!

Aber es liegt nicht am TS. Denn "nochmal": ein ACCEPT; in der INPUT

behebt das Problem.

Es ist ja gerade DAS Problem - das ich nicht verstehe - Port offen - iptables IO - connect geht nicht.

zB. Alle rules aus iptables raus - TS connect geht.

Es muss also ein Eintrag in der INPUT sein. (denke ich zumindest.. andere Stellen möglich )

lG

[dku]

  raiserle schrieb:

Schön, dass du mir jetzt gesagt hast, was ich selbst schon gesehen und oben im Text erwähnt hatte. (Sry, wenn zu schnippig)!

Port 8768 hast du in deinem Eingangspost nicht erwähnt. Sondern nur Port 8767.

Wenn der nicht geöffnet ist in der Firewall (was er laut dem Output nicht ist), dann kriegst du von aussen auch keine Verbindung zustande.

(oder ich hab tomaten auf den den Augen :upps )

Ein "accept all" erschlägt natürlich alles.

Du könntest mal

iptables -I INPUT 5 --proto udp --dport 8767 -j ACCEP 

versuchen.

Das fügt die _richtige_ Regel manuell ein.

[raiserle]

Oh man(n).

Entschuldige nochmal bitte - dass ich so blind bin - und deinen Post nicht verstanden habe.

Ich dachte du meintest - es läge am TS. Mir ist die 8768 absolut nicht aufgefallen.

iptables benutzt.. geht .. muss ich das ABER trotzdem nicht verstehen.

Denn in der ferm.conf steht doch 8767 drin.

lG und Danke für die guten Augen

[dku]

kein Problem ;-)

evtl einfach mal in der ferm.conf ein bisschen mit den Ports rumspielen, die Regeln erstellen lassen und dann einfach bei iptables direkt schauen was er so daraus gezaubert hat.

ggf. fehlt irgendwo der berühmte "haken" oder so ;-)

[raiserle]

Hmm..

nachdem ich es - wie du sagtest - über iptables eingefügt habe, klappt es nun auch mit FERM.

Es gibt eben Dinge, die man nicht verstehen muss.

Als Anhang:

Ja, ich habe ferm die conf neu laden lassen (siehe ACCEPT).

Ja, andere Regeln konnte ich mit FERM auch beeinflussen.

Nein, ich verstehe nicht, wo der Fehler lag. (ausser das FERM nen falschen PORT benutzte)

ps.

FERM ist schon genial. Zumal man sich damit nicht mehr ausperren kann - fals mal ein Eintrag wie drop an der falschen Stelle kommt (tcp 22 )

Ich kann nur jedem raten! Nutzt FERM.

Das Progrämmchen (Script) wartet immer default 10 Sekunden auf die Eingabe von YES nach einer Änderung an der FW. Sollte in den 10 Sek kein YES kommen - wird ein Rollback gemacht. Wie gesagt : Aussperren fast unmöglich.

lG Henrik