Mobile Einwahl IPSec VPN von iPhone iPad T-Mobile zur Pfsense
Ich möchte mich in dieser Frage nochmals auf den Wissensartikel IPsec VPN für mobile Benutzer auf der pfSense Firewall einrichten] hier im Forum beziehen, bei dem es um die Konfiguration eines Mobile Client (iPhone und iPad sowie über ein Macbook) gehen soll.
Ziel soll es sein, eine Verbindung ins LAN Netz der Pfsense Firewall aufzubauen, damit mit diversen Apps auf Daten bzw. Server und Computer zugegriffen werden kann. Das Ganze soll über die Mobile Einwahl meines Providers T-Mobile erfolgen.
Infrastruktur Bei meinem Provider Unity Media (BW) habe ich einen Business Tarif mit 5 festen IP Adressen gebucht. Welche ich in meinem eingenen Subnetz, welches mir zur Nutzung zur Verfügung gestellt wurde frei nutzen kann.
Was wurde bereits vorab geklärt? Zunächst habe ich mich bei der Telekom erkundigt, ob von Ihrer Seite irgendwelche Ports blockiert werden und ob mein gebuchter Tarif eine solche Möglichkeit bietet oder ob seitens der Telekom irgendwas mein Vorhaben verhindert. Nach 3 Telefonaten sicherten mir 2 Mitarbeiter zu, dass dies problemlos möglich sei und hier nichts blockiert werde. Auch in der Community Telekom Hilft war man sich einig. Das Funktioniert und einige betreiben ein ähnliches Setting mit der Mobilen Einwahl über VPN.
Was wurde bisher eingerichtet? Zunächst wurde and der Fritzbox Cable 6490 nur Portfreigaben eingerichtet. UDP 4500, 500 und ESP. Der Bridgemode wurde auf LAN 2 der Fritzbox aktiviert. Das Gateway meines Subnetzes wurde von UM automatisch der FB zugewiesen. Die Pfsene hat die erste (XX.XX.XX.42) der 5 IP Adressen erhalten und wurde statisch am WAN Port vergeben. Das Lan Interface hat die 192.168.10.0/24 erhalten.
hier die Screenshots dazu:
Nun habe ich mich mal an die Einrichtung der VPN Einwahl gemacht. Wie oben genannt, und Aquis Anleitung 1:1 veruscht umzusetzten.
Leider funktioniert die Einwahl immer noch nicht.
Anbei mal der IPSec Log der Pfsense:
Ziel soll es sein, eine Verbindung ins LAN Netz der Pfsense Firewall aufzubauen, damit mit diversen Apps auf Daten bzw. Server und Computer zugegriffen werden kann. Das Ganze soll über die Mobile Einwahl meines Providers T-Mobile erfolgen.
Infrastruktur Bei meinem Provider Unity Media (BW) habe ich einen Business Tarif mit 5 festen IP Adressen gebucht. Welche ich in meinem eingenen Subnetz, welches mir zur Nutzung zur Verfügung gestellt wurde frei nutzen kann.
Was wurde bereits vorab geklärt? Zunächst habe ich mich bei der Telekom erkundigt, ob von Ihrer Seite irgendwelche Ports blockiert werden und ob mein gebuchter Tarif eine solche Möglichkeit bietet oder ob seitens der Telekom irgendwas mein Vorhaben verhindert. Nach 3 Telefonaten sicherten mir 2 Mitarbeiter zu, dass dies problemlos möglich sei und hier nichts blockiert werde. Auch in der Community Telekom Hilft war man sich einig. Das Funktioniert und einige betreiben ein ähnliches Setting mit der Mobilen Einwahl über VPN.
Was wurde bisher eingerichtet? Zunächst wurde and der Fritzbox Cable 6490 nur Portfreigaben eingerichtet. UDP 4500, 500 und ESP. Der Bridgemode wurde auf LAN 2 der Fritzbox aktiviert. Das Gateway meines Subnetzes wurde von UM automatisch der FB zugewiesen. Die Pfsene hat die erste (XX.XX.XX.42) der 5 IP Adressen erhalten und wurde statisch am WAN Port vergeben. Das Lan Interface hat die 192.168.10.0/24 erhalten.
hier die Screenshots dazu:
Nun habe ich mich mal an die Einrichtung der VPN Einwahl gemacht. Wie oben genannt, und Aquis Anleitung 1:1 veruscht umzusetzten.
Leider funktioniert die Einwahl immer noch nicht.
Anbei mal der IPSec Log der Pfsense:
Sep 21 21:01:27 charon 14[NET] <6> sending packet: from XX.XX.XXX.42 (IP der Pfsense)[500] to 80.187.115.140 (IP der des iPhones T-Mobile LTE)[500] (473 bytes)
Sep 21 21:01:27 charon 14[IKE] <6> received retransmit of request with ID 0, retransmitting response
Sep 21 21:01:27 charon 14[ENC] <6> parsed IKE_SA_INIT request 0 [ SA KE No N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]
Sep 21 21:01:27 charon 14[NET] <6> received packet: from 80.187.115.140 (IP der des iPhones T-Mobile LTE)[500] to XX.XX.XXX.42 (IP der Pfsense)[500] (604 bytes)
Sep 21 21:01:24 charon 14[NET] <6> sending packet: from XX.XX.XXX.42 (IP der Pfsense)[500] to 80.187.115.140 (IP der des iPhones T-Mobile LTE)[500] (473 bytes)
Sep 21 21:01:24 charon 14[IKE] <6> received retransmit of request with ID 0, retransmitting response
Sep 21 21:01:24 charon 14[ENC] <6> parsed IKE_SA_INIT request 0 [ SA KE No N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]
Sep 21 21:01:24 charon 14[NET] <6> received packet: from 80.187.115.140 (IP der des iPhones T-Mobile LTE)[500] to XX.XX.XXX.42 (IP der Pfsense)[500] (604 bytes)
Sep 21 21:01:21 charon 14[NET] <6> sending packet: from XX.XX.XXX.42 (IP der Pfsense)[500] to 80.187.115.140 (IP der des iPhones T-Mobile LTE)[500] (473 bytes)
Sep 21 21:01:21 charon 14[IKE] <6> received retransmit of request with ID 0, retransmitting response
Sep 21 21:01:21 charon 14[ENC] <6> parsed IKE_SA_INIT request 0 [ SA KE No N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]
Sep 21 21:01:21 charon 14[NET] <6> received packet: from 80.187.115.140 (IP der des iPhones T-Mobile LTE)[500] to XX.XX.XXX.42 (IP der Pfsense)[500] (604 bytes)
Sep 21 21:01:18 charon 14[NET] <6> sending packet: from XX.XX.XXX.42 (IP der Pfsense)[500] to 80.187.115.140 (IP der des iPhones T-Mobile LTE)[500] (473 bytes)
Sep 21 21:01:18 charon 14[ENC] <6> generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(MULT_AUTH) ]
Sep 21 21:01:18 charon 14[IKE] <6> sending cert request for "C=DE, ST=BW, L=GP, O=Home, E=user@gmail.com, CN=vpnca, OU=Home"
Sep 21 21:01:18 charon 14[IKE] <6> remote host is behind NAT
Sep 21 21:01:18 charon 14[IKE] <6> 80.187.115.140 (IP der des iPhones T-Mobile LTE) is initiating an IKE_SA
Sep 21 21:01:18 charon 14[ENC] <6> parsed IKE_SA_INIT request 0 [ SA KE No N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]
Sep 21 21:01:18 charon 14[NET] <6> received packet: from 80.187.115.140 (IP der des iPhones T-Mobile LTE)[500] to XX.XX.XXX.42 (IP der Pfsense)[500] (604 bytes)
Sep 21 21:01:14 charon 14[NET] <bypasslan|5> sending packet: from XX.XX.XXX.42 (IP der Pfsense)[4500] to 80.187.115.140 (IP der des iPhones T-Mobile LTE)[17675] (80 bytes)
Sep 21 21:01:14 charon 14[ENC] <bypasslan|5> generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]
Sep 21 21:01:14 charon 14[IKE] <bypasslan|5> peer supports MOBIKE
Sep 21 21:01:14 charon 14[IKE] <bypasslan|5> received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Sep 21 21:01:14 charon 14[CFG] <bypasslan|5> no alternative config found
Sep 21 21:01:14 charon 14[IKE] <bypasslan|5> peer requested EAP, config inacceptable
Sep 21 21:01:14 charon 14[CFG] <bypasslan|5> selected peer config 'bypasslan'
Sep 21 21:01:14 charon 14[CFG] <5> looking for peer configs matching XX.XX.XXX.42 (IP der Pfsense)[pfsense]...80.187.115.140 (IP der des iPhones T-Mobile LTE)[10.25.123.172]
Sep 21 21:01:14 charon 14[ENC] <5> parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) N(MOBIKE_SUP) IDr CPRQ(ADDR DHCP DNS MASK ADDR6 DHCP6 DNS6 (25)) N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) SA TSi TSr ]
Sep 21 21:01:14 charon 14[ENC] <5> unknown attribute type (25)
Sep 21 21:01:14 charon 14[NET] <5> received packet: from 80.187.115.140 (IP der des iPhones T-Mobile LTE)[17675] to XX.XX.XXX.42 (IP der Pfsense)[4500] (496 bytes)
Sep 21 21:01:14 charon 14[NET] <5> sending packet: from XX.XX.XXX.42 (IP der Pfsense)[500] to 80.187.115.140 (IP der des iPhones T-Mobile LTE)[500] (473 bytes)
Sep 21 21:01:14 charon 14[ENC] <5> generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(MULT_AUTH) ]
Sep 21 21:01:14 charon 14[IKE] <5> sending cert request for "C=DE, ST=BW, L=GP, O=Home, E=user@gmail.com, CN=vpnca, OU=Home"
Sep 21 21:01:14 charon 14[IKE] <5> remote host is behind NAT
Sep 21 21:01:14 charon 14[IKE] <5> 80.187.115.140 (IP der des iPhones T-Mobile LTE) is initiating an IKE_SA
Sep 21 21:01:14 charon 14[ENC] <5> parsed IKE_SA_INIT request 0 [ SA KE No N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]
Sep 21 21:01:14 charon 14[NET] <5> received packet: from 80.187.115.140 (IP der des iPhones T-Mobile LTE)[500] to XX.XX.XXX.42 (IP der Pfsense)[500] (604 bytes)
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 349971
Url: https://administrator.de/contentid/349971
Ausgedruckt am: 19.12.2024 um 09:12 Uhr
37 Kommentare
Neuester Kommentar
eines Mobile Client (iPhone und iPad sowie über ein Macbook) gehen soll.
Auch Windows 10 und Android !! Soviel Zeit muss sein Zurück zum Thema...
Was etwas unklar ist wie deine Infrastruktur aufgebaut ist.
- Du redest von der Telekom, schreibst aber oben das du einen Unity media Vertrag hast. 2 Provider geht ja schlecht oder wie ist das zu verstehen ?
- Dann schreibst du das du einen Business Tarif mit 5 festen IP Adressen gebucht hast. Wie ist das zu verstehen ?? Normalerweise wäre das ein kleines öffentliches Subnetz was der Provider dir routet. Das erfordert dann aber 2 Router was bei dir aber nicht gegeben ist.
- Möglich wäre auch das diese festen IPs im Kabel Subnetz reserviert sind. Dann müsstest du diese IPs aber mit Alias IPs auf die kaskadierte pfSense bringen, was die FritzBox aber nicht supportet.
Das geht nur wenn du ein reines NUR Modem an der pfSense hast.
Ohne all das kannst du nur mit der FB ein Kaskaden Design machen mit 2 mal NAT und Port Forwarding.
Unity Media lässt zudem befürchten das du einen DS-Lite Anschluss bekommen hast, dann ist VPN so oder so nicht möglich jedenfalls nicht auf IPv4 Basis. Das ginge dann nur mit IPv6.
Wenn die 5 IPs aber öffentliche IPv4 Adressen sind und dabei keine RFC 1918 IPs, dann spricht das wieder gegen DS-Lite.
Fazit: Deine Provider Infrastruktur ist höchst undurchsichtig und man weiss nicht wirklich in welchem Modus die FB läuft. Daraus resultieren vermutlich aiuch alle Folgeprobleme.
Vor allen Dingen welche Infrastruktur. Telekom hat kein Kabelnetz nur xDSL usw. Unity Media Kabel ist aber nicht Telekom ?!
Wie werden die IP Adressen aus dem 5er Pool zugewiesen ? PPPoE ? DHCP ?
Das würde bedeuten sie routet das öffentliche IP Netz transparent durch ohne FW und NAT.
Dafür spricht dann auch die öffentliche IP.
So oder so wäre es sinnvoll den VPN Client erstmal in das WAN Port Netz der pfSense zu bringen und mal wasserdicht auszutesten ob das VPN überhaupt funktioniert und ob nicht dort schon Konfig Fehler gemacht wurden.
Das sollte der erste Step sein beim Troubleshooting.
Bekommt man das VPN dort sauber und fehlerfrei zum Laufen kann man sicher sein das es wenigstens an der VPN Einrichtung NICHT mehr liegt sollten dann noch wider Erwarten Fehler auftreten.
Also am WAN Port mal einen Switch mit einem AP anschliessen und dort dann mal Mac, Windows und kabel basierte VPN Clients anschliessen. Über den AP dann Smartphone, iPad, Tablet etc.
Quasi im Proinzig den Testaufbau machen wie im Tutorial beschrieben.
Dafür spricht dann auch die öffentliche IP.
So oder so wäre es sinnvoll den VPN Client erstmal in das WAN Port Netz der pfSense zu bringen und mal wasserdicht auszutesten ob das VPN überhaupt funktioniert und ob nicht dort schon Konfig Fehler gemacht wurden.
Das sollte der erste Step sein beim Troubleshooting.
Bekommt man das VPN dort sauber und fehlerfrei zum Laufen kann man sicher sein das es wenigstens an der VPN Einrichtung NICHT mehr liegt sollten dann noch wider Erwarten Fehler auftreten.
Also am WAN Port mal einen Switch mit einem AP anschliessen und dort dann mal Mac, Windows und kabel basierte VPN Clients anschliessen. Über den AP dann Smartphone, iPad, Tablet etc.
Quasi im Proinzig den Testaufbau machen wie im Tutorial beschrieben.
Hallo,
Diesmal hat dir also eine Firma ein Modem angestöpselt. Das ist doch deine 6490 im Bridgemodus da du sonst keine Feste IP nutzen kannst, oder? Du bastelst also immer noch an dein Richtige Grundeinstellungen der Pfsense für mein Netzwerk oder?
Gruß,
Peter
Diesmal hat dir also eine Firma ein Modem angestöpselt. Das ist doch deine 6490 im Bridgemodus da du sonst keine Feste IP nutzen kannst, oder? Du bastelst also immer noch an dein Richtige Grundeinstellungen der Pfsense für mein Netzwerk oder?
Gruß,
Peter
Hallo,
Sagt wer?
Lies dies hier mal und du wirst feststellen das manch einer dazu immer noch Konfigurieren sagt https://www.heise.de/forum/heise-online/News-Kommentare/Routerzwang-Hers ...
Gruß,
Peter
PS. Da hat das Marketing von UM geklappt - dir unbekannte Fremdwörter nutzen um an dein Geld zu kommen
Sagt wer?
Abgesehen von der Authorisierung gegenüber Unity Media in BW wüsste ich noch nicht mal was zutun ist.
Du brauchst nur fehlerfrei zu lesen und dies auch artikulieren können. Lies die CM MAC und die Seriennummer deiner Fritte ab und gib die an UM fehlerfrei weiter. mehr ist es nicht Lies dies hier mal und du wirst feststellen das manch einer dazu immer noch Konfigurieren sagt https://www.heise.de/forum/heise-online/News-Kommentare/Routerzwang-Hers ...
Gruß,
Peter
PS. Da hat das Marketing von UM geklappt - dir unbekannte Fremdwörter nutzen um an dein Geld zu kommen
Hallo,
Richtig, weswegen es auch nur ein PS war. Falls du noch immer nicht weisst was mit Provisioning in der IT gemeint ist dann besorg dir ein neues Google, deins ist kaputt.
Warum, wieso, weshalb usw. du dort einen UM Anschluss hast ist uns wumpe. Das sich dein UM Anschluss nicht ändert nur weil ein Subunternehmer dort rum fummelt ist auch klar. Und wenn der Fachmann dir nicht erklären konnte was ein Provisioning dort bedeutet und macht, sorry, aber du hättest ihn ja fragen können.
Und wenn du immer noch deinen UM in BW in betrieb am nehmen bist, dir sind die Technischen Unterschiede zwischen NRW un BW bekannt und kannst auch erkennen wie die umgesetzt wurden bzw. sind. Ich hab bisher nur Fritten an UM in NRW angepappt, mit fester Öffentliche IP und Telefonie, und dazu braucht es einen 2tem Router der das Kundennetz sauber trennt. Da ist also dann immer die UM eigene Fritte dran und den Kundeneigenen Router für sein Heimspiel.
Den Link von hier Richtige Grundeinstellungen der Pfsense für mein Netzwerk hast du wohl noch nicht vergessen?
Vielleicht solltest du das lassen und jemand holen der es kann bzw. auch versteht was er/sie dort tut...
Gruß,
Peter
Richtig, weswegen es auch nur ein PS war. Falls du noch immer nicht weisst was mit Provisioning in der IT gemeint ist dann besorg dir ein neues Google, deins ist kaputt.
Warum, wieso, weshalb usw. du dort einen UM Anschluss hast ist uns wumpe. Das sich dein UM Anschluss nicht ändert nur weil ein Subunternehmer dort rum fummelt ist auch klar. Und wenn der Fachmann dir nicht erklären konnte was ein Provisioning dort bedeutet und macht, sorry, aber du hättest ihn ja fragen können.
Und wenn du immer noch deinen UM in BW in betrieb am nehmen bist, dir sind die Technischen Unterschiede zwischen NRW un BW bekannt und kannst auch erkennen wie die umgesetzt wurden bzw. sind. Ich hab bisher nur Fritten an UM in NRW angepappt, mit fester Öffentliche IP und Telefonie, und dazu braucht es einen 2tem Router der das Kundennetz sauber trennt. Da ist also dann immer die UM eigene Fritte dran und den Kundeneigenen Router für sein Heimspiel.
Den Link von hier Richtige Grundeinstellungen der Pfsense für mein Netzwerk hast du wohl noch nicht vergessen?
Vielleicht solltest du das lassen und jemand holen der es kann bzw. auch versteht was er/sie dort tut...
Gruß,
Peter
Hallo,
die meisten Anwender, benutzen leider recht oft OpenVPN und deswegen ist bei der aktuellen pfSense 2.3.x & 2.4.0
etwas deaktiviert (AES-NI) was IPSec natürlich so richtig beschleunigt also bitte einmal nachschauen und aktivieren
wenn noch nicht geschehen, oder sogar IPSec selber ist nicht aktiviert, da sollte man aber auch noch einmal direkt
bei pfSense im Forum oder hier den @aqui nachfragen bzw. ansprechen.
So ist es zumindest sehr oft in dem pfSense Forum (engl. Teil) seitens der Entwickler beschrieben wurden, ich versuche
noch einmal heraus zu finden ob ich eine dieser Aussagen wiederfinde und verlinke sie dann einfach hier.
Also wenn Unitimedia Dir 5 IP Adressen zur Verfügung stellt sind in der Regel nur 3 oder 4 davon nutzbar, für solche
und andere Zwecke, denn eine ist das Gateway und die andere die Broadcast oder DHCP Adresse. Einfach mal eine
andere IP Adresse ausprobieren und gut ist es.
T-Mobile kann bei seinem LTE Vertrag und Netz auch solche Träger und Transfernetze dazwischen schalten, also
einfach mal versuchen heraus zu finden ob dem so ist, die AVM FB hat auch Apps mit denen man sich einwählen
kann, einfach mal damit einen Versuch machen und dann sieht man sehr schnell bzw. sehr viel schneller ob es
überhaupt eine VPN Verbindung erlaubt bzw. ermöglicht!
Und zu guter Letzt sollte man auch einmal versuchen zu klären was da eigentlich mit der AVM FB los ist, also in
welchem Zustand sie sich nun wirklich befindet!!!! Denn einige Aussagen hier sind so richtig fälschlich zu verstehen
oder zu deuten, mal ein paar Beispiele dazu;
Gruß
Dobby
die meisten Anwender, benutzen leider recht oft OpenVPN und deswegen ist bei der aktuellen pfSense 2.3.x & 2.4.0
etwas deaktiviert (AES-NI) was IPSec natürlich so richtig beschleunigt also bitte einmal nachschauen und aktivieren
wenn noch nicht geschehen, oder sogar IPSec selber ist nicht aktiviert, da sollte man aber auch noch einmal direkt
bei pfSense im Forum oder hier den @aqui nachfragen bzw. ansprechen.
So ist es zumindest sehr oft in dem pfSense Forum (engl. Teil) seitens der Entwickler beschrieben wurden, ich versuche
noch einmal heraus zu finden ob ich eine dieser Aussagen wiederfinde und verlinke sie dann einfach hier.
Also wenn Unitimedia Dir 5 IP Adressen zur Verfügung stellt sind in der Regel nur 3 oder 4 davon nutzbar, für solche
und andere Zwecke, denn eine ist das Gateway und die andere die Broadcast oder DHCP Adresse. Einfach mal eine
andere IP Adresse ausprobieren und gut ist es.
T-Mobile kann bei seinem LTE Vertrag und Netz auch solche Träger und Transfernetze dazwischen schalten, also
einfach mal versuchen heraus zu finden ob dem so ist, die AVM FB hat auch Apps mit denen man sich einwählen
kann, einfach mal damit einen Versuch machen und dann sieht man sehr schnell bzw. sehr viel schneller ob es
überhaupt eine VPN Verbindung erlaubt bzw. ermöglicht!
Und zu guter Letzt sollte man auch einmal versuchen zu klären was da eigentlich mit der AVM FB los ist, also in
welchem Zustand sie sich nun wirklich befindet!!!! Denn einige Aussagen hier sind so richtig fälschlich zu verstehen
oder zu deuten, mal ein paar Beispiele dazu;
- Entweder die AVM FB ist im "Bridged Modus" und die Telefonie und WLAN funktionieren nicht mehr wegen der
- Man hat die AVM FB nicht in den so genannten "Bridge Modus" versetzt und nicht alle Port und Protokolle
Gruß
Dobby
Aber wie gesagt, dass sind wirklich 5 zur freien Nutzung
Ist ja auch klar ! In der Regel bekommt man dann einen /29er Prefiix und hat dann 6 nutzbare IP Adressen in dem Subnetz. Beispiel: Netzadresse:192.168.1.0
Broadcast:192.168.1.7
Host-IPs von:192.168.1.1 bis:192.168.1.6
Bei deiner Adressierung dann:
Netzadresse:192.168.1.40
Broadcast:192.168.1.47
Host-IPs von:192.168.1.41 bis:192.168.1.46
Entspricht dann also deiner Angabe von oben und ist soweit richtig.
dass er der Aktivierungsschalter des VPN sofort zurückgeschnappt ist und sich nie komplett einschalten ließ
Zeigt das die VPN Konfig des iPhones fehlerhaft ist. Vermutlich statt IKEv2 dann "Cisco IPsec" genommen was dann natürlich in die Hose geht.Die pfSense Konfig ist immer IKEv2 basierend !! Folglich dann auch der Client.
Leider habe ich die Strongswan App nicht im iOS Appstore gefunden
Wäre ja auch völliger Schwachsinn (sorry) bei iPhone und iPad da die ja von sich aus einen IKEv2 Client schon an Bord haben. Wer wäre dann also so blöd und würde noch ein sinnlose zusätzliche App dafür rausbringen. Macht ja logischerweise keinen Sinn !iOS Versionen 10 und 11 implementiert, dass somit keine gesonderte App mehr erforderlich ist.
Genau so ist es !! Mann muss eben nur aufs "richtige" IPsec klicken und "IKEv2" auswählen ! Steht aber auch so ganz groß im Tutorial Daher behaupte ich mal vorsichtig, dass der Bridge Mode nun somit aktiviert wurde.
Kannst du ja mal wasserdicht testen indem du auf der pfSense dahinter an der WAN Port Regel ICMP auf das WAN Interface erlaubst.Damit ist dann das Firewall Interface pingbar von außen ! (Solltest du später wieder deaktivieren die Regel)
Mit den entsprechenden kostenlosen Hurricane Tools aus dem App Store:
https://itunes.apple.com/de/app/he-net-network-tools/id858241710?mt=8
kannst du dann das WAN Interface, oder auch alle anderen IPs deines 5er Kontingents anpingen.
Das ist wenigstens ein wasserdichter Test das die IP Connectivity dann sauber funktioniert von iPhone und iPad.
Später kann man damit dann auch Endgeräte im VPN pingen. Die HE Tools sind also sehr hilfreich beim Troubleshooting mit Apple Mobilgeräten.
Waren die Portfreigaben aktiviert kammen auch Pakete UDP 4500 und 500 an
Das sieht doch dann sehr gut aus !!und allow all auf dem IPSec Interface der Pfsense.
Auf dem internen IPsec Interface meinst du, oder ? Nicht etwa das WAN Interface da wäre "allow all" tödlich.Zu deiner Frage wie ein Testaufbau aussieht:
Das ist ganz einfach und schnell gemacht !!
Du klemmst an den WAN Port der pfSense einen kleinen Switch aus der Bastelkiste und wenn du hast einen WLAN Accesspoint damit die die Mobilgeräte via WLAN testen kannst.
Der pfSense gibst du am WAN Port testweise die statische IP 10.1.1.1 /24
Mit der WAN Regel erlaubst du dann
- RFC 1918 Netze (Haken entfernen)
- UDP 500, 4500 und ESP von "ANY" auf die WAN IP
- Testweise erlaubst du noch ICMP von "ANY" auf die WAN IP um pingen zu können
Dann pingst du testweise von allen Cliewnts mal das WAN Interface 10.1.1.1 was sauber klappen sollte wenn die Regel stimmt.
Den Clients musst du testweise dann statische IPs aus dem 10.1.1.0er netz geben oder wenn der AP es supportet schlatest du da einen DHCP Server aktiv der IP Adressen verteilt oder nutzt eine Software auf dem PC den du am Switch hast wie z.B.:
http://www.dhcpserver.de/cms/
Das erspart dir dann die manuelles IP Vergabe und macht das testszenario noch realistischer.
Gut, damit sind dann alle Clients quasi im "Internet" mit der pfSense IP seitig verbunden.
Nun startest du den Client, konfigurierst den auf die 10.1.1.1 als Ziel mit allen im Tutorial beschrieben Settings (die du ja schon gemacht hast).
Und nun muss sich fehlerlos eine sauberer VPN Verbindung herstellen lassen.
Klar, denn du hast erstmal ja nichts was zwischen VPN Client und Firewall ist. Hier kommt also die VPN Verbindung fehlerfrei zustande und für dich ist das dann ein ganz sicheres Indiz das die VPN Verbindung mit User/Pass usw. komplett richtig ist und die sauber funktioniert.
Etwaige Fehler können dann also ausschliesslich nur durch die Netzwerk Infrastruktur kommen wenn du wieder ans "heiße" Internet geht. Dadurch engst du deine Troubleshooting Option schon mal erheblich ein und musst nicht überall suchen.
So sähe das dann aus was das Testsetup aus Layer 3 Sicht anbetrifft:
Eigentlich doch ganz einfach und logisch
Die Firewall Regeln hab ich auch gesetzt:
Hier hast du schon den ersten gravierenden Fehler gemacht !!!Du hast dort WANnet als Ziel angegeben was natürlich falsch ist ! Das Ziel ist ja die WAN IP Adresse der Firewall selber !
Folglich muss dort also als Ziel (Destination) zwingend WAN_address stehen !!
Die Mobilen Clients wollten dann nicht mit dem WLAN verbinden.
Das ist auch klar wenn du die FritzBox FALSCH mit dem WAN Port (LAN1) verbindest !! Dort greift ja dann die NAT Firewall und verhindert eine WLAN Verbindung. Logisch ! Wenn man mal nur etwas nachdenkt...Die FB soll bei dir ja als reiner Accesspoint laufen zum Test, oder ?? Dann verbindest du sie natürlich mit dem LAN Port und nicht mit dem WAN/LAN1 Port.
Der in der FB integrierte WLAN Accesspoint arbeitet dort als Bridge zw. LAN und WLAN wie bei allen Routern auch.
Siehe auch entsprechendes Tutorial dazu:
Kopplung von 2 Routern am DSL Port
Fazit: 2 gravierende Fehler im Setup wovon jeder einztelen schon zur Fehlfunktion führt. Wenn du so oberflächlich und fehlerhaft auch im Produktiv Umfeld vorgehst muss man sich ja nicht groß wundern das nix rennt
Danach habe ich die ganze VPN Konfiguration an der Pfsense nochmals gelöscht und sie der 10.1.1.1 angepasst
Auch das ist vollkommen unsinnig und falsch !! Der dritte Kinken Die IPsec Konfiguration der FW ist vollkommen unabhängig von der IP Adresse ! Diese kann sich sogar per DHCP ändern. Sinnfrei das neu zu machen...aber egal schadet auch nicht, zeigt aber auch das du wieder grundsätzliche Fehler in der FW Konfig machst...siehe oben.
Der Common Name ist niemals eine IP Adresse !!! Genau das soll ja mit einem Namen, also einem einfachen ASCII String ersetzt werden gerade um genau KEINE Abhängigkeit von der IP Adresse zu schaffen.
Logisch, denn bei vielen ist die IP variabel.
OK, bei dir nicht, du könntest auch mit der IP arbeiten aber deine Clients haben fast immer wechselnde IPs. In so fern sind einfache Namen erheblich sinnvoller und machen die IPsec Konfig weniger fehleranfällig.
IPs als Identifier zu verwenden macht einzig nur Sinn in einem LAN zu LAN Umfeld mit beidseitig festen IPs sonst nicht.
Auch das steht aus genau diesem Grund mehrfach explizit im Tutorial. Lesen hilft hier also !
Weil das hier so ein Drama ist hab ich das eben mit dem aktuellsten 2.3.4p1 Patch in der pfSense (APU Hardware) nochmal verifiziert in genau dem beschriebenen Labor Setup und wie erwartet rennt es absolut fehlerfrei mit allen getestenen Clients, iPhone/iPad (iOS 10 und 11), Windows 10, Mac OS (Sierra) und Strong Swan.
pfSense hat die WAN IP 10.99.1.110.
Wenn du die 3 gravierenden Fehler von oben beseitigst ist das mit Sicherheit auch bei dir der Fall.
Sonst schickst du die FW rum und ich klicke für dich dann die richtigen Knöpfe im GUI.
Nur nochmal der Sicherheit halber nachgefragt:
Das Zertifikat bzw. die exportierte Zertifikatsdatei hast du auf ALLEN deiner Clients installiert ?? (Siehe Tutorial !)
Ein Clientzugriff ohne das Zertifikat scheitert.
Ein anderer Freund meinte auch, dass die Fritzbox keine Ports für die Pfsense aufmachen müsste.
Ports öffnen und Protokolle weiterleiten! Und vor allen anderen Dingen die VPN Funktion an der AVMFB deaktivieren denn sonst nimmt die immer zuerst das VPN an und leitet es nicht zur pfSense weiter
weil sie "denkt" das VPN sei für sie gedacht!
Nach einem Test über die Pfsense und das Tool Packet Capture konnte ich ohne Portfreigabe an der Fritzbox von
4500, 500 und ESP keine ankommenden Paktete IKE, ESP feststellen, sondern nur mit dieser Freigabe.
Die müssen leider geöffnet sein und auch weitergeleitet werden. Die pfSense sollte am WAN eine feste statische IP4500, 500 und ESP keine ankommenden Paktete IKE, ESP feststellen, sondern nur mit dieser Freigabe.
Adresse aus dem netz der AVM FB haben die nicht zum DHCP Kreis der AVM FB gehören sollte.
Auch meine er, dass ein gesondertes Aktivieren des Bridge Modes nicht nötig sei, da dieser schon von Werk aus aktiviert ist.
Der bridge modus macht aus dem Router AVM FB eine nur Modem AVM FB!!! Telefonie und WLAN sind dann dort nicht mehrmöglich und auch der DHCP Server funktioniert dann dort nicht mehr!
Auch das habe ich getestet und konnte keinen Unterschied zwischen deaktiviertem und aktiviertem Bridge Modus feststellen.
Das kann nicht sein, denn das ist wie der Unterschied zwischen einem reinen Modem und einem vollständigen Router.Prüfe das doch bitte noch einmal bevor wir hier weiter machen.
Gruß
Dobby
Ports öffnen und Protokolle weiterleiten! Und vor allen anderen Dingen die VPN Funktion an der AVM
Muss aber in der Tat nur sein wenn die FB oder generell der davor kaskadierte Router auch als Router arbeitet, sprich er also aktiv am IP Forwarding (Layer 3) beteiligt ist UND zusätzlich eine NAT Firewall aktiv hat.Einzig nur in diesem Fall ist ein Port Forwarding zwingend nötig.
Im Bridge Modus, also im reinen Layer 2 Modus als reines NUR Modem muss das in der Tat nicht sein und wäre auch kontraproduktiv !
Es ist also essentiell zu wissen wie ein vorgeschaltetes Gerät sich genau verhält bzw. in welchem Modus es genau arbeitet um es erfolgreich einbinden oder Troubleshooten zu können !!
Dem Kollegen Dobby kann man hier also nur zustimmen. Wenn der TO behauptet das es keinen Unterschied zwischen Bridge (Nur Modem) und Router Modus gibt dann hat er grundsätzlich etwas falsch gemacht im Setup.
Das wäre so als wenn man einen Diesel PKW mit Brennspiritus betankt und sagt es gäbe keinerlei Unterschied im Betrieb !
Den hat bisher noch keiner Kommentiert von euch beiden
Es gibt immer ein ganz sicheres Indiz ob das Gerät davor im Router oder im Bridge Mode arbeitet:Eine Bridge arbeitet immer auf dem Hardware Layer, sprich sie kennt keinerlei IP Adressen.
Eine Bridge reicht deshalb das Provider IP Netz einfach nur transparent durch.
Das sieht man dann immer eindeutig daran, das der WAN Port der dahinter kaskadierten Firewall eine öffentliche IP Adresse hat aus dem öffentlichen IP Adressbereich des jeweiligen Service Providers.
Ist dem so hat man eine Bridge oder ein Nur Modem davor.
Bei einem Router ist immer IP Forwarding im Layer 3 im Spiel. Das bedeutet das so ein Gerät routet und immer 2 unterschiedliche IP Netze auf beiden Seiten hat.
Außen am WAN Port dann wieder die Provider Internet IP wie oben. Am anderen Ende aber ein unterschiedliches IP Netz.
Da zum Großteil hier einfache NAT (IP Adresstranslation) Router zum Einsatz kommen haben die auf dieser Seite (lokales LAN wo die FW kaskadiert ist) so gut wie immer ein im Internet NICHT geroutetes IP Netz aus dem privaten RFC 1918 IP Adressbereich anliegen. Sprich einem 10.0.0.0 /8 einem 172.16.0.0 /12 oder einem 192.168.0.0 /16 Netz.
Ist letzteres der Fall muss man zwingend Port Forwarding machen. Technisch immer die zweitbeste Lösung.
Reicht das wenn du mir die erstellst und wiederherstellst?
Du hast recht, das wäre das Einfachste Nochwas. was mir im Labortest aufgefallen ist:
Der Phase 2 Parameter PFS Group muss auf OFF gesetzt werden im pfSense Setup. Ist er das nicht bricht die VPN Verbindung nach ca. 1-2 Minuten automatisch ab. Dazu gibt es auch einen entsprechenden Thread im pfSense Forum.
Mit OFF bleibt die VPN Verbindung stabil.
(Das Tutorial ist schon angepasst an diese Erkenntnis.)
Mach man erstmal dein neues Setup und folge da ganz genau mit allen Steps dem Tutorial:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Ich habe da heute noch ein paar Text Korrekturen gemacht damit es nun wirklich "laiensicher" ist.
Du bist jetzt das Versuchskaninchen ! Also streng dich an...
Hier ist es also essentiell wichtig ins Server Zertifikat auf der pfSense wirklich alle 4 Optionen des Common Names einzutragen.
Wenns auf dem MBP rennt dann zu 100% auch auf allen iOS Geräten.
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Ich habe da heute noch ein paar Text Korrekturen gemacht damit es nun wirklich "laiensicher" ist.
Du bist jetzt das Versuchskaninchen ! Also streng dich an...
Will jetzt zunächst mal schauen, dass ich nur das Macbook verbinden kann
Gute Idee, denn der IKEv2 Client auf dem MBP ist erheblich toleranter als der Winblows Onboard Client. Der hat mich ne Menge graue Haare gekostet bevor ich rausbekommen habe das der zwangsweise den DNS Namen aus der Client Konfig der Zieladresse mit dem im Server Zertifikat verifiziert. Ein weiterer Grund Windows den Rücken zu kehren !!Hier ist es also essentiell wichtig ins Server Zertifikat auf der pfSense wirklich alle 4 Optionen des Common Names einzutragen.
Wenns auf dem MBP rennt dann zu 100% auch auf allen iOS Geräten.
Test erfolgreich!
Klasse ! Hört sich gut an... wo ich was wie verstanden habe
Bin immer für konstruktive Kritik offen und wenn wir das Tutorial dadurch klarer und verständlicher machen umso besser.... Der pfSense gibst du am WAN Port testweise die statische IP 10.1.1.1 /24 und hier pfSense hat die WAN IP 10.99.1.110
Mmmhhh...ja klar das war einmal meine Labor Adressierung und einmal deine. Ich hatte jetzt keine Lust hier alles nur aus kosmetischen Gründen umzustellen.Soviel Intelligenz sollte man doch aber als Netzwerker haben die IP Adressierung auf seine lokal vorhandenen Netzwerke anzupassen, oder ?!
Für mich fehlt da der Bezug bei der VPN Config vom Netz 10.99.1.110 zu meiner festen IP von Unity Media.
Sorry, aber damit kann ich jetzt gar nichts anfangen ??! Bahnhof ??Was willst du uns damit sagen ?? Ob da nun am WAN Port eine IP aus dem oder irgendeinem Testnetz steht oder eine öffentliche von Unity Media ist doch vollkommen "Latte" !
Letztlich bezieht sich das dann nur auf das Server Zertifikat wo diese IP drinsteht. Aber da hast du letztlich Recht, du müsstest ein neues Server Zertifikat auf der pfSense generieren mit neuer WAN IP und das alte löschen, das ist richtig. Die Konfig selber bleibt aber immer gleich, die muss man natürlich nicht löschen !
Möglich das du hier was missverstanden hast.
da ich den DNS Server auf der Pfsense mal garnicht konfiguriert habe.
Wenn man das nicht macht, macht die pfSense das im Setup selber. Aber guter Hinweis, ich ändere das im Tutorial nochmal.da ich den DNS Server auf der Pfsense mal garnicht konfiguriert habe.
Das muss man auch nicht ! Zumal es kein DNS Server ist sondern nur ein Proxy Server der für die Funktion des IPsec VPNs irrelevant ist. Außerdem konfiguriert der sich immer selber denn er ist per Default aktiv.um die vpnca.crt zu per E-Mail zu versenden
Beim Apple kannst du das auch bequem per Airdrop machen wie ich jetzt die Settings anpassen muss, damit ich bei bestehnder VPN Verbindung mit einer RDP App bzw. irgendwelchen Fileexplorern oder Synology DSFile auf meine NAS Server und andere Recourcen zugreifen kann.
Da muss man nix mehr anpassen. Du hast scheinbar den Sinn einer VPN Verbindung nicht verstanden, kann das sein ??Das VPN sorgt mit dem Tunnel dafür das du genau so arbeiten kannst wie in einem lokalen LAN. Es transportiert deine IP Daten und schert sich nicht darum WAS du darüber sendest ob das RDP, Mail oder was auch immer ist.
Vermutlich bezieht sich deine Frage eher auf die Firewall Regel des VPN, oder ?
Klar statt Scheunentor any any kannst du hier die Schotten dichtmachen wenn du willst und nur entsprechende Anwendungen durchlassen wenn du willst.
Um abschliessend nochmal die Sache mit dem Common Name zu klären:
Der Common Name ist erstmal nur ein Name. ob der pfsense, pfSense oder klausbaerbel lautet ist vollkommen egal. Da es ASCII Zeichen sind kann es auch eine IP Adresse sein die dann aber als Textstring gesehen wird.
Das ist das was im Apple IKE VPN Client als "Entfernte ID" abgefragt wird. Diese ID muss zwingend mit dem Common Name übereinstimmen.
Ein Name macht sich da etwas logischer verständlich als wenn man eine IP Adresse als Textstring dort nimmt.
Der Windows Client hat aber z.B. nicht die Möglichkeit das anzugeben und überprüft diese "Enterfernte ID" sprich den Common Name mit der Ziel IP oder FQDN Hostnamen die er im Client konfiguriert hat. Und das kann dann zwingend nur der FQDN Hostname des Systems oder die IP des WAN Ports sein.
Deshalb ist es zwingend erforderlich ALLE 4 Optionen in das Server zertifikat zu integrieren um hier wasserrdicht zu sein:
- Common Name = Teststring (sollte immer der Hostname sein)
- FQDN Hostname = Hostname ohne Domain
- FQDN Hostname = Hostname mit Domain
- IP Adrress = IP Adresse WAN Port
Genau deshalb sind bei wechselnden IPs Common Name und Hostname so wichtig !
Fazit: Ich nehme deine durchaus richtigen Anregungen nochmal auf um das Tutorial hier noch etwas sicherer und verständlicher zu machen.
ber wenn ich dann das VPN aktivieren will wiederum nicht.
Wieso sollte es deiner Meinung dann nicht klappen...??Es ist vollkommen egal mit welcher Infrastruktur du verbunden bist. Das VPN geht auch über einen feuchten Bindfaden wenn es muß und dieser IP spricht.
Zum Thema WoL solltest du das hier lesen:
https://www.heise.de/ct/artikel/Wake-on-WAN-221718.html
und
https://www.heise.de/ct/hotline/Wake-on-LAN-ueber-VPN-324190.html
Da gibt es zig intelligente Lösungen zur Not mit einem lokalen Rasperry und WoL steuerbar über ein Web GUI.
Also mach dich erstmal schlau was WoL ist, die Protokoll Mechanismen wie es funktioniert und dann kannst du hier weiterphilosophieren...
Hallo,
Gruß,
Peter
Zitat von @Spitzbube:
Hast du mir vllt. noch abschließend ne Info, was VPN an Traffickosten verursacht?
Das hängt von deinen Verträgen und Tarifen ab was du anschließend für deine Bits und Bytes bezahlst welche du per VPN hin und her schiebst.Hast du mir vllt. noch abschließend ne Info, was VPN an Traffickosten verursacht?
Gruß,
Peter
Hallo,
Gruß,
Peter
Zitat von @Spitzbube:
T-Mobile Complete L+ Premiumn LTE 10 GB ca. 6-7 brauch ich monatlich für Streaming etc. der Rest kann verpulvert werden.
Da du nur einen ESXi verwalten kannst, aber generell nicht damit arbeiten kannst, reicht selbst mittels VNC oder RDP deine 3 - 4 GB (Zur verpulverung freigegebene Datenmenge ) locker aus um die VMs dort Hoch/Runter zu fahren. Selbst ein arbeiten auf den VMs sollte für Excel und Co. Reichen. Wie gesagt, es ist abhängig davon wie viele Bits und Bytes eben über deine VPN Leitung laufen.T-Mobile Complete L+ Premiumn LTE 10 GB ca. 6-7 brauch ich monatlich für Streaming etc. der Rest kann verpulvert werden.
Gruß,
Peter