Gibt es bzgl. PFSense irgendwelche Besonderheiten zu beachten bei einem WLAN Call von iPhone zu Telekom Mobile?
-
machst Du in dem Netz auch ipv6?
-
@slu said in Gibt es bzgl. PFSense irgendwelche Besonderheiten zu beachten bei einem WLAN Call von iPhone zu Telekom Mobile?:
machst Du in dem Netz auch ipv6?
Nein, aktuell tatsächlich nicht. Wir sind da noch sehr verhalten was IPv6 betrifft.
-
das wäre mit noch als Unterschied zum iPhone eingefallen....
-
@slu said in Gibt es bzgl. PFSense irgendwelche Besonderheiten zu beachten bei einem WLAN Call von iPhone zu Telekom Mobile?:
das wäre mit noch als Unterschied zum iPhone eingefallen....
Du meinst mein Android würde kein IPv6 versuchen das iPhone aber schon?
Dem Grunde nach haben wir in der PFsense eigentlich keinen IPv6 DHCP Server, das Gateway dafür
nicht eingerichtet usw. Ich denke alle Netzwerkgeräte müsste erkennen können, dass diese IPv4
verwenden müssen/sollen. Hier wird denen auch eine fixe IP zugewiesen. -
wenn es nicht konfiguriert ist wird es daran nicht liegen, es war nur ein Verdacht.
Ich fürchte Du wirst um ein Packet Capture nicht herum kommen, man braucht einfach mehr Daten zum gezielt zu suchen. -
@slu said in Gibt es bzgl. PFSense irgendwelche Besonderheiten zu beachten bei einem WLAN Call von iPhone zu Telekom Mobile?:
wenn es nicht konfiguriert ist wird es daran nicht liegen, es war nur ein Verdacht.
Ich fürchte Du wirst um ein Packet Capture nicht herum kommen, man braucht einfach mehr Daten zum gezielt zu suchen.danke Dir, vermute ich auch. Problem ist die betroffenen iPhones sind nicht immer da, das Problem tritt nicht immer
auf usw.Aber vermutlich wird es irgendwie ein Langzeitcapturing sein müssen. Und der Nutzer muss mir dann möglichst exakte
Zeitpunkte nennen. -
@SMehre said in Gibt es bzgl. PFSense irgendwelche Besonderheiten zu beachten bei einem WLAN Call von iPhone zu Telekom Mobile?:
Leider hatte ich bisher kein iPhone für meinen Vodafone Vertrag zur Hand und auch das iPhone des Kunden bzw.
dessen Mobilfunkvertrag einfach auf ein Android Handy zu bekommen ist auch nicht so einfach umsetzbar.Da kann man doch eigentlich (zumindest bei eSIM) einen QR-Code erzeugen, den einfach abfotografieren und schon hat das anderen Gerät den Vertrag.
Bei SIM-Karten würd ich mal einen Congstar-Prepaid für 9,90 Euro kaufen. Für den test im Android kein problem, die weitaus meisten haben doch Dual-SIM. Congstar ist 100%-Telekom Tochter für Prepaid. Alles genau wie bei Original Telekom auch.
-
Hast du Fast Roaming im WLAN für die Apple Geräte aktiv?
Ich habe das hier für meine UI Aps und auf der Arbeit in der Cisco Infrastruktur haben wir das nicht aktiv, da gibt es auch schon mal Probleme mit der WLAN Telefonie.
Wenn du also keine Altlasten im WLAN hast, wovon ich mal ausgehe, dann kontrolliere hier mal die Parameter bezüglich fast Roaming.
Jedes iPhone kann das und damit kann es dann ohne Unterbrechungen von einem AP zum anderen roamen.
Und Roaming ist immer Client gesteuert, das kannst du nicht über die Infrastruktur regeln, bzw. willst du gar nicht, weil du dir damit noch mehr Probleme schaffst als du löst.
Auch Band Steering vergessen, das sollen die Clients wenn über die Treibereinstellungen selber machen.
Auch sollte man den Controller die Sendeleistung und Kanäle der APs selber regeln lassen, der kann das meist besser, weil dynamisch, als wenn man da selber Hand anlegt.
Wir setzen das nur, wenn die Anwendung das benötigt und nur so zertifiziert betrieben werden kann.
Ansonsten laufen mehrere hundert APs pro Standort auf Auto, was Pegel und Kanäle angeht.Hilfreich ist jetzt, die MAC von den Geräten zu bekommen die Probleme machen um dann die Telemetriedaten aus zu werten, dass sollte doch bei Ruckus auch möglich sein.
Vielleicht kannst du ja sogar über den Controller hier einen DUMP erzeugen, das du jedes Beacon vom Client siehst, was er mit dem jeweiligen AP getauscht hat. -
@NOCling
danke Dir, ja ich hatte sowohl FastRoaming an und aktuell auch mal aus, ich hatte den Wert für das FastRoaming
mal erhöht und abgesenkt, also diverse Punkte diesbezüglich versucht. Irgendwie war leider keine Anpassung von
Dauer.Es geht ja dann immer erstmal einige Zeit und dann kommt es wieder zu Problemen. Gefühlt auch wenn man
Änderungen vorgenommen hat einige Zeit besser und irgendwann schlechter. Aber ich konnte es bisher an
nichts festmachen. D.h. Reboot FireWall, Reboot Modem, Reboot WLAN alle APs, Reboot Switche. Irgendwie
scheinen Anpassungen im Netzwerk schon Auswirkungen zu haben, aber nur für einige Zeit.Aber eventuell täuscht das auch und es funktioniert halt einfach einige Zeit wieder und dann wieder nicht.
Die MAC Adressen habe ich und vermutlich muss ich hier wirklich mal den Traffic der iPhones loggen.
-
@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.
