Gibt es bzgl. PFSense irgendwelche Besonderheiten zu beachten bei einem WLAN Call von iPhone zu Telekom Mobile?
-
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.
