Gibt es bzgl. PFSense irgendwelche Besonderheiten zu beachten bei einem WLAN Call von iPhone zu Telekom Mobile?
-
@SMehre said in Gibt es bzgl. PFSense irgendwelche Besonderheiten zu beachten bei einem WLAN Call von iPhone zu Telekom Mobile?:
In der FireWall haben wir die VoIP UDP Optimierungen gemacht, die Festnetzanrufe funktionieren auch ohne Probleme.
Auch scheint ja der IPSEC Tunnel möglich, da sonst die WLAN Calls ja nie gehen würden.Gefühlt ist es eher ein Laufzeit Problem, d.h. wenn das gesamte Netzwerk aufgrund Firmwareupdate oder Stromabschaltung
neu gestartet ist, dann funktioniert es erstmal auch für die iPhones über einige Tage ggfls. 1-1,5 Wochen ohne Probleme.
Danach wird es dann eher zu einer 50:50 Chance dass es funktioniert oder eben nicht.Was sind denn bitte die "VoIP UDP Optimierungen"?
Cheers
-
@JeGr said in Gibt es bzgl. PFSense irgendwelche Besonderheiten zu beachten bei einem WLAN Call von iPhone zu Telekom Mobile?:
Was sind denn bitte die "VoIP UDP Optimierungen"?
Cheers
Hierbei geht es ja in erster Linie um die UDP Timeouts, was ja bei VoIP Calls gerne dazu führt dass Verbindungen
nach einigen Minuten während laufendem Call abbrechen.Da gibt es ja unterschiedliche Ansätze. Man kann die UDP Timeouts einzeln anpassen oder das Profil der FireWall
von "Normal" auf "Conservative" stellen, was im Grunde im Hintergrund diese Einstellungen dann anpasst. -
@SMehre said in Gibt es bzgl. PFSense irgendwelche Besonderheiten zu beachten bei einem WLAN Call von iPhone zu Telekom Mobile?:
Da gibt es ja unterschiedliche Ansätze. Man kann die UDP Timeouts einzeln anpassen oder das Profil der FireWall
von "Normal" auf "Conservative" stellen, was im Grunde im Hintergrund diese Einstellungen dann anpasst.Nein, tut sie nicht. Conservative dreht für ALLE Verbindungen egal welchen Protokolls die Timeout Einstellungen massiv nach oben. Das ist für die meisten aber eher unüblich/hinderlich bzw. führt zu massiv längeren States und kann bei einer sehr frequentierten Maschine zum Überlauf von States führen.
Darum frage ich ja welche "UDP Optimierung" - es gibt keine, außer dem manuellen anpassen der 3 UDP Timeouts in System Advanced. Die machen bei schlecht laufenden/konfigurierten VoIP Calls bspw. durchaus Sinn. Die ganze Firewall auf Conservative zu knallen, eher weniger :)
Was bei WiFi/VoIP Calls hilft sind die 3 Werte aus der konservativen Einstellung manuell zu übernehmen, normale Default Settings sonst wiederherzustellen und sicherstellen, dass das Netz aus dem die WiFi Calls kommen für die Geräte die UDP/500 static Port Optimization drin hat. WiFi Calls sind "sloppy" und funktionieren bei Gegenstellen oft sehr dreckig mit dem Pseudo VPN Aufbau. Daher lange UDP Laufzeiten und Gegencheck, dass UDP/500 outbound für das VPN sauber statisch umgeschrieben und nicht geändert wird.
Ist das der Fall?
Cheers :)
-
danke Dir, OK das war mir so bisher nicht bewusst. In der Help der PFsense klang das nach einem
guten Ansatz für VoIP...Conservative:
Tries to avoid dropping any legitimate connections at the expense of increased memory usage and
CPU utilization. Can aid in environments that require long-lived but mostly idle UDP connections,
such as VoIP.Bzgl. Speicher und CPU hatte ich bisher noch nicht das Gefühl, dass hier die Netgate Hardware
6100er oder 4200er kritisch waren. Auch wenn die Firewalls schon einiges zu tun haben.Bzgl. der static Ports für UDP/500 hab ich eigentlich drin, wobei ich noch mehr drin habe was aber
ehrlich gesagt aufgrund meines noch nicht so großen KnowHows hierzu vielleicht auch nicht so
gut ist. Das rührt teilweise auch aus Themen mit 3CX und AGFEO Telefonanlagen und dem einen
oder anderen Problem. Kann durchaus sein, dass hier einige nicht so ideale Einstellungen drin sind.
Aber bisher wurden dann zumindest die Themen gelöst. Für den UDP 500 gibt es ja die automatisch
generierte ISAKMP Regel für alle VLANs.
-
Über diese Einstellungen bin ich schon einige Male gestolpert, aber ich habe noch keine abschließende Information
gefunden welche Einstellungen hier gewählt werden sollten:
D.h. für IP Do-Not-Fragment compatiblity für das allgemeine Packet Processing und für VPN selber. Bzw. auch die IP Random
id generation und Disable Firewall Scrub. Bzw. eben alle Einstellungen bei den VPN Paketen. Was ja gerade bei WLAN Call mit
IPSEC der Fall wäre.In der Help gibt es ja bei den Einstellungen auch Andeutungen auf VoIP, wobei oft eher von seltenen Fällen gesprochen wird.
-
Ich bin mir nicht sicher ob ich es schon erwähnt hatte, aber ich könnte mir vorstellen dass das u.U. einen Hinweis oder eine
Richtung bzgl. des Problems geben könnte.Bei einem Call vom Kunden an mich hatte ich nach kurzer Zeit den Ton digital verzerrt bis der Call dann abgebrochen wurde.
Danach konnte der Kunde für einige Minuten nicht mehr telefonieren, da Mobilfunk im Haus nicht geht und der WLAN Call
wohl nicht mehr möglich war.D.h. es gab eine Verbindung, diese scheint aber wohl dann schlechter zu werden bis hin zum kompletten Abbruch und danach
kann sich das iPhone wohl auch einige Zeit nicht mehr mit einem WLAN Call anmelden. Da verschwindet dann auch die Anzeige,
dass das iPhone eine WLAN Call Verbindung hätte. -
@SMehre said in Gibt es bzgl. PFSense irgendwelche Besonderheiten zu beachten bei einem WLAN Call von iPhone zu Telekom Mobile?:
D.h. es gab eine Verbindung, diese scheint aber wohl dann schlechter zu werden bis hin zum kompletten Abbruch und danach
kann sich das iPhone wohl auch einige Zeit nicht mehr mit einem WLAN Call anmelden. Da verschwindet dann auch die Anzeige,
dass das iPhone eine WLAN Call Verbindung hätte.Das klingt tatsächlich aber nicht nach Firewall. Wäre das der Fall würde der Kontakt nicht graduell schwächer, sondern würde abbrechen und/oder gar nicht erst zu Stande kommen. Das State Handling ist aber sehr solide. Da würde nicht einfach irgendwann was "weniger" werden. Das würde für mich tatsächlich auf ein anderes Problem abseits der Firewall deuten. Denn die obigen Punkte waren eher nötig um überhaupt WiFi Calling zum Fliegen zu bekommen. Wenn das aber läuft, angezeigt wird und der Call rausgeht, dann steht der, dann hat die FW eigentlich nur noch wenig damit zu tun. Dass der dann abreißt klingt eher nach WAN, WiFi oder Verbindungsproblemen.
Cheers :)
-
@JeGr
also dem Grunde nach geht es eigentlich, wie ja auch erwähnt funktioniert es mit meinem Android Handy und
Vodafone soweit ich das als gelegentlicher Besucher vor Ort über einen Tag hin weg mehrfach ohne Probleme.Daher hatte ich die FireWall auch nur bedingt in Verdacht. Was mich nur etwas stutzig macht ist die Tatsache,
dass das iPhone mit Telekom nach einem abgebrochenen Telefonat dann auch häufiger erstmal für einige
Minuten sich nicht mehr mit einem WLAN Call anmeldet. Mit dem WLAN ist es aber weiterhin verbunden,
es hilft dann auch nicht 1x WLAN aus- und wieder einzuschalten. Aber nach mehrfachem AUS/AN oder
eventuell auch warten geht es dann wieder und kann u.U. auch für einige Calls normal laufen.Bzgl. WLAN und grundsätzlichem Internetzugriff ist es halt auch sonderbar, da ja beides noch gegeben ist.
Nur WLAN Calls scheinen für einige Zeit wie geblockt zu sein.Das wiederum hat mich schon etwas in Richtung FireWall denken lassen. Quasi wie wenn immer mehr Pakete
nicht mehr korrekt an kommen (digital verzerrt) bis die Fehler zu hoch werden und dann die Verbindung
abreißt. Dann war ich mir nicht sicher ob es sein könnte dass eine WLAN Call Verbindung dann eventuell
für einige Zeit geblockt sein könnte (Telekom Routing oder FireWall) bzw. vielleicht im gesamten Routing
eigentlich noch belegt ist bis ein interner Timeout dann die Verbindung wieder frei gibt. -
@SMehre said in Gibt es bzgl. PFSense irgendwelche Besonderheiten zu beachten bei einem WLAN Call von iPhone zu Telekom Mobile?:
Das wiederum hat mich schon etwas in Richtung FireWall denken lassen. Quasi wie wenn immer mehr Pakete
nicht mehr korrekt an kommen (digital verzerrt) bis die Fehler zu hoch werden und dann die Verbindung
abreißt. Dann war ich mir nicht sicher ob es sein könnte dass eine WLAN Call Verbindung dann eventuell
für einige Zeit geblockt sein könnte (Telekom Routing oder FireWall) bzw. vielleicht im gesamten Routing
eigentlich noch belegt ist bis ein interner Timeout dann die Verbindung wieder frei gibt.Das gibt mir tatsächlich weniger "Firewall" im Sinne von "blocken" Vibes als vielmehr Congestion oder Verbindungsproblem-Schwingungen. Das hört sich so ein wenig wie MTU Probleme und Co an, die nur manchmal und nur bei größeren Sachen passieren. Aber das zeitliche Problem mit "geht nicht mehr und braucht dann um sich zu erholen" klingt sehr mekrwürdig.
Andere Frage weil es hauptsächlich um iPhones geht: die verbinden sich aber nicht aus Versehen irgendwie wegen ihrem Apple-Gedöns mit irgendwelchen Tunnel Spielchen? Oder machen IPv6? Das hatten wir tatsächlich schon, dass sich hinterher rausgestellt hatte, dass die iPhones da nach irgendeinem iOS Update plötzlich nen phone home VPN aufgerissen haben und darüber dann teils Verbindungen abgewickelt haben, was dann zu diversen MTU Sperenzchen durch den Tunnelbau geführt hat.
Das wäre aber eins der wenigen Dinge, die mir dazu gerade noch einfallen... Hmm... grübel
-
@JeGr said in Gibt es bzgl. PFSense irgendwelche Besonderheiten zu beachten bei einem WLAN Call von iPhone zu Telekom Mobile?:
Das gibt mir tatsächlich weniger "Firewall" im Sinne von "blocken" Vibes als vielmehr Congestion oder Verbindungsproblem-Schwingungen. Das hört sich so ein wenig wie MTU Probleme und Co an, die nur manchmal und nur bei größeren Sachen passieren. Aber das zeitliche Problem mit "geht nicht mehr und braucht dann um sich zu erholen" klingt sehr mekrwürdig.
Andere Frage weil es hauptsächlich um iPhones geht: die verbinden sich aber nicht aus Versehen irgendwie wegen ihrem Apple-Gedöns mit irgendwelchen Tunnel Spielchen? Oder machen IPv6? Das hatten wir tatsächlich schon, dass sich hinterher rausgestellt hatte, dass die iPhones da nach irgendeinem iOS Update plötzlich nen phone home VPN aufgerissen haben und darüber dann teils Verbindungen abgewickelt haben, was dann zu diversen MTU Sperenzchen durch den Tunnelbau geführt hat.
Das wäre aber eins der wenigen Dinge, die mir dazu gerade noch einfallen... Hmm... grübel
danke Dir, ja ich sag ja ich kann es aktuell auch nicht so ganz greifen. Die MTU hatte ich auch in Verdacht. Wobei diese
soweit ich das aktuell sagen kann alles korrekt sein sollte. Für den WAN ist die 1492 und für alle anderen VLAN
Interfaces in der FireWall sind diese bei 1500. Was, soweit ich weiß, korrekt sein müsste.Ob die sich nun mit irgendwelchen Apple Gedöns verbinden wollen, ist mir aktuell noch nicht klar. Tatsache ist, dass die
Nutzer dort einen OpenVPN zu Ihrem eigenen Netzwerk auf den iPhones hätten. Wäre natürlich die Frage ob die das
ggfls. dauerhaft aktiv lassen. IPv6 ist zumindest in der FireWall nicht konfiguriert und sollte eigentlich damit nicht verwendet
werden, ob die iPhones hier trotzdem irgendeinen Mist machen kann ich aktuell nicht sagen. -
Welcher Provider?
Telekom hat ja hin und wieder mal das geilte Peering der Welt und wenn da rein gerätst, hf...
Denn bei WLAN Call ist ja nicht nur das WLAN beteiligt, sondern auch die komplette Infrastruktur bis zum Provider, also in dem Fall auch von einem zum anderen bis du bei der Telekom auf das VOIP GW knallst...Mein Dienst SE2 ist auch bei T-Mobile und ich nutze hier mit den fast Default pf Einstellungen WLAN Call, ohne Probleme.
Es sei denn, das Cabel Segement hat mal wieder Pakethusten...Hier wird also nix auf einen statischen UDP Port im outbound NAT gesetzt oder sonst was, zudem wird auch gleich noch eine random id in die Pakete geschrieben, weil das halt nicht alle Anwendungen sauber können.
Nutze aber selber IPsec und habe daher für den VPN Verkehr IP Fragment Reassemble aktiv und die MSS auf 1328 gesetzt.
-
@NOCling said in Gibt es bzgl. PFSense irgendwelche Besonderheiten zu beachten bei einem WLAN Call von iPhone zu Telekom Mobile?:
Welcher Provider?
Telekom hat ja hin und wieder mal das geilte Peering der Welt und wenn da rein gerätst, hf...
Denn bei WLAN Call ist ja nicht nur das WLAN beteiligt, sondern auch die komplette Infrastruktur bis zum Provider, also in dem Fall auch von einem zum anderen bis du bei der Telekom auf das VOIP GW knallst...Mein Dienst SE2 ist auch bei T-Mobile und ich nutze hier mit den fast Default pf Einstellungen WLAN Call, ohne Probleme.
Es sei denn, das Cabel Segement hat mal wieder Pakethusten...Hier wird also nix auf einen statischen UDP Port im outbound NAT gesetzt oder sonst was, zudem wird auch gleich noch eine random id in die Pakete geschrieben, weil das halt nicht alle Anwendungen sauber können.
Nutze aber selber IPsec und habe daher für den VPN Verkehr IP Fragment Reassemble aktiv und die MSS auf 1328 gesetzt.
Was meinst Du mit welcher Provider? Festnetz I-Net oder Mobilfunk? wobei egal:
vor Ort ist es ein Telekom Magenta TV VDSL mit so 150 Mbit/s I-Net Anschluss. Beim Kunden und den betroffenen iPhones
(unterschiedliche Modelle) sind es Telekom Mobilfunkverträge (die genauen weiß ich nicht). Wie schon erwähnt scheint es
mit meinem Android Handy und Vodafone diese Probleme nicht zu geben. Aber ich bin natürlich auch nicht so oft vor Ort,
vielleicht hab ich auch nur Glück :)Danke, dessen bin ich mir bewusst und ich selbst habe auch nicht die Erwartung dass WLAN Call immer und zu jedem
100%ig funktioniert. Das kommuniziere ich so auch. Dafür sind viel zu viele Einflüsse außerhalb des Einflusses des Nutzers
und der IT Verwaltung noch eingebunden. Ich glaube das ist dem Nutzer auch bewusst, ein gelegentlicher Abbruch wäre
vermutlich auch nicht das Problem. Das Problem ist eher, dass häufiger für etliche Minuten nicht wieder zurückgerufen
bzw. er selbst erneut angerufen werden kann. Das Handy ist dann für die Gegenstelle nicht erreichbar und er kann keinen
Call starten. Soweit ich das beurteilen kann kann das iPhone in diesem Zustand sich nicht mit einer WLAN Call Verbindung
anmelden. Soweit man sieht ist WLAN noch da auch mit einigen "Balken" (für den Nutzer) aber das iPhone meldet keine
WLAN Call Verbindung.Nach einigen Minuten geht es dann wieder, dann auch ggfls. für mehrere Minuten für einen ganzen Call.
Meinst Du die Einstellungen für "Random ID", IP Fragment Reassemble und MSS könnten hier relevant sein?
VPN wird hier eigentlich nur über OpenVPN genutzt, aber der WLAN Call basiert natürlich auf dem IPSEC Tunnel. -
noch zwei Gedanken, ist die Internetverbindung stabil
und hat eine statische IP? -
@slu said in Gibt es bzgl. PFSense irgendwelche Besonderheiten zu beachten bei einem WLAN Call von iPhone zu Telekom Mobile?:
noch zwei Gedanken, ist die Internetverbindung stabil
und hat eine statische IP?nun, soweit ich das sagen kann sollte diese stabil sein. Zum einen ist in den Logs nichts auffälliges zu sehen und
zum anderen hatte ich nun schon einige Male mit einem Dauerping durchs Haus laufend die Zeiten in Richtung
Internet (glaube google.de) getestet. Es gab 2-3 Ecken bei denen die Zeiten mal leichte Ausreißer hatten, aber diese
Ecken sind etwas schlechter mit APs abgedeckt und da dauert das Umbuchen ein klein wenig länger.
Ansonsten waren die Zeiten eigentlich immer recht ordentlich und nie komplett abgerissen.Aber das schließt natürlich nicht aus, dass zu ganz bestimmten Zeiten u.U. das Internet mal instabil wäre.
Wobei dann müsste ich in den Logs der PFsense ja etwas sehen und da war nichts.Ich hatte auch schon das Gefühl, dass ggfls. ein Refresh der Internetverbindung hilft. Wobei ich mache aktuell
jede Nacht einen erzwungenen Reconnect der Internetverbindung, das scheint es aber nicht gewesen zu sein. -
Dafür richtest du doch einfach mal sauber das Monitoring in der pf für das WAN GW ein.
Dann kannst du sehen ob an dem Zeitpunkt ggf. das WAN mal ein wenig lost hatte.
Und es gibt auch nur eine WAN Verbindung?
Sonst muss dich gleich um die Stickyness kümmern.Das die Clients Netzhopping machen kannst auch ausschließen? Sprich auf bestimmten APs im falschen VLAN oder gar keinem landen?
Weil States sind jetzt swid 24.03 Int bound und nicht mehr Floating based.
-
@NOCling said in Gibt es bzgl. PFSense irgendwelche Besonderheiten zu beachten bei einem WLAN Call von iPhone zu Telekom Mobile?:
Dafür richtest du doch einfach mal sauber das Monitoring in der pf für das WAN GW ein.
Dann kannst du sehen ob an dem Zeitpunkt ggf. das WAN mal ein wenig lost hatte.
Und es gibt auch nur eine WAN Verbindung?
Sonst muss dich gleich um die Stickyness kümmern.Das die Clients Netzhopping machen kannst auch ausschließen? Sprich auf bestimmten APs im falschen VLAN oder gar keinem landen?
Weil States sind jetzt swid 24.03 Int bound und nicht mehr Floating based.
Das hab ich glaube ich, muss nochmal nachsehen. Ich glaube ich hatte es mal
bei einem anderen Kunden rausgenommen, da in einer FW-Version oder am
Anschluss ein Problem war und da hatte zumindest der automatische Refresh
zu noch mehr Problemen geführt.Ja, nur ein WAN in diesem Fall.
Nun, hopping der Clients vielleicht nicht zu absolut 100%. Aber es gibt auf allen
APs die für die Clients relevante SSID, in diversen Tests habe ich auch wunderbar
gesehen, dass die Clients von AP zu AP innerhalb des richtigen VLAN springen.
Ich sehe die Clients auch immer im richtigen VLAN, also bis auf dass es u.U.
vielleicht wirklich mal zu einem ganz seltenen Fall kurzzeitig passiert, kann ich
es ausschließen.Wenn sie in keinem landen würden, dann würde ja auch Internet nicht mehr
funktionieren. Bisher habe ich aber immer die Meldungen gehabt, dass WhatsApp
oder E-Mails dann immer noch funktioniert hat. Nur SMS und der WLAN Call
wurde mir als Problem gemeldet. D.h. die Clients müssen noch mit dem WLAN,
dem VLAN und dem Grunde nach mit dem Internet verbunden gewesen sein.Aktuell ist diese FireWall noch auf 24.03, hier habe ich noch kein Update auf 24.11
gemacht. Bei mir schon, aber ich betreibe aktuellste Firmware eigentlich immer
erstmal einige Wochen/Monate bei mir bevor ich Kundensysteme aktualisiere.Ich hatte gestern nochmal die FireWall Konfig mit anderen verglichen und hatte
(warum auch immer) tatsächlich noch Unterschiede gefunden:- Advanced > FireWall & NAT > Hardware Checksum Offloading: war hier noch aktiv, ist jetzt aus (wie eigentlich in allen anderen FW)
- Advanced > FireWall & NAT > Firewall Optimization Options: steht jetzt wieder auf Normal + Erhöhung der UDP timeouts
- Advanced > FireWall & NAT > IP Do-Not-Fragment compatibility: war an, ist jetzt mal aus
Ich habe hier aktuell auch die erwähnten VPN Einstellungen hierzu nicht gesetzt, ggfls. teste ich die dann noch.
Mal sehen ob damit in den nächsten Tagen/Wochen eine Änderung feststellbar ist.
