Models vs. Firewall

Hallo Zusammen,

seit einiger Zeit habe ich Probleme mein Model S im Heimischen WLAN zu erreichen. Bis Ver. 6.1(2.2.115) funktionierte es noch problemlos, doch nun seit den nachfolgenden Versionen habe ich das Problem, dass das Model S gar nicht „versucht“ die VPN Verbindung via 1194 UDP aufzubauen. Ich habe auch eine Port-Forwarding Rule aktiv, dass braucht das openvpn sowieso.

Es gibt ganz „seltene“ Momente, bei denen es eine Kommunikation gibt - da sehe ich dann, dass es funktioniert (die Regeln sollten eigentlich passen). Diese Momente sind leider nur sehr sporadisch …

Im Model S kann man problemlos surfen, Musik hören etc. - also prinzipiell ist Konnektivität vorhanden.

In den Firewall-Logs sieht man auch, dass zahllose Zeitserver mit hoher Frequenz abgefragt werden - aber kein Traffic via 1194 UDP!! Ein Reboot der Center-Console hat auch nichts gebracht :wink:

Wenn ich unterwegs bin und das Fahrzeug im 3G resp. Edge Netz ist, funktioniert die Kommunikation - hm, grübel …

Bin jetzt ziemlich ratlos. Habt Ihr ähnliche Erfahrungen gemacht? Oder kann mir jemand erklären, wie die Kommunikation mit Smartphone und Co. wirklich funktioniert? Meine Theorie ist:

Handy und Co. kommunizieren via https mit den Tesla-Servern, diese geben die Informationen aus der vpn-Kommunikation Fahrzeug - Tesla-Server weiter, so ähnlich wie auch Teamviewer arbeitet …

Bin für jegliche Inputs dankbar - vielleicht gibt’s ja auch via OTA bald eine „Spontanheilung“ ??

Cheers

Habe ähnliche Probleme mit dem heimischen WLAN.
Meine Anfrage im SC ob iwelche Ports freigegeben müßten wurde verneint
Appzugriff im Heim-WLAN ist reine Glückssache.

Grüße

Eric

Hallo zusammen,

ich habe das Problem auch bei „ServiceHelpEU“ von Tesla deponiert. Als Antwort, übrigens sehr schnell, bekam ich das folgende:

„Bitte versuche Sie zunächst Folgendes, öffnen Sie die Ports TCP 443, TCP 943, UDP 1194, um Zugriff aufs Internet zu bekommen…“

Ok, zusätzlich sollte man noch das Übliche: 123 (UDP - Network Time Protokoll), 80 (TCP - WWW ungesichert) und 53 (UDP - Namenauflösung) öffnen. Nicht ganz klar ist mir bei der Antwort von Tesla, wozu der Port 943 (TCP) offen sein sollte, da hab ich in den Logs noch nie Traffic sehen können … So wie es Tesla schreibt, reicht es den Verkehr von innen nach aussen zu zulassen.

Allerdings ist es im Fall vom openvpn (Port 1194 UDP) welches das Model S nutzt, um die Telemetriedaten an die Tesla-Server zu senden ein Portforwarding braucht, d.h. es muss auch eine Verbindung von aussen nach innen möglich sein … meine Erfahrung war auch diese. Allerdings seit den letzten Firmware Updates muss irgendetwas geändert worden sein, wie sich das Model S bei einer WLAN Verbindung verhält.

In den Firewall-Logs kann ich keine Pakete vom openvpn sehen, selbst wenn mein Rule-Setup falsch wäre, würden die ja unweigerlich von der „Ausputzer-Regel“ geblockt und dann auch geloggt - aber nix … sehr komisch. Aus dem Fahrzeug kann man eben alle Dienste nutzen …

Liebe Grüsse

udp ist „stateless“ je nach Router/Firewall kann aber trotzdem eine virtuelle Session gebildet werden, die ggf die Antwortpakete durchlässt. Das Portforwarding wäre also nur nötig, wenn das der Router/die Firewall nicht macht. Mir sind keine handelsüblichen Consumer-Geräte bekannt, bei denen das nötig wäre, höchstens ein „selbstgebauter“ IP Filter bei dem das entsprechende Modul fehlt (zB iptables conntrack und dann eine Allow rule für Established).
Grund der „fehlenden“ Logs könnte genau diese Vorgehensweise vieler Geräte sein, da es bei UDP keinen Sessionaufbau/abbau wie bei TCP gibt ist die Frage, wann man es etws logged? Bei TCP machen das die meisten Geräte beim Beenden der Session (damit man auch das Volumen der Session kennt), bei UDP oft nur in Intervallen, die (je nach Konfiguration) durchaus Tage betragen können. Insofern würde ich mir mal mit einem Wireshark/tcpdump angucken, was passiert. Evtl gegt schon DNS nicht, dann gibt es auch keinen Versuch, eine Verbindung aufzubauen.

Hm, das mag ja richtig sein. Aber DNS geht zum Beispiel, da ich ja mit dem Webbrowser im Auto surfen kann … eben vom Auto aus kann ich alle Dienste problemlos nutzen. Ist auch logisch, da ich den Zugang vom Tesla in eine eigene DMZ gepackt habe und allen Verkehr vom Tesla - Netzsegment nach draußen passieren lasse…

Habe hier dasselbe Problem. Ebenfalls bei ServiceHelpEU deponiert. Über 3G funktioniert die App einwandfrei, mit WLAN geht die App nicht, surfen mit dem Browser im Auto hingegen schon…

Nachtrag: bis ca letzten Montag hat alles einwandfrei und zuverlässig funktioniert auch über WLAN.

Hallo nochmal,

Danke für Deine Meldung axryp - ich dachte schon ich bin der Einzige mit diesem Problem … Ich hatte neulich wieder 2 Tage, an denen es funktioniert hat und seit Gestern ist wieder „Feierabend“! Ich habe in der Tiefgarage einen minimalen 3G - respektive EDGE Empfang ich werde jetzt mal eine Woche ohne WLAN testen.

Am Firewall-Setup liegt und lag es jedenfalls nicht!! Ich setze eine Zyxel USG 20 ein und die braucht definitiv einen Rückkanal für die UDP Pakete und eine NAT - Rule, dass habe ich während der Funktionsphase sehen können… Danach fing es wieder mit „Stocken“ an - man konnte meist nur einen Befehl via App oder Visible Tesla (Ver. 0.29.00) setzen und dann finito… ;(

Hm, ich denke, da gibt es irgend ein Problem mit der WLAN Connectivität - da werden wir uns wohl bis Ver. 6.2 gedulden müssen und hoffen, dass es dann wieder besser funktioniert! Btw. Antwort vom Support habe ich auch bekommen allerdings recht kryptisch, da der wahrscheinlich vom Englischen oder Niederländischen ins Deutsche konvertiert worden ist:

Hm, da werde ich nicht ganz schlau draus. Auf jeden Fall ist es meiner Meinung nach nicht so, dass die App auch UDP benutzt…

Ich verwende eine Fritzbox 7390. Für das Model S habe ich nie etwas spezielles eingerichtet auf dem Router, und von Mai 2014 bis Feb 2015 hat mit dem App und WLAN alles perfekt funktioniert - ich habe auch jeden Tag das Fahrzeug vorgewärmt mit der App.

Ich habe gestern noch den Traffic mitgeschnitten auf der Fritzbox, und sehe wohl dass DNS anfragen gemacht werden um die IPs der VPN Server zu ermitteln, nur irgendwelche versuche das VPN aufzubauen kann ich nicht erkennen.

Habe alles mal so an Tesla weitergeleitet. Ich habe das Glück dass ich auf dem Parkplatz zu Hause auch guten 3G Empfang habe, somit habe ich für den Moment das WLAN gekappt, und die App funktioniert wieder bestens.

Wenn Du da funktionierende Rules gefunden hast, wäre ich an genaueren Daten interessiert. Die USG habe ich nämlich auch im Einsatz.

Grüße

Eric

@Eric: Also bei mir steht das Model S in der Tiefgarage und wir selbst wohnen in der 2. Etage - also für’s normale WLAN keine Chance; deshalb habe ich über ein PowerLine Set von devolo ein WLAN Segment in der Garage aufgemacht (was für ein Luxus - nur leider im Moment zwecklos) - das ist nur für’s Verständnis meiner Lösung und muss nicht sein :wink:

Also um es schön zu trennen, hab ich das PowerLine Segment in die DMZ (an der Zyxel einfach einen Port als DMZ konfigurieren) gehängt mit einem eigen Adressbereich. Der Accesspoint erlaubt nur angemeldete MAC-Adressen… Da nur das Model S und allenfalls mein Handy im Netzwerk sind und Sicherheit jetzt (ausnahmsweise) mal nicht höchste Priorität hat, lasse ich allen Verkehr von Innen nach Aussen zu:
Also From „DMZ“ to „Any (excluding Zywall)“ -> „Allow“; zur Kontrolle habe ich noch das Log-Flag gesetzt. Das ist mal die einfache Regel mit der kannst Du schon surfen und Radio hören usw…

Jetzt musst Du noch für UDP den Rückkanal bauen, dafür brauchst Du eine NAT Regel (Im Bereich Network unter Setup): NAT-Type ist „virtual server“, Interface ist „WAN“, Original IP ist die „WAN-Interface-IP“ Deiner Zywall, Mapped IP ist logischerweise die „IP Deines Model S“, Protocol ist „UDP“, Original Port ist „high_UDP“ und Mapped Port ist auch „high_UDP“. Als „high_UDP“ habe ich ein Service Objekt mit dem Namen „high_UDP“ erstellt, mit dem Range von 1024 … 49151. Man will ja nicht gar zu viel zulassen. Die NAT Regel wird immer vor den Firewall Regeln abgearbeitet…

In der Firewall habe ich jetzt zwei Regeln gemacht, durch die sporadische Funktion konnte ich nicht genau testen welche es jetzt wirklich braucht … Da die NAT-Regel als erste abgearbeitet wird müsste eigentlich diese genügen:
From „WAN“, To „DMZ“, Source „Any“ (hier könnte man auch ein Range Objekt mit den Tesla VPN-Servern nehmen, wäre sicherer), Destination „Dein Model S“, Service „high_UDP“, -> „Allow“ und auch hier wieder das Log-Flag… Dann dachte ich noch es braucht eine Regel die den Verkehr von Aussen zum WAN-Interface der Zywall zulässt:
From „WAN“ to „Zywall“, Source „Any“ (auch hier wieder könnte man nur einen Adressrange zulassen), Destination „WAN-Interface-IP Deiner Zywall“, Service „high_UDP“, -> Allow und auch hier wieder das Log-Flag … Aber ich glaube, dass es die Regel nicht braucht, da ja wie gesagt das NAT schon vor den Firewalling Regeln gemacht wird und die Regel würd ich dann lieber grad löschen - Verkehr direkt auf die Firewall zugeben ist eigentlich ein No-Go…

Hm soweit so gut - oder nicht … im Moment mache ich es genau so wie „axryp“ bei mir ist eben erschwerend das die Garage durch ein recht massives Metalltor verschlossen wird und da is fertig mit Radiowellen :wink: aber’n bissel was scheint trotzdem durch zu kommen …

Werde mich morgen mal damit bebschäftigen.

Dein Stromzähler sitzt also im Keller und Dein Parkplatz ist im Stromzählerkreis mit eingebunden. Sonst wäre hier auf alle Fälle schon ein Punkt für einen sporadischen Verbindungsabbruch zu vermuten.

Zu der Konfiguration:
Wäre es nicht sinnvoller ein Object Adresse mit der IP des Model S zu erstellen, anstelle den mE immer noch bedenklichen DMZ Traffics offen am Rand Deines Netzwerkes zu erlauben. Damit wären die Regeln doch ein wenig sicherer.

Grüße

Eric

wieso eigentlich UDP high? lässt sich der source port nicht genauer eingrenzen? evtl mal an der outbound NAT so drehen, dass der source port beibehalten wird?

@Eric: Ja das Model S ist quasi bei uns im Stromnetz mit eingebunden, der Verbrauch läuft also über unseren Zähler. Vom Hausanschluss her sind wir also „hinter“ dem Zähler, von der Warte her habe ich kein Problem mit dem PowerLine Zeugs - habe auch da immer eine recht gute Verbindung - das ist wohl nicht das Problem. Zumal es in der Vergangenheit wie „geschmiert“ lief und erst seit etwa den letzten 3 Firmware Updates die Probleme auftraten.

Ein Adress-Objekt für das Model S hab ich erstellt klar und die DMZ habe ich gemacht, um das „Sauber“ vom Heimnetz zu trennen… Man kann den Verkehr sehr restriktiv auf das Model S beschränken nur sollte der VPN Kanal vernünftig funktionieren und das ist im Moment irgendwie das Problem…

@ctr: Das ist erstmal so der Standardfall: Der Client vom Model S kommt vom UDP high und geht zum Server von Tesla auf UDP1194 und der Server kommt von UDP high und sendet zum Model S auf UDP1194 - ähnlich, wie das bei TCP läuft. Man kann das „umbiegen“, dass Hin- und Rückweg über den gleichen Port laufen, wäre noch eine Überlegung wert… mal gucken, ob das geht bei der Zywall…

Vielen Dank für Eure Inputs und liebe Grüsse

ich habe soeben einen Wlan Access Point in der Firma direkt mit offiziellen IP Adressen ins Internet gestellt. Kein NAT, keine Firewall, …

Ergebnis: Browser geht, Tesla App auf dem iPhone kann nicht connecten wen das Auto im Plan ist.

Scheint ein Bug zu sein!

Ich habe einen Zyxxel-Powerline-Adapter in der TG, ab und zu verbindet mein MS nicht mehr automatisch, dann soll ich den Code neu eingeben, er nimmt den Code nicht an. Also mit dem rechten Daumenrad resetten, Nach dem Neustart verbinden sich die Beiden wieder automatisch. Dieses Phänomen habe ich schon immer gehabt, ungeachtet der SW-Version.