SIP-Probleme - same procedure as every thread
-
@FFK:
Im Log werden keine Pakete geblockt, sieht soweit also gut aus. Die entsprechenden VoIP/SIP Pakete kommen auch am PfSense an, werden aber scheinbar still gedroppt?
SIP kommt entsprechend Deiner Konfig sicher an, aber RTP dürfte gedroppt werden. Mach Dir einfach eine auf dem WAN-Interface eine Regel (am Ende), die alles blockt und dabei loggt. Dann siehst Du alles.
@FFK:
NAT -> Port Forwarding:
If Proto Src. addr Src. ports Dest. addr Dest. ports NAT IP NAT Ports WAN UDP * * WAN address 5060 (SIP) 192.168.0.4 5060 (SIP) WAN UDP * * WAN address 5004 (RTP) 192.168.0.4 5004 (RTP) WAN UDP * * WAN address 7077 - 7087 192.168.0.4 7077 - 7087Eine FB hat in der Regel einen Port-Range von 7078 bis 7110 für die RTP-Ports! Bitte die dritte Regel entsprechend anpassen. Regel 2 ist unnötig. Bei der Konfig dürftest Du ein Problem mit one-way-audio haben.
Die RTP-Ports werden paarweise verwendet (7078 und 7079 oder 7080 und 7081), immer einer als Quellport für das Senden von Audiodaten (Deine FB an die andere Seite) und einer als Zielport für die eingehenden Audiodaten (von der anderen Seite in Deine FB). Welchen Zielport die andere Seite verwenden soll, teilt die FB der anderen Seite per SIP mit. Beispiel: 7078 als Quell- und 7079 als Zielport.
Mehrere Paare von Ports werden verwendet, wenn mehrere parallele Telefonverbindungen aufgebaut werden müssen.
@FFK:
NAT-> Outbound (Hybrid Outbound NAT):
Interface Source Source Port Destination Destination Port NAT Address NAT Port Static Port WAN any udp/* * udp/* WAN address * YESSource muß 192.168.0.4/32 sein! Sonst versucht die pfSense alle ausgehenden ports static zu machen.
@FFK:
Firewallrules:
WAN: Proto Source Port Destination Port Gateway Queue Schedule Description IPv4 UDP * * 192.168.0.4 5060 (SIP) * none NAT IPv4 UDP * * 192.168.0.4 5004 (RTP) * none NAT IPv4 UDP * * 192.168.0.4 7077 - 7087 * none NATDie WAN-Rules werden beim Einstellen von NAT automatisch korrekt angelegt. Das muß sich dann entsprechend anpassen.
@FFK:
LAN: Proto Source Port Destination Port Gateway Queue Schedule Description IPv4 UDP * * * 7077 - 7087 * none Easy Rule: Passed from Firewall Log View IPv4 UDP * * * 5060 (SIP) * none Easy Rule: Passed from Firewall Log View IPv4 * * * * * * noneMüßte gehen (Du erlaubst ja alles).
Wenn Du es korrekt konfigurieren willst:
1. Du mußt SIP ausgehend von der FB erlauben: Source ist 102.168.0.4, Zielport 5060, Rest auf any. Im Prinzip hast Du das, evtl. stellst Du das Protokoll auf TCP UND UDP. (SIP kann im Prinzip auf beidem aufsetzen.)
2. Du mußt der FB ausgehenden Traffic mit den Source-Ports (RTP-Ports) 7078 bis 7110 erlauben. (Genau genommen wird nur jeder zweite Port als source-Port verwendet.) Die RTP-Zielports kannst Du nicht steuern, da das nicht von Deiner FB abhängig ist, sondern von den Geräten auf der anderen Seite. Das können komplett andere Ports sein.
Du brauchst STUN nicht. siproxd ist nicht erforderlich.
-
Danke für eure schnellen Antworten! Ich habs nun mal versucht anhand eurer Vorschläge umzusetzen.
Beim Port Forwarding wart ihr euch ja nicht ganz einig - ich habs jetzt einfach mal hinzugefügt.
Zusätzlich hab ich noch den Port 7077 mitgenommen - ich weiß, eigentlich nicht notwendig, aber ich hatte da mal irgendwas gelesen und doppelt hält ja in dem Fall besser^^Das hier kennst du schon?
https://doc.pfsense.org/index.php/VoIP_Configuration
Oh ja, ich glaube ich kann den auch nachts um drei verschlafen aufsagen…In der FritzBox Stun ausschalten.
In der FritzBox Nat Keep Alive runterdrehen als den kleinsten Wert einstellen der geht und dann in der PfSense unter:
System: Advanced: Firewall and NAT
bei UDP Timeouts etwas einstellen das ein wenig höher ist als das Nat Keep Alive in der FritzBoxHmm schwierig. Ich hab am 23.12.15 Abends einen Anruf vom MNet Third-Level-Support bekommen. Er wollte wissen, was wir mit der Box gemacht haben, weil die ja schon auf FW 6.50 läuft. Außerdem erhält er ne Menge SIP-Pings von uns und das System wertet die als Angriff. Und wir sollen das umgehend abschalten, sonst knipsen sie uns früher oder später einfach den ganzen Anschluss aus ;D Er konnte mir zwar nix konkretes sagen, was es ist, warum es passiert und wie ich es deaktiveren kann, aber ich habs dann nach einiger Zeit doch in der FB Config gefunden… Die SIP Pings sind bei MNet standardmäßig komplett deaktiviert. Serverseitig meinte der Mitarbeiter wären es wohl 1200 Sekunden als Timeout oder so... Aber er war sich da nicht sicher.
Ich denke mit NAT Keep Alive meinst du den SIP Ping oder?
Mit dem Fax Problem einfach mal in der FritzBox T.38 ausschalten (denke das es im Moment an ist) und dann nochmal testen.
Ist aktiviert gewesen, aber soweit ich in den Logs gesehen habe wurde es sowieso nicht benutzt… Ist ja nur optional scheinbar.
Aber hier jetzt erstmal die neue Konfiguration:
Aber leider auch gleich der erste Fehler:
Ich verstehe nicht, wieso das geblockt wird?
-> NAT müsste es doch korrekt weiterleiten an die 192.168.0.4
-> auf dem WAN Interface wurde die Regel automatisch vom NAT angelegt und der Port freigegebenWieso also wird das trotzdem geblockt??
P.S.: Ich hätte euch gerne beiden ein Danke gegeben, aber der "Thanks"-Button ist verschwunden -.- gibts da ein Zeitlimit oder sowas?
EDIT:
Shame on me! Hatte keinen Reboot gemacht… Scheinbar gehts mit Hotdeploy nicht so gut :) Nach einem Reboot läuft es erstmal.
Ich melde mich nochmal obs auch so bleibt oder ob es später nach Timeouts noch Probleme gibt!EDIT2:
Ich hab nun auch noch die Portforwards auf TCP/UDP gestellt, weil ab und zu via TCP ein Sync ankam und natürlich dementsprechend geblockt wurde. Ich hoffe das passt so. -
Freut mich zu hören das es nun geht :)
Die Floating Rule würde ich so nicht machen wenn ich das richtig sehe hast du mit dieser ja auf allen Interfaces eine ANY TCP Regel angelegt also auch auf dem WAN und das wollen wir ja eigentlich nicht ;)
Was mich noch interessieren würde wäre ob es ohne das NAT vom WAN zum LAN klappt also die Regel mit 5060 und 7077-7110.
Normalerweise wir das dann Dynamisch generiert. Wichtig ist hier halt dann das keep alive oder SIP Ping.
Mit Alle 20 Sekunden sollte der Provider eigentlich keine Probleme haben. Bei SIP muss man ja irgendwie die Firewall für eingehende Gespräche offenhalten -
@FFK:
Zusätzlich hab ich noch den Port 7077 mitgenommen - ich weiß, eigentlich nicht notwendig, aber ich hatte da mal irgendwas gelesen und doppelt hält ja in dem Fall besser^^
Ja das schadet nicht. Du kannst in Ruhe recherchieren, welche Ports die FB benötigt.
@FFK:
Hmm schwierig. Ich hab am 23.12.15 Abends einen Anruf vom MNet Third-Level-Support bekommen. Er wollte wissen, was wir mit der Box gemacht haben, weil die ja schon auf FW 6.50 läuft. Außerdem erhält er ne Menge SIP-Pings von uns und das System wertet die als Angriff. Und wir sollen das umgehend abschalten, sonst knipsen sie uns früher oder später einfach den ganzen Anschluss aus ;D Er konnte mir zwar nix konkretes sagen, was es ist, warum es passiert und wie ich es deaktiveren kann, aber ich habs dann nach einiger Zeit doch in der FB Config gefunden… Die SIP Pings sind bei MNet standardmäßig komplett deaktiviert. Serverseitig meinte der Mitarbeiter wären es wohl 1200 Sekunden als Timeout oder so... Aber er war sich da nicht sicher.
Das solltest Du nochmal versuchen zu klären. Erstens sollte es möglich sein, daß da eine Auskunft kommt. ob das jett ok ist. Und zweitens wäre es sehr unangenehm, wenn etwas nicht funktioniert, und das dann daran liegt, daß Du abgeklemmt worden bist und womöglich davon nichts mitbekommst. Das verkompliziert die Fehlersuche dann ungemein. :-)
@FFK:
P.S.: Ich hätte euch gerne beiden ein Danke gegeben, aber der "Thanks"-Button ist verschwunden -.- gibts da ein Zeitlimit oder sowas?
Da gibt es links einen Link"[applaud]". Ich glaube der "Thank you" link geht nur einmal pro Thread.
@FFK:
Nach einem Reboot läuft es erstmal.
Ich melde mich nochmal obs auch so bleibt oder ob es später nach Timeouts noch Probleme gibt!Schön!
Und nicht vergessen die Regeln angemessen restriktiv einzustellen. Du kannst Dich ja jetzt von einem funktionierenden Stand aus rantasten.
-
Was mich noch interessieren würde wäre ob es ohne das NAT vom WAN zum LAN klappt also die Regel mit 5060 und 7077-7110.
Normalerweise wir das dann Dynamisch generiert.Das würde mich jetzt (rein aus akademischen Gründen ;D ) auch brennend interessieren. Geht das bei Dir so?
Problem ist der RTP-Port für eingehendes Audio. Der wird m.W. per SIP an die Gegenstelle übermittelt, damit die Gegenstelle dorthin eine Verbindung aufbauen kann. Wenn das ohne Port Forwarding gehen sollte, dann müßte das eigene VoIP-Gerät dazu auf dem Port für eingehendes Audio erstmal eine ausgehende Verbindung öffnen, damit die Firewall die Verbindung kennt. Oder?
Das ist durchaus denkbar. Die Frage ist, ob das ein Standard-Verhalten aller VoIP-Geräte ist, oder ob das eine spezielle Eigenschaft bestimmter Geräte ist. anders ausgedrückt: Klappt ein Setup ohne die Regeln dann für alle denkbaren Geräte oder nur für manche?
-
Das würde mich jetzt (rein aus akademischen Gründen ;D ) auch brennend interessieren. Geht das bei Dir so?
Bei meinem Gigaset DX800A ging das so ja. Auch mit einer FrizBox hatte ich das schon so und es ging.
Daher interessiert es mich eben auch ob das allgemein gültig ist :)Gehen müsste es dann wenn das Gerät die RTP Pakete eben genau auf dem Port erwartet mit dem es seine auch verschickt was ja auch machbar ist.
Wichtig ist dann halt die Outbound NAT Regel mit dem Static Port wenn ich diese gemacht hatte hat es immer geklappt.
Könnte man ja ggf. mal mittracen auf welchem Ports die Pakete erwartet werden und mit welchem Port sie dann verschickt werden.Fände es halt schöner wenn die Ports nur bei Bedarf offen wären und nicht immer ;)
-
Das würde mich jetzt (rein aus akademischen Gründen ;D ) auch brennend interessieren. Geht das bei Dir so?
Bei meinem Gigaset DX800A ging das so ja. Auch mit einer FrizBox hatte ich das schon so und es ging.
Daher interessiert es mich eben auch ob das allgemein gültig ist :)Gehen müsste es dann wenn das Gerät die RTP Pakete eben genau auf dem Port erwartet mit dem es seine auch verschickt was ja auch machbar ist.
Habe das mal nachgelesen.
Erstmal eine kleine Korrektur: Ich habe weiter oben geschrieben, daß Paare von Ports benutzt werden für eingehende und ausgehende Audio-Daten. Das ist falsch. Korrekt ist: Es wird ein Paar benutzt, wobei ein Port mit gerader Nummer für die media-Daten verwendete wird (RTP-Protokoll), der darauffolgende ungerade Port dann für die Steuerungsinformationen (RTCP-Protokoll).
Im SIP-Protokoll wird beim SIP-INVITE ein payload mitgesendet. Hierfür wird SDP verwendet. Damit wird u.a. spezifiziert, wie die Audio-Daten transportiert werden sollen. Der Absender des INVITE (Anrufer) gibt den gewünschten (geraden) port für RTP-Audio-Daten an. (Der darauffolgende ungerade Port für RTCP ist implizit mit spezifiziert.) Nennen wir diesen Port "A".
Bei der Antwort gibt der Eingeladene seinerseits per SDP auf gleiche Weise einen Port für RTP-Daten an. Diese Ports können komplett unterschiedlich sein. Das soll Port "B" sein.
Der Anrufer baut eine RTP-Verbindung von einem selbst gewählten Source Port (z.B. "a") zur Zieladresse mit Port B auf und sendet dort Audiodaten. Der Angerufene baut eine RTP-Verbindung von einem beliebigen Source-Port (hier "b") zu Port A auf der IP-Adresse des Anrufers auf und sendet dort seine Audiodaten.
Die Firewall des Anrufers muß folgendes leisten:
-
Ausgehendes RTP vom Port a zu port B erlauben
-
Eingehendes RTP vom Port b zu Port A erlauben
-
Eingehendes Audio auf die VoIP-Anwendung weiterleiten.
ad 1. Hierfür braucht die Firewall eine Regel auf der LAN-Seite. Der Zielport B ist niemals bekannt, da er von der Gegenseite festgelegt wird. Die Regel kann aber den Source-Port filtern, sofern ein Port-Range dafür bekannt. VoIP-Geräte verwenden wohl in der Regel feste Port-Ranges dafür. Eine FB macht das jedenfalls so. Hierfür wird wohl der Port-Range 7078 bis 7110 verwendet.
ad 2. Der Firewall ist Port b niemals bekannt. Eine Regel kann nur Port A kennen. Hierfür muß bekannt sein, welcher Portrange dafür durch die VoIP-Anwendung genutzt wird. Das ist bei der FB wieder der Portrange 7078 bis 7110.
ad 3. Das erfordert eine Weiterleitungsregel. In der oben beschriebenen Form existiert keine bestehende Verbindung, der Traffic kann also durch die Firewall nicht zugeordnet werden.
Ich habe jetzt mal nachgelesen, warum das auch anders geht: Offenbar ist es tatsächlich die Regel, daß VoIP-Geräte gleiche Ports benutzen. Sprich: im o.a. Beispiel verwenden Anrufer und der Angerufene jeweils die von ihnen festgelegten Zielports auch als Source Ports. (b ist also gleich B, a ist gleich A).
Nun baut also der Anrufer eine RTP-Verbindung von Port A nach Port B auf und sendet Audio. Der Angerufene sendet vom Port B zu Port A ebenfalls Audio. Damit hat die Firewall eine bestehende Verbindung, der sie den eingehenden Traffic zuordnen kann. Das funktioniert auch mit Firewalls auf beiden Seiten. Sitzen beide Seiten hinter einer Firewall, dürften anfangs höchstens ein paar Pakete verlorengehen, bis beide Firewalls eine bestehende Verbindung erkennen.
Für die Firewall verbleibt dann nur diese Anforderung:
- Ausgehendes RTP zu port B erlauben (mit B aus dem Portrange der VoIP-Anwendung)
Eine Firewall, die jeden ausgehenden Traffic erlaubt, wäre damit automatisch richtig für RTP konfiguriert.
Wir können festhalten: Es ist zwar nicht standardkonform, aber für die meisten VoIP-Geräte müßte das Setup auch ohne mit den weniger umfangreichen Regeln funktionieren. Jetzt wäre es noch interessant zu wissen, ob es überhaupt Geräte mit abweichendem Verhalten gibt und ggf. welche.
Wichtig: Es reicht nicht, wenn sich nur eine Seite, z.B. das eigene Gerät, so verhält! Wenn die Gegenstelle nicht so arbeitet, wie hier beschrieben, dann braucht es das volle Set an Regeln. D.h. es kann in der Regel funktionieren, aber abhängig von der Gegenstelle fallweise scheitern. ::)
-
-
Danke für die ausführliche Beschreibung.
Man kann also sagen kommt immer drauf an ;) was man selbst als Gerät hat und welche Gegenstelle es ist.
Bei Telekom und FritzBox kann man sich wohl das eingehende NAT sparen.Ich hoffe das man sich hier auch mal auf einen Standard einigen kann.
-
Also leider doch noch nichts ganz positives zu vermelden…
Es hat rund 24 Stunden gut funktioniert, dann ging es wieder los mit Kommunikationsfehlern.
Ich habe dann festgestellt, dass scheinbar auch noch andere Ports verwendet werden - sah ziemlich zufällig aus.
Irgendwo im Internet habe ich dann gelesen, dass scheinbar bei manchen Providern die Ports 10000-65355 ebenfalls für RTP-Mediadaten verwendet werden können.Diese Portrange habe ich also entsprechend freigegeben. Zusätzlich ist mir aufgefallen, dass die Verbindungen immer aus dem IP-Netz 62.245.0.0/16 kommen, woraufhin ich die Regeln entsprechend angepasst habe (es kamen nämlich zwischenzeitlich auch "fremde" Pakete auf dem 5060er an - zwar nichts gefährliches, aber es wurde fleissig gescannt)
Nun, seitdem ist zwar die Firewall clean (also es kommen in Richtung SIP/Fax keine Blocks mehr), aber es geht trotzdem nicht richtig.
Und zwar funktioniert es konkret so:- Telefon rein/raus scheint zu funktionieren
- Faxe raus von hinterhalb PfSense funktionieren auch wunderbar
- Fax von einer FritzBox auf die FB hinter PfSense -> GEHT!
- Fax von Faxgeräten auf die FB hinter PfSense -> Kommunikationsfehler & Abbruch. Wenn man mithört, dann hört es sich so an, als würden 1-2 Sekunden des Fax-Handshakes vorne verschluckt?!
Wie gesagt, Firewall sieht soweit gut aus - irgendwelche Ideen?
Ich hab schon an der FB mit der Einstellung "is_nat_aware = yes" rumgespielt, aber dann melden sich die Nummern gar nicht mehr an.
Außerdem habe ich natürlich T.38 an und aus gemacht (und jetzt auch aus gelassen), aber ändert sich ebenfalls nix.Screenshots der aktuellen Rules liefere ich in Kürze nach...
Edit: 00:26 Uhr - Beim Faxempfang ist ein Übertragungsfehler aufgetreten. Das Dokument wurde nicht empfangen oder ist unvollständig. (via Fax)
00:28 Uhr - Senden OK (via Fax)
01:12 Uhr - Beim Faxempfang ist ein Übertragungsfehler aufgetreten. Das Dokument wurde nicht empfangen oder ist unvollständig. (via Fax)
01:16 Uhr - Beim Faxempfang ist ein Übertragungsfehler aufgetreten. Das Dokument wurde nicht empfangen oder ist unvollständig. (via FritzBox)
01:20 Uhr - Senden OK (via FritzBox)
??? ??? ??? ???Und die Einstellungen sind jetzt auch da… Dieses sporadische funktionieren, nicht funktionieren geht mir dermaßen auf den Nerv >:(
Natürlich funktioneren die verwendeten Faxe zueinander (also von Anschluss B zu C - beide ohne PfSense) zu 100% zuverlässig!Achso, wegen MNet... Auskünfte kann man da vergessen. Wie gesagt, die Box ist modifiziert und ohne direkten Zugriff darauf durch den Support wird sofort jeglicher Support abgeblockt.
Und zum Third Level Support lassen die mich erst recht nicht durch (der Typ damals hat leider auch mit unterdrückter Nummer angerufen :D )
SIP Ping meinte er aber sei normal komplett deaktiviert - was ja auch klar ist, weil bei der "Zwangsbox" ja zwingend gar keine Firewall dazwischen sein darf... "Normal" kann man die Zwangsbox ja nichtmal so konfigurieren, dass es möglich wäre.
-
bei manchen Providern die Ports 10000-65355 ebenfalls für RTP-Mediadaten
Das wäre ja nur dein Ziel wichtiger für dich ist ja auf was deine Geräte den RTP erwarten.
Vom LAN ins WAN ist normal nicht so das Problem.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.Dann hast du Im LAN Regel die gar nicht zu tragen kommen.
Erst erlaubst du aus den LAN TCP und UDP mit einer /24 Maske und ICMP wieder mit einer /16 Maske.
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.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 InterfaceAuch auf dem WAN sind ein paar Regeln die wohl so nicht zum tragen kommen und ich glaube das du hier etwas falsch verstanden hast.
Die Regel gelten immer für Pakete die auf dem Interface eingehen.
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.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
Ich würde das erst mal alles überarbeiten und dann nochmal schauen wie es sich verhält.
Wegen dem FAX hast du T.38 mal ein bzw. ausgeschaltet und damit mal getestet?
-
@FFK:
Edit: 00:26 Uhr - Beim Faxempfang ist ein Übertragungsfehler aufgetreten. Das Dokument wurde nicht empfangen oder ist unvollständig. (via Fax)
00:28 Uhr - Senden OK (via Fax)
01:12 Uhr - Beim Faxempfang ist ein Übertragungsfehler aufgetreten. Das Dokument wurde nicht empfangen oder ist unvollständig. (via Fax)
01:16 Uhr - Beim Faxempfang ist ein Übertragungsfehler aufgetreten. Das Dokument wurde nicht empfangen oder ist unvollständig. (via FritzBox)
01:20 Uhr - Senden OK (via FritzBox)
??? ??? ??? ???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.
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.
Ein möglicher Workaround (oder eine dauerhafte Lösung?) wäre eine Fax-Nummer über einen Provider, der eine Fax-to-Mail-Funktion anbietet.
-
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.
