SIP-Probleme - same procedure as every thread
-
Bzgl. T.38: Ich habe kein Fax und auch keine entsprechenden Erfahrungen mit Fax über VoIP. Aber was ich über T.38 weiß ist, daß das genau dafür da sein sollte, um das zu ermöglichen. Die Modems der Faxgeräte können über die Codes bei VoIP halt nicht vernünftig kommunizieren.
Das Stimmt es ist genau dafür gemacht. Ich mache das auch beruflich und ich weiß aus der Praxis das es mehr Probleme macht als es hiflt.
In der Regel fährt man mit G.711 besser. Ist zwar doof aber leider ist es in der Praxis so.Wenn ein Connect zustande kommt aber kein Fax drüber geht könnte es immer noch eine einseitige Verständigung sein also doch ein Firewall Thema.
Leider steht ja im Log nur Fax wurde nicht empfangen oder ist unvollständig.
Die Programm geben da oft leider zu wenig Infos. -
Ich kann kann nur spekulieren … Aber wenn Telefon zuverlässig komplett geht, dann ist one way audio ja offenbar kein Problem. Beide Geräte sollten sich also gegenseitig hören können. Es ist also mit sagen wir mal "sehr hoher Wahrscheinlichkeit" ein Codec-Problem.
Habe ich das richtig im Kopf, daß eine Einstellung von G.711 auch eine Sache des Providers ist? Oder ist das eine reine Client-Angelegenheit?
-
Was mir noch auffällt ist deine Floating Regel für was hast du die drin?
Diese Regel erlaubt auf allen Interfaces TCP auch auf dem WAN und das wollen wir ja eigentlich nicht.Diese Regel wurde mir im Support-Chat empfohlen. In der Regel selbst ist "Any Flags" und "Sloppy State" aktiviert. Das sollte wohl verhindern, dass bereits getrennte Verbindungen einen Firewall-Eintrag generieren, wenn sie erneut per TCP Paket getrennt werden.
Was bedeutet die Floating-Regel eigentlich? Wann kommt die genau zum Tragen?Erst erlaubst du aus den LAN TCP und UDP mit einer /24 Maske und ICMP wieder mit einer /16 Maske.
Soweit sollte das doch passen oder? Ich will aus dem 192.168.0.0/16er ICMP erlauben, aber nur aus dem /24er TCP und UDP erlauben. ICMP ist ja, dachte ich, Ping und TCP/UDP "Diverses"
Und dann erlaubst du nochmal Port 5060 von deiner FritzBox. Das hast du ja aber schon mit der ersten Regel gemacht und bringt daher nix.
Ja, das ist korrekt, das ist wohl doppelt gemoppelt. Liegt daran, dass es die Regel zuerst gab und die erste Regel erst später dazukam… Werde ich deaktivieren.
Wake on Lan basiert auf MAC Adressen bleibt daher lokal und damit hat die PfSense nix zu tun muss also auch nicht freigegeben werden.
Wake on Lan schicken kann sie trotzdem da geht ja nix in das LAN InterfaceHmm, die hatte ich aber komischerweise im Firewall Log drin? Hab die von dort übernommen und nur die IP "gewildcarded". Eventuell wurde hier eine falsche Anfrage generiert, sprich das WoL an die falsche IP geschickt, sodass es "raus" ging.
Eventuell weil sie an die Broadcast-Adresse ging oder so? Werde ich bei Gelegenheit prüfen.Die Regel gelten immer für Pakete die auf dem Interface eingehen.
Ja, das dachte ich auch, bis auf einmal merkwürdige Sachen im Log dazu standen. Kann ein Rechner im LAN Pakete auf das WAN-Interface schicken oder ist dann was größeres kaputt? :D
Weil du hast da auf dem WAN eine Regel die als Destination 62.245.0.0/16 hat. Aber auf dem WAN Interface können bei dir keine Pakete Richtung 62.245.0.0/16 gehen weil das bedeuten würde das diese Netz hinter deiner PfSense sein müsset was ja aber nicht so ist.
Nur aus dem LAN kann etwas Richtung 62.245.0.0/16 gehen. Aber das hast du mit deiner TCP/UDP Regel und dem * ja schon drin.Das ist aber genau das, was passiert ist, meine ich… Aber ich werde es nochmal prüfen, vielleicht habe ich mich da verguckt.
Auch z.B. mit dem Regel "Dropbox outgoing" erlaubst du jedem von extern vollen Zugriff auf das Webinterface deiner PfSense. Ist das gewollt? Im Normalfall nicht
Jetzt hast du mir kurz einen Schrecken eingejagt :D Nein, das soll natürlich nicht so sein. Geht aber auch nicht (habs gerade getestet).
Die Regel lässt Traffic durch, der als Source die WAN-Adresse (also die eigene IP) hat und als Ziel-Port 443 (also https).
Hier bin ich mir 100% sicher, dass das so im Log stand! Die eigene WAN-IP-Adresse hat eine Verbindung zu 5.9x.xxx.xxx:443 hergestellt. Recherchen und Hostname-Auflösung haben zu Dropbox geführt (die wir auch nutzen). Ist wohl was zum syncen.
Aber bitte frag mich nicht, wieso das auf dem Interface WAN lief! Ich hab mich auch gewundert.Wegen dem FAX hast du T.38 mal ein bzw. ausgeschaltet und damit mal getestet?
Ja, hab ich gemacht. Kein Unterschied festzustellen. Laut Recherchen unterstützt MNet sowieso kein T.38 (was auch meine bisherigen Erfahrungen bestätigten).Ist das ein Auszug aus dem Log der FB?
Dann dürfte die Verbindung zwischen den Geräten ja grundsätzlich zustandekommen, aber die Kommunikation schlägt fehl. Das heißt, daß das Problem nicht in der Firewall liegt.Ja, aus der FB. Wie gesagt, ich habe an der Firewall auch nichts gesehen. Beim Fax kann man ja "mithören" und ich höre ganz kurz das Quietschen. Also die Verbindung steht erstmal.
Anschließend wird die Verbindung entweder schlagartig durch die Firewall getrennt oder die FritzBox legt auf, weil der Handshake nicht klappt - letzteres wäre halt komisch, weils mit einer anderen FB ja klappt.
Dieses sporadische funktionieren und nicht funktionieren würde zwar auch für Kommunikationsfehler sprechen, aber wenn ich die FritzBox ohne PfSense hinhänge ist die Erfolgsquote 99,9% - war das Setup im letzten halben Jahr, weil PfSense nicht erfolgreich eingerichtet werden konnte…Ein möglicher Workaround (oder eine dauerhafte Lösung?) wäre eine Fax-Nummer über einen Provider, der eine Fax-to-Mail-Funktion anbietet.
Leider nein… Wir haben das Problem, dass die Faxe dem Dienstgeheimnis unterliegen (wir sind eine Feuerwehr) und wir das so nicht machen dürfen. Deswegen muss die FritzBox auch hinter die Firewall und darf nicht davor stehen... Sind spezielle Sicherheitsregelungen.
Das Stimmt es ist genau dafür gemacht. Ich mache das auch beruflich und ich weiß aus der Praxis das es mehr Probleme macht als es hiflt.
In der Regel fährt man mit G.711 besser. Ist zwar doof aber leider ist es in der Praxis so.Die Erfahrung habe ich auch gemacht. 90% der Fälle kommt sowieso ein Fallback auf G.711, weil Sender, Emfänger oder Knoten dazwischen T.38 nicht unterstützt. Und wenn es doch mal geht, dann geht's meistens auch nicht :D
Wenn ein Connect zustande kommt aber kein Fax drüber geht könnte es immer noch eine einseitige Verständigung sein also doch ein Firewall Thema.
Leider steht ja im Log nur Fax wurde nicht empfangen oder ist unvollständig.
Die Programm geben da oft leider zu wenig Infos.Gibts denn eine Möglichkeit das irgendwie mitzuschneiden/zu loggen, was genau passiert? Mit dem Packet-Capture evtl? (Ich werde da nur nicht so schlau draus…)
Ich kann kann nur spekulieren … Aber wenn Telefon zuverlässig komplett geht, dann ist one way audio ja offenbar kein Problem. Beide Geräte sollten sich also gegenseitig hören können. Es ist also mit sagen wir mal "sehr hoher Wahrscheinlichkeit" ein Codec-Problem.
Habe ich das richtig im Kopf, daß eine Einstellung von G.711 auch eine Sache des Providers ist? Oder ist das eine reine Client-Angelegenheit?
Gute Frage. Jedoch sehe ich im Log der FritzBox, dass eben jener Codec verwendet wurde. Siehe Screenshot.
-
Jetzt hast du mir kurz einen Schrecken eingejagt :D Nein, das soll natürlich nicht so sein. Geht aber auch nicht (habs gerade getestet).
Die Regel lässt Traffic durch, der als Source die WAN-Adresse (also die eigene IP) hat und als Ziel-Port 443 (also https).
Hier bin ich mir 100% sicher, dass das so im Log stand! Die eigene WAN-IP-Adresse hat eine Verbindung zu 5.9x.xxx.xxx:443 hergestellt. Recherchen und Hostname-Auflösung haben zu Dropbox geführt (die wir auch nutzen). Ist wohl was zum syncen.
Aber bitte frag mich nicht, wieso das auf dem Interface WAN lief! Ich hab mich auch gewundert.Stimmt hatte mich verschaut.
Aber wichtig ist nicht alles was im Firewall log steht wird geblock weil die Ports nicht offen sind. Kann auch sein das das TCP Syn nicht richtig gelaufen ist.
Wenn die Firewall z.B. ein SYN-ACK bekommt ohne vorher ein SYN dann blockt sie das auch. Daher können so Einträge kommen.
Wenn du vom LAN zum WAN Dropbox machen willst brauchst du diese spezielle Regel nicht.Floating Regeln sind Regeln die für alle Interfaces gelten braucht man nicht soo oft.
Wegen dem FAX hast du T.38 mal ein bzw. ausgeschaltet und damit mal getestet?
Ja, hab ich gemacht. Kein Unterschied festzustellen. Laut Recherchen unterstützt MNet sowieso kein T.38 (was auch meine bisherigen Erfahrungen bestätigten).Dann ausschalten.
Gibts denn eine Möglichkeit das irgendwie mitzuschneiden/zu loggen, was genau passiert? Mit dem Packet-Capture evtl? (Ich werde da nur nicht so schlau draus…)
Kann man nur die Analyse ist eben nicht so einfach gerade bei Fax braucht man da spezielle Tools. Leider bin ich was das angeht auch nicht so fit.
Man kann da nur mal schauen ob es da vielleicht Delay, Paketloss oder Jitter gibt.
Bei normaler Sprache ist das nicht ganz so schlimm bei Fax müssen diese Werte stimmen. -
Aber wichtig ist nicht alles was im Firewall log steht wird geblock weil die Ports nicht offen sind. Kann auch sein das das TCP Syn nicht richtig gelaufen ist.
Wenn die Firewall z.B. ein SYN-ACK bekommt ohne vorher ein SYN dann blockt sie das auch. Daher können so Einträge kommen.
Wenn du vom LAN zum WAN Dropbox machen willst brauchst du diese spezielle Regel nicht.Dafür ist angeblich die Floating-Regel. Dass genau diese Einträge eben nicht mehr erscheinen - so hab ich das zumindest verstanden… Englische Fachbegriffe sind ja so eine Sache^^
Dann ausschalten.
Ist aus.
Übrigens:
Heute haben alle Faxe auf Anhieb funktioniert (bisher 5 oder 6 Stück an der Zahl). Keine Fehler, keine Probleme, egal von welchem Gerät.
Ich habe seit gestern noch nichts weiter geändert. Die einzige Änderung ist, dass sich der PfSense nachts neu eingewählt hat.
Kann man da evtl. auch einfach mal ne scheiss Leitung erwischen? Gerade wenn ich PfSense 30x neu starte…
Das würde zumindest einiges erklären! -
Klingt doch schon mal besser.
Die einzige Änderung ist, dass sich der PfSense nachts neu eingewählt hat.
Warum macht sie das?
Hast du das eingestellt?
Weil normal wenn du VDSL hast oder VOIP sollte es keine Zwangstrennung mehr geben.
Bei der Telekom ist das so.Wäre ja auch doof wenn man mal nachts telefonieren will und hat dann Zwangstrennung.
Weißt du ob dein Provider Zwangstrennung macht?
-
Warum macht sie das?
Hast du das eingestellt?
Weil normal wenn du VDSL hast oder VOIP sollte es keine Zwangstrennung mehr geben.
Bei der Telekom ist das so.Wäre ja auch doof wenn man mal nachts telefonieren will und hat dann Zwangstrennung.
Weißt du ob dein Provider Zwangstrennung macht?
Ja, ich gehe stark davon aus. Bisher habe ich nur davon gehört, dass es bei Telekom und Kabel Deutschland Business wohl weggefallen ist.
MNet hat bisher immer getrennt.Und ja, beim Telefonieren ist das sehr nervig :D Beim alten Privatanschluss von KabelD hatte ich das sehr häufig, wenn ich nachts telefoniert habe…
-
Moin,
habe gerade mal nachgeschaut: KD, jetzt Vodafone, verbunden seit 26.11.2015, 09:22 Uhr, also fast schon statische IP ;)
-teddy
-
Finde ich persönlich ja ein Unding.
Wenn dann All over IP dann aber auch immer IP da.
Weil egal wann du die Zwangstrennung machst irgendwann wird auch bestimmt da mal telefoniert oder IP TV geschaut.Bei der Telekom habe ich das Problem zwar nicht, würde mich bei meinem Provider aber mal beschweren wenn ich das so hätte, weil so kann das ja nicht sein finde ich.
-
Um nochmal ein abschließendes Feedback zu geben:
Alles funktioniert wie es sein sollte - endlich…Sollte jemand mal diesen Thread finden und Hilfe brauchen - einfach kurz eine PN mit Verweis auf einen eigenen Thread an mich schicken! Werde es mir dann mal ansehen...
Danke an alle für die großartige Hilfe!
