Ein praktischer Leitfaden für FileMaker-Entwickler und Remote-Worker

Als FileMaker-Entwickler arbeite ich regelmäßig remote an Kundenprojekten. Der Zugriff auf interne FileMaker-Server erfolgt dabei manchmal über OpenVPN. Das funktionierte über Jahre hinweg problemlos, bis ich auf Starlink als Internet-Provider wechselte.

Die Symptome

Die VPN-Verbindung schien auf den ersten Blick zu funktionieren:

  • TLS-Handshake erfolgreich
  • Zertifikate werden akzeptiert
  • Verbindung zum VPN-Server wird aufgebaut

Aber dann: AUTH_FAILED

Interessanterweise zeigte der VPN-Server keinerlei Login-Versuche in seinen Logs. Es war, als würde die Authentifizierung ins Leere laufen.

Ein schneller Test mit dem Smartphone als Hotspot (mobiles Netz) brachte Klarheit: Die VPN-Verbindung funktionierte sofort einwandfrei.

Das bedeutet:

  • Die Credentials sind korrekt
  • Die VPN-Konfiguration ist valide
  • Starlink manipuliert oder blockiert OpenVPN-Traffic

Starlink ist bekannt dafür, dass es mit bestimmten VPN-Protokollen auf Standard-Ports Probleme gibt. Die Gründe sind vielfältig:

  1. Carrier-Grade NAT (CGNAT): Starlink nutzt oft mehrere NAT-Ebenen, was VPN-Protokolle verwirren kann
  2. Traffic-Shaping: Bestimmte Protokolle werden priorisiert oder gedrosselt
  3. Deep Packet Inspection: OpenVPN-Pakete auf Port 1194 (TCP) werden möglicherweise erkannt und anders behandelt
  4. Satellitenlatenz: Die hohe Latenz kann bei bestimmten Protokollen zu Timeouts führen

In meinem Fall wurde die Verbindung technisch aufgebaut, aber die Authentifizierungs-Pakete kamen nie beim Server an oder wurden fehlerhaft übertragen.

Die Lösung: Ein VPN-Relay-Server

Statt gegen Starlink anzukämpfen, habe ich einen Workaround entwickelt: Ein Relay-Server als VPN-Vermittler.

Die Architektur

Mein Mac (Starlink) 
    ↓ [Normaler TCP-Traffic]
Windows Server (Cloud/Rechenzentrum)
    ↓ [OpenVPN]
Kunden-FileMaker-Server

Der Trick: Der Relay-Server hat eine normale Internet-Verbindung ohne Starlink-Einschränkungen und baut die OpenVPN-Verbindung problemlos auf.

Warum einen eigenen Server nutzen?

In meinem Fall hatte ich bereits einen gemieteten Windows Server. Statt einen zusätzlichen VPS zu mieten, nutze ich einfach diesen:

Vorteile:

  • Keine zusätzlichen Kosten
  • Bestehende Infrastruktur nutzen
  • Volle Kontrolle über die Konfiguration
  • Kann für mehrere Kundenprojekte genutzt werden
  • Einfach ein-/ausschaltbar

Technische Umsetzung

Schritt 1: OpenVPN auf dem Relay-Server

Auf dem Windows Server (könnte auch Linux sein):

  1. OpenVPN Client installieren
  2. Die VPN-Config des Kunden importieren
  3. Verbindung aufbauen – funktioniert problemlos!

Schritt 2: Port-Forwarding einrichten

Der elegante Teil: Ich richte auf dem Relay-Server ein Port-Forwarding ein, sodass ich vom Mac aus direkt auf den Kunden-FileMaker-Server zugreifen kann.

Windows (PowerShell als Admin):

# Port 15003 auf den FileMaker-Server weiterleiten
netsh interface portproxy add v4tov4 ^
  listenport=15003 ^
  listenaddress=0.0.0.0 ^
  connectport=5003 ^
  connectaddress=192.168.00.00

# Firewall öffnen
netsh advfirewall firewall add rule ^
  name="FileMaker Relay" ^
  dir=in action=allow protocol=TCP localport=15003

Linux Alternative:

# Mit iptables
iptables -t nat -A PREROUTING -p tcp --dport 15003 \
  -j DNAT --to-destination 192.168.00.00:5003
iptables -t nat -A POSTROUTING -j MASQUERADE

# Oder mit socat (einfacher für Tests)
socat TCP-LISTEN:15003,fork TCP:192.168.00.00:5003

Schritt 3: Vom Mac aus verbinden

In FileMaker Pro einfach als Host eintragen:

mein-relay-server.de:15003

Fertig! Der FileMaker Server ist erreichbar, als wäre er direkt im Internet.

Sicherheitsüberlegungen

Wichtig:

  1. Port-Forwarding nur für vertrauenswürdige Ziele – du leitest Traffic durch deinen Server
  2. Firewall-Regeln eng fassen – nur die benötigten Ports öffnen
  3. Starke Authentifizierung am FileMaker-Server selbst
  4. Logging aktivieren – um unbefugte Zugriffe zu erkennen
  5. IP-Whitelist in Betracht ziehen, falls deine eigene IP stabil ist

Performance

Durch den zusätzlichen Hop (Relay-Server) entsteht minimal zusätzliche Latenz:

  • Direkt (ohne Starlink-Problem): ~50ms
  • Via Relay: ~70-100ms

Für FileMaker-Development ist das völlig akzeptabel. Die Satellitenlatenz von Starlink (20-40ms) ist da meist der größere Faktor.

Kosten-Nutzen-Rechnung

Ohne eigenen Server:

  • VPS-Kosten: ~5€/Monat
  • Zeitaufwand Setup: ~1-2 Stunden einmalig
  • Nutzen: Produktives Arbeiten von jedem Ort mit Starlink

Mit eigenem Server:

  • Zusatzkosten: 0€
  • Zeitaufwand Setup: ~30 Minuten
  • Nutzen: Mehrere Kundenprojekte über einen Relay

Alternative (Handy-Hotspot):

  • Kosten: Mobiles Datenvolumen
  • Nachteil: Umständlich, langsamer, Akku leer

Für mich war die Relay-Lösung die perfekte Alternative.

Fazit

Starlink ist eine fantastische Technologie für Remote-Work – aber mit VPN-Verbindungen gibt es bekannte Hürden. Statt zu verzweifeln oder ständig auf Handy-Hotspot auszuweichen, bietet ein Relay-Server eine elegante, dauerhafte Lösung.

Die Einrichtung ist in unter einer Stunde erledigt und funktioniert dann zuverlässig. Besonders für FileMaker-Entwickler, die regelmäßig auf verschiedene Kunden-Server zugreifen müssen, ist diese Methode Gold wert.

Zusammengefasst

Problem: Starlink blockiert OpenVPN-Authentifizierung
Lösung: Relay-Server als VPN-Vermittler
Aufwand: 30-60 Minuten Setup
Kosten: 0-5€/Monat (falls kein eigener Server vorhanden)
Ergebnis: Produktives Arbeiten von überall

Weiterführende Ressourcen

Hast du ähnliche Erfahrungen mit Starlink und VPN gemacht? Welche Lösungen hast du gefunden? Schreib es in die Kommentare!