Ausgehender Sprachkanal und AVM Firewall-log nicht zu finden

[gnom2]

Hi All!
Erst mal herzlichen Dank für dieses TOP - Forum.
Obwohl ich schon diverse Threars gelesen habe komme ich leider auf keinen grünen Zweig.
Zenario:
FB 7270, gemeinsame Nutzung mit 2 Nachbarn über WLan, filesharing und P2P kann einem leider nicht abgewöhnt werden.
FB also Freetz-Modden und ausgehend alles dicht machen.
Soweit sogut. Standardports sind freigegeben und alles läuft wie es soll.
Nun zum Problem
In der FB sind die VoipPorts freigegeben deren ich habhaft werden konnte
permit udp any any range 3478 3479 /*AVM*/
permit udp any any range 30000 30005 /*AVM*/
permit udp any any range 7077 7097 /*AVM*/
permit udp any any range 5070 5079 /*AVM*/
permit udp any any range 5060 5061 /*AVM*/
permit udp any any range 5004 5005 /*AVM*/

Alles geht ausser dem ausgehenden Sprachkanal. Will heißen mein Telefonpartner hört mich nicht.

Um dem ganzen auf die Spur zu kommen habe ich mir gedacht schaue ich einfach ins Firewall-Log. das finde ich aber nirgens!
DSLD habe ich mit dsld -s gestop und mit -fv wieder gestartet

Logging ist nirgens zu sehen :-(

Vielleicht hat ja einer ne Idee die meine Probs löst

greetz

 

[cando]

Hallo,

Firewall log geht nicht mehr. AVM hat dem dsld der 7270 das loggen abgewöhnt. wurde schon lang und breit hier im forum diskutiert.

ausserdem hat AVM den printk verbogen und nutzt den für die DECT steuerung. damit verschwinden die meisten kernel logs ins nirvana.

echo STD_PRINTK > /dev/debug schaltet kernel meldungen ein (dafür geht kein DECT mehr)

echo AVM_PRINTK > /dev/debug setzt wieder die AVM logik ein, DECT geht, aber kein kernel log mehr....

Es gibt auch noch einen patch, der das beheben können soll, funktioniert aber bei mir nicht stabil, ich habe dann alle 4 Minuten Gesprächsabbrüche im DECT.

Hast du in deiner Firewall die stateful - regeln rein / raus mit eingebaut?

permit ip any any connection outgoing-related
permit ip any any connection incoming-related

P.S. Willkommen im Forum...

 

[gnom2]

Hi,

danke für die schnelle Antwort....

permit ip any any connection outgoing-related
permit ip any any connection incoming-related

das alle ausgehende Connections beantwortet werden können will ich ja grade, wegen der p2p-Problematik, verhindern. Oder liege ich da falsch?
Im Normalfall ist es doch so, daß ne FW alles von aussen blocken soll und ich Löcher für Dienste bohre, die durch dürfen.

Auf DECT kann ich ja zum loggen verzichten und den vorhandenen S0-Port nutzen oder einen der beiden analogen.
Interessant wäre noch eine Liste aller verwendeter Voip-Ports. Die die ich schon habe stammen aus diversen threads
-----------------
Ich habe jetzt im Ausschlussverfahren Ports zwischen 15000 - 19999 UDP freigegeben und nun geht der ausgehende Sprachkanal. Dokumentiert habe ich allerdings nichts gefunden :-(

 

[cando]

Ganz so einfach ist das nicht, wie du dir das vorstellst.

VoIP nutzt dynamische portadressen. mit dem SIP protokoll handelt der server vom provider mit deiner box eine verbindung aus (ich glaube udp 5060) und "vermittelt" die deinem gesprächspartner, mit dem dann über eine dynamische udp adressen die eigendliche sitzung + nutzdaten kanal geöffnet wird. wenn das gespräch zu ende ist, wird über eine neue verbindung zum SIP server dies gemeldet, damit der seine abrechnung machen kann.

die connection regeln sorgen ja dafür, dass nur dann ein firewall port geöffnet wird, wenn mit dem partner tatsächlich eine verbindung vorher initiiert wurde.

connection outgoing-relatet öffnet die firewall für daten von deinem partner, wenn du vorher eine (outbound) verbindung initiiert hast,

connection incomming-relatet öffnet für dich die ports nach aussen, wenn von deinem partner eine verbindung über ein von dir freigegbenes port (inbound) aufgebaut wurde.

in jedem fall muss vorher eine zulässige verbindung (über eine andere gültige portregel) zustande gekommen sein, bevor die firewall für diesen host ein angefordertes port öffnet. das ist viel sicherer gegenüber regeln, die riesen udp segmente grundsätzlich öffnen.


ausserdem kann conntrack mit dynamischen ports umgehen, da er die protokolleigenheiten von VoIP und ftp kennt und nicht einfach alle ports öffnet, sondern nur die, die für die jeweilige sitzung und den jeweiligen partner unbedingt benötigt / angefordert werden. es belauscht so zu sagen den verkehr und interpretiert die verwendeten ports + sitzungspakete.

 

[matze1985]

Das klappt natürlich nur solange man die sachen nicht verschlüsselt.

 

[cando]

das klappt auch wenn man die sachen verschlüsselt. es werden ja nur die portadressen und die routing informationen ausgewertet und die sind immer unverschlüsselt. sonst könnte man ja keine kommunikation über öffentliche netze realisieren.

verschlüsselt werden nur die nutzdaten.

bei vpn verbindungen werden die privaten adressinformationen / routinginformationen als datenpaket verschlüsselt in unverschlüsselte öffentliche transportpakete gepackt, die dann normal von firewalls, routern und anderen netzwerkkomponenten transportiert und zugestellt werden.

 

[gnom2]

wenn ich das nun richtig verstanden habe brauche ich nur 5060 für die Verbindung zum sip und die outgoing-related / incoming-related Regeln das Telefonie läuft?

 

[cando]

ich würde es mal so probieren. ich weiss nicht genau wie der dsld das handhabt, da ich nicht über VoIP telefoniere, in iptables gibt es extra conntrack module für die sprachprotokolle, ftp und instant messenger.

ich nehme mal an, der dsld macht das ähnlich.

in der ar7.cfg steht dazu für das port forwarding auf das Box interface:

        voip_forwardrules = "udp 0.0.0.0:5060 0.0.0.0:5060", 
                            "tcp 0.0.0.0:5060 0.0.0.0:5060", 
                            "udp 0.0.0.0:7078+32 0.0.0.0:7078";

also udp 5060 + tcp 5060 und 32 udp ports ab 7078

 

[gnom2]

thx,
werde ich mal versuchen