VPN mit iPhone an pfSense hinter FritzBox

Die 3 IPsec Regeln sind natürlich Schwachsinn wenn du dahinter so oder so eine Scheunentor Regel implementiert hast die das eh alles zulässt.
Mal dumm nachgefragt: Bei so einer Regel hast du die Firewall ja quasi ausgeschaltet, was macht die denn da dann noch für einen Sinn ??? Dann kannst du sie auch gleich weglassen.
Oder ist die Regel jetzt nur testweise um das VPN zu testen ?
Ja, dem ist so...
Mmmhhh...
Gehe mal auf die pfSense unter Diagnostics --> Packet Capture wähle dort das WAN Interface aus und starte den Packet Capture.
Dann startest du den IPsec Client auf dem iPhone und versuchst eine Verbindung auf die pfSense aufzumachen.
15 Sek. warten und Capture wieder schliessen.
In der Anzeige der Pakete solltest du dann UDP und ESP Pakete mit der Absender IP des iPhone sehen.
Bedenke hier das als Ziel IP für den IPsec Client immer die öffentliche IP der FritzBox angegeben werden muss !
Oder falls du die FB mit einem DDNS Dienst verbunden hast diese Hostadresse !
Wenn du keine eingehenden UDP 500, 4500 oder ESP Pakete siehst forwardet die FritzBox dann weiterhin KEIN IPsec auf die pfSense.
Du kannst auch die pfSense mal temporär abziehen und einen Laptop stattdessen anklemmen an die FB der die gleiche IP Adresse hat wie der WAN Port der pfSense.
Auf diesem Laptop startest du dann mal den Wireshark Sniffer und wieder den IPsec Client am iPhone. Der stellt die mitgeschnittenen IPsec Protokollpakete grafisch etwas übersichtlicher dar als die pfSense.
So oder so solltest du aber IMMER eingehende IPsec Pakete da gehen wenn der VPN Client versucht den Tunnel zu öffnen.
Siehst du sie nicht forwardet die FritzBüx nix !!

Greifst du mit dem iPhone über ein Mobilfunknetz zu per VPN ??
Auch hier besteht die Gefahr das der Mobilfunkprovider IPsec filtert. Das wird oft gemacht wenn man billig nur Surf Accounts hat und keinen Business Account. Viele Billig Provider geben das erst bei Business Accounts frei.
Das solltest du sicher klären vorab

Das sieht gut aus ! 109.237.187.235 bedeutet das dein Telefon im T-Mobile oder Congstar Netz ist oder ein Carrier der das T-Com Mobilfunknetz benutzt
Alle anderen Daten sind aber uninteressant. Das kannst du daran sehen das der Port nicht zum IPsec Protokoll gehört.
Die 5te Zahl hinter der IP gibt den Port an. Z.B.
IP 192.168.33.2.38676 > 96.17.152.39.53: UDP, length 51
Bedeitet das das IP Paket eine Absender IP 192.168.33.2 hat mit dem Absender Port UDP 38676 und als Zieladresse 96.17.152.39 mit dem Zielport UDP 53
UDP 53 ist DNS also Nameserver. Daraus wird klar das die Firewall hier ein Name Server Query an die 96.17.152.39 (Akamai Name Server USA) stellt.
DNS hat mit dem IPsec VPN primär nix zu tun. Ist aber klar das solche Pakete da landen denn du machst keine Filterung.
Man könnte mal eingehend auf die 109.237.187.235 filtern, dann würdest du nur die Pakete sehen die vom und an dein iPhone gehen. Musst du aber immer neu checken, denn die IP Adressen in Mobilfunknetzen sind dynmaisch und ändern sich täglich. Im Zweifel also immer ins Setup des iPhone sehen und prüfen was für eine IP du aktuell hast.
Da aber UDP 4500 durchkommt ist das schonmal ein Teilerfolg.
Es ist aber nur eben ein Teil des IPsec. Da müssen auch UDP 500 und besonders ESP Pakete kommen. ESP transportiert den Tunnel an sich.
Ohne die ist das IPsec Portforwarding auf der FB unvollständig !

Was du auch mal testen kannst ist das iPhone testweise in das WLAN der FB einzubuchen.
Das Mobilfunknetz deaktivierst du im iPhone
Damit ist das iPhone dann direkt im LAN Netzwerk der FB und somit auch direkt im Netz des pfSense WAN Ports.
Du umgehst also quasi das Port Forwarding der FritzBox aus dem Internet und diese potentielle Fehlerquelle.
Auch kann das iPhone das VPN dann nur noch zwangsweise über das WLAN aufbauen, da du ja den Daten Mobilfunkzugang gesperrt hast.
Damit kannst du dann absolut sicherstellen das dir das Port Forwarding der FB keinen Streich mehr spielt, denn es ist so umgangen und du bist quasi DIREKT mit deinem VPN an der pfSense dran ohne Hindernisse.
Wenn du dem iPhone Client dann als Ziel IP Adresse nun die 192.168.33.2 also die pfSense WAN IP mitgibst, baut dieser direkt die VPN Verbindung auf.
Das sollte in jedem Fall klappen denn nun hast du keine Hindernisse mehr dazwischen.
Voraussetzung ist natürlich das deine Firewall Regeln korrekt sind aber das kannst du mit Hilfe des pfSense Logs und VPN Logs und auch Paket Sniffers dann sauber verifizieren.
Klappt damit der VPN Zugang weisst du ganz sicher das die vorliegende FritzBüx der böse Bube ist und das dort am Paket Forwarding dann was nicht klappt !
Der Test lohnt in jedem Falle !

Ist ja normal weil hier dann erstens eine Route auf der Fritte in dieses Netz fehlt und zweitens das NAT der PFSense blockt. Wenn du nun anstatt auf der PfSense NAT zu betreiben das NAT abschalten würdest und auf der Fritte eine statische Route ins 192.168.33.x/24 Netz mit GW-IP der PFSense gesetzt hättest, wäre auch ein direkter Zugriff auf dein Netz hinter der PFSense kein Problem so denn die Firewall in der PFSense dies per Regel zulässt . Alles simpelstes Routing-ABC das jeder Netzwerker aus dem FF beherrschen sollte.

Gruß

Besser hätte man es nicht sagen können...
Allerdings zeigt das aber auch klar das irgendwas am IPsec Port Forwarding an der FB nicht stimmt.
Zu 98% hat der TO eben nicht das VPN bzw. den VPN Service deaktiviert auf der FB und dann forwardet sie eben keine IPsec Pakete auch wenn diese fürs Port Forwarding eingetragen ist.
Der Sniffer Output von oben lässt das leider vermuten und genau deshalb macht es sehr viel Sinn den VPN Test mal ohne die FB davor zu machen wie oben beschrieben um überhaupt erstmal zu verifizieren das die IPsec Konfig direkt mit der pfSense Firewall auch sicher klappt.

Jepp auf der Fritte sähe diese dann so aus

Dann kann das Wochenende ja kommen

Danke für die Rückmeldung.

Gruß

Klasse ! Glückwunsch !
Gut zu wissen das man die FB besser einmal durchstarten sollte. Ist aber im Nachhinein auch verständlich wenn da nch irgendwelche Session Caches aktiv sind.
Supi wenns nun klappt wie es soll.
Und nicht vergessen...:
Unbedingt die üble Scheunentor Regel vom pfSense WAN Port wieder dichtmachen ! Du lässt deine Haustür ja auch nicht sperrangelweit offen, oder ?

Punkt d. ist hier ganz wichtig !
Nein Standard gibts so nicht und hängt immer von individuellen Anforderungen und Policies ab, du hast schon die wichtigsten genannt.
d solltest du im Hinblick auf ein harmonisches Familienleben nochmal überdenken sonst darfst du die nächsten 3 Monate die 31.192.120.44 nicht sperren in der FW !

Hallo in die Runde,
darf ich mich an den Thread dran hängen?

Die Konstellation des Thread-Erstellers ist auch bei mir vorhanden. Durch die Hilfe aus diesem Thread konnte ich schließlich erfolgreich eine VPN Verbindung aufbauen. Die VPN-Verbindung besteht nun zwischen iPhone (LTE-Netz) und der pfsense.

Problem: die IP-Adresse des iPhone (über myip abgefragt o.ä) ist nicht die aus dem Heimnetz oder meine DSL-IP, nein es ist die IP vom LTE-Netz. Also die gleiche IP ohne VPN Verbindung. Auch kann ich meine Clients im Heimnetz nicht ansprechen.

Könnt ihr mir da bitte helfen, ich finde keinen Ansatz zur Fehler suche? Danke!

Aber immer doch ! Genau dafür ist ein Forum ja da
Klappt auch problemlos...
Mittlerweile gibt es ein dediziertes und eigenes Tutorial dafür hier im Forum:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Das ist auch völlig normal und richtig so !
Das VPN auf der pfSense ist vermutlich als Split Tunnel konfiguriert, richtig ?
Dann wird einzig nur der Traffic ins remote Netz in den Tunnel geroutet und alles andere wird dann lokal, mit der Absender IP des LTE Netzes, bedient. Genau deshalb siehst du auch die LTE IP.
Works as designed.

Wenn du aber dein VPN mit einem Gateway Redirect konfigurierst, also den gesamten Traffic in den VPN Tunnel routest um dann über den remoten Heimnetz Router wieder ins Internet zu gehen, dann bekommst du als Absender IP auch die des Heimnetz Routers am WAN/DSL Port.
Fazit:
Du hast, wenn du Redirect möchtest, vermutlich dein VPN auf der pfSense falsch konfiguriert wenn du alles in den Tunnel routen willst. Sprich Redirect nicht aktiviert sondern normal Split Tunneling gemacht, was ja generell auch üblich ist.
Auch das steht im o.a. Tutorial wie man das dann mit dem Redirect macht.
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten

Erstmal vielen Dank!!!
Genau nach der, von dir verlinkten Anleitung, habe ich mein VPN eingerichtet. Das mit dem "redirect" konnte ich nur im workaround für Windows 10 aus machen. Wenn ich das richtig verstehe muss redirect oder Split-tunnel im Endgerät, also iPhone oder so, eingestellt werden?
In der pfsense konnte ich eine Einstellung für redirect nicht finden.

so sieht meine VPN aus:

jetzt habe ich doch noch etwas gefunden:

sieht dann bei mir so aus:

leider ist die IP des iPhone noch immer die von meinem LTE-Provider. Was tun?

hier die aktuelle Verbindung:

Leider habe ich noch immer keine Lösung gefunden den gesamten Verkehr durch den Tunnel zu leiten. Könnt ihr mir bitte noch mal helfen? Welche Informationen fehlen noch zur Diagnose??

Nein, es reicht wenn du das remote Netz mit 0.0.0.0 /0 angibst wie im Tutorial beschrieben, dann routet der Client alles in den Tunnel. Auch bei OpenVPN z.B. wir das am VPN Server eingestellt. Nicht am Client.
Dann hast du das Tutorial NICHT oder nicht richtig gelesen !
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Das gilt für alle Client nicht nur Winblows. Funktioniert hier mit einem iPhone mit aktuellem IOS und Android mit StrongSwan fehlerlos.
Benutzt dein LTE Provider im Mobilfunknetz ggf. private RFC 1918 IP Adressen ? Wenn ja dann macht der CGN und dann funktioniert es deshalb nicht.
Bei vielen Billigen "nur Surf" Accounts landet man oft auf einem APN der nur private IP Netze mit CGN nutzt im Funknetz.
Mit öffentlichen IPs im WAN funktioniert es wie gesagt fehlerfrei.
Im Zweifel mal die Log Dateien löschen, dann VPN Verbindung aufbauen und das IPsec Log der FW ansehen. Dort steht in der Regel alles was beim Tunnelaufbau passiert.