Gibt es bzgl. PFSense irgendwelche Besonderheiten zu beachten bei einem WLAN Call von iPhone zu Telekom Mobile?
-
Nein, ich habe Telekom Mobile und nutze bei mir zuhause WLAN Call (da meine Fenster beschichtet sind) läuft alles super ohne Probleme.
Ich habe bei mir nur UBNT APs und nichts weiter Konfiguriert. -
OK, danke schonmal für die Info.
Verwendest Du Telekom DNS Server oder auch Google oder andere? meine gelesen
zu haben zumindest bei der Festnetztelefonie über VoIP der Telekom hatten einige
Probleme wenn kein Telekom DNS Server verwendet wurde. -
-
danke
Daran hatte ich auch gedacht, aber ich habe schon so vieles durch und das ändert
irgendwie alles nichts. Ich habe die Schwellengrenze für den Wechsel geändert,
ich habe die Sendeleistungen angepasst usw.Ich kann es natürlich nicht 100%ig ausschließen, aber ich wüsste auch nicht mehr
was ich hier noch ändern soll. Zumal es eben "leider" auch nicht immer zu Problemen
kommt.OK, aber ich nehme hier auf jeden Fall mal mit dass Einstellungen in der FireWall
wohl keinen Einfluss haben wird. Das wäre auch schon mal gut zu wissen. Das
hätte mich auch gewundert, da ich auch der Meinung war wenn der IPSEC Tunnel
aufgebaut werden kann, dann ist die FireWall soweit klar.Zuletzt hatte nur alles in Richtung iPhone und/oder Telekom gedeutet, was mich
zu der Frage geführt hat ob die Telekom u.U. etwas besonderes braucht oder ob
es da in der FireWall doch etwas zu berücksichtigen gibt in dieser Konstellation. -
@SMehre said in Gibt es bzgl. PFSense irgendwelche Besonderheiten zu beachten bei einem WLAN Call von iPhone zu Telekom Mobile?:
Ich bin für jede Art von Idee dankbar, da wir so langsam nicht mehr wissen an welcher Stelle wir suchen sollen
Du hast offenbar zwei mögliche Fehlerquellen
- das Telekom-Mobifunknetz
- die IPhones
So wie ich das lese hast du bisher nur Test durchgeführt mit deinem Android im Vodafon-Netz und im Vergleich den IPhones im Telekom-Netz
Um den Fehler näher einzugrenzen solltes du aber eben zum Vergleich auch die IPhone im Netz von Vodafon und und ein Android im Netz von Telkom testen.
Wandert der Fehler nach dem Wechsel des Netzes dann vom iPhone zum Android mit, dann liegt es am Netz. Bleibt der Fehler auch beim anderem Netz beim iPhone ist es das iPhone.
Ich denke erst wenn du das sicher eingrenzen kannst, kannst du das Problem lösen. -
@eagle61
danke Dir, da könntest Du recht haben.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.Aber ja, ich dachte auch schon dran einen Kollegen mit iPhone bzw. Bekannten mit iPhone und Telekom Vertrag
mal hier mit einzubeziehen.Vermutlich wird es nur auf dem Weg mal nachstellbar sein, wobei wie erwähnt das Problem ja leider nicht immer
auftritt. Könnte natürlich sein dass das wieder einen Tag lang normal funktioniert.Wir hatten ja schon einige Dinge und irgendwie hatten wir es immer gelöst bekommen, aber das hier ist echt
schwierig zu greifen. -
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.
