• Apfeltalk ändert einen Teil seiner Allgemeinen Geschäftsbedingungen (AGB), das Löschen von Useraccounts betreffend.
    Näheres könnt Ihr hier nachlesen: AGB-Änderung
  • Viele hassen ihn, manche schwören auf ihn, wir aber möchten unbedingt sehen, welche Bilder Ihr vor Eurem geistigen Auge bzw. vor der Linse Eures iPhone oder iPad sehen könnt, wenn Ihr dieses Wort hört oder lest. Macht mit und beteiligt Euch an unserem Frühjahrsputz ---> Klick

.VPN File importieren

maxxlite.de

Empire
Registriert
15.06.09
Beiträge
84
Hallo an alle VPN Experten,

ich bin freiberuflicher Entwickler und bin nun bei einer Firma gelandet wo mir ein Windows Notbook als Arbeitsgerät gestellt wird.

Nun ist es so das ich ein paar Wochen von Zuhause aus Arbeiten muss.

Für mein Windows Notbook habe ich eine .vpn datei + Shresoft VPN bekommen.
Da ich kein großer Fan von Windows bin und auch keine externe Tastatur/Maus + Monitor habe, hab ich mir gedacht das ich mir das VPN einfach auf mein Macbook einrichte.

Problem: Es gibt kein Shresoft VPN für Mac… und ich finde auch kein VPN Tool was mit dieser .vpn datei zurecht kommt.

Habt ihr Tipps oder Hinweise?
 

JeepMatze

Friedberger Bohnapfel
Registriert
02.02.13
Beiträge
532
Hi,

ich hatte vor vier Jahren das gleiche Problem (VPN unter Win mit ShrewSoft). Damals hat ein Kollege eine Config-Datei für Ipsecuritas gebastelt.
Hier gibt's den Client: http://www.lobotomo.com/products/IPSecuritas/
Ob man die VPN Datei direkt importieren kann, weiß ich nicht. Aber das ist nur ein Textfile, also zur Not die Einstellungen manuell eintragen und halt den Admin nochmal nach dem Schlüssel im Klartext fragen.

Mittlerweile verwenden wir OpenVPN, das läuft glücklicherweise auch auf dem Mac...
 

Marcel Bresink

Hadelner Sommerprinz
Registriert
28.05.04
Beiträge
8.560
Das ist ein proprietäres Dateiformat, das nur von Shrew Soft benutzt wird. Damit kann kein anderes Programm etwas anfangen.

Es wäre hilfreicher, wenn Du einfach anfragen würdest, welches VPN-Verfahren mit welchen Parametern das Firmennetz verwendet. Wenn sich das an übliche Standards hält, kannst Du den VPN-Zugang mit wenigen Mausklicks selbst in macOS einrichten. Die VPN-Datei ist ja nur eine Komfort-Lösung, um manuelle Eingaben zu vermeiden.

Ein gängiges Verfahren ist z.B. "L2TP over IPSec" mit einem "Shared Secret".
 

dg2dra

Idared
Registriert
02.10.17
Beiträge
24
Problem: Es gibt kein Shresoft VPN für Mac… und ich finde auch kein VPN Tool was mit dieser .vpn datei zurecht kommt.
Habt ihr Tipps oder Hinweise?

Das stimmt so leider nicht - der ShrewSoft-VPN-Client läuft sehr wohl unter macOS. Nur gibts den nicht fertig, sondern zum selber compilieren als Source. Habe mit einiger Arbeit die Sourcen etwas angepasst, nun läuft er (wieder muss ich sagen) auch unter macOS 10.13 High Sierra. Hauptproblem ist das dieser Client gegen QT4 entwickelt wurde - was nun nicht mehr für macOS seit 10.12 oder höher supportet wird. Gegen QT5 linken geht nicht - hier müssten die ganzen Sourcen auf QT5 angepasst werden, eine Heidenarbeit, ich habe früher unter Linux viel mit QT programmiert, dort hat mich diese dauernde Änderung der Frameworks von Version zu Version auch schon saumässig angestunken. Es gibt aber einen Weg ihn dort wieder lauffähig zu bekommen, ist aber leider ne Menge Arbeit - man muss viel drumrum vorarbeiten (QT4, openssl, anpassen der Original-Sourcen). ABER: Er läuft und für mich ist er unverzichtbar, weil genau wie bei Dir ein Datenaustausch der VPN-Dateien zwischen WIN und macOS eben möglich ist. Das kann derzeit kein anderer Client - oder vielleicht der NCP samt seiner Abwandlung von LANCOM. OpenVPN ist leider keine Alternative, ich brauche IPSec und nicht OpenVPN. IPSecuritas habe ich auch mal ne Weile benutzt, kann aber bei verschiedenen Funktionen nicht mit dem Shrew mithalten, ausserdem ist das Verbindungsmanagment unter aller Sau. Btw, ich habe ca. 200 Verbindungen in meinem Shrew drin, da habe ich wirklichen keinen Bock die auf einen anderen Client umzurubbeln. Deswegen habe ich mir die Mühe gemacht, den wieder unter 10.13 fit zu bekommen, auch auf meinem iMac, der noch unter 10.12 läuft, geht es genauso.

Bildschirmfoto 2017-10-03 um 01.35.18.png

Gruss Heiko
 
Zuletzt bearbeitet:
  • Like
Reaktionen: Master123of

Master123of

Süsser Pfaffenapfel
Registriert
12.01.11
Beiträge
668
Hallo Heiko,

habe im Moment genau das selbe Problem. Wäre es möglich die Sourcen bzw. eine kurze Anleitung zur Verfügung zu stellen? Wäre wirklich sehr dankbar da ich momentan gezwungen bin die VPN Verbindungen über eine Ubuntu VM herzustellen was weder mich noch meinen Akku sonderlich freut.

Vielen vielen Dank im Voraus. Ich bin über jeden Tipp dankbar!

(QT4 und openSSL habe ich bereits installiert und die source habe ich herunter geladen)

Grüße
 
Zuletzt bearbeitet:

dg2dra

Idared
Registriert
02.10.17
Beiträge
24
habe im Moment genau das selbe Problem. Wäre es möglich die Sourcen bzw. eine kurze Anleitung zur Verfügung zu stellen?

Da es sich ja um frei zugängliche Sourcen handelt, habe ich das sowieso geplant. Nur eine "kurze" Anleitung wird's wohl eher nicht, man muss schon einiges machen - also Plug'n'Play wird's nicht ;)

Ich werde dazu auf meiner Firmenhomepage das komplette Setup public machen, wird nur noch wenig dauern, da bitte ich um etwas Geduld. Voraussetzung ist aber, einigermassen fit im Umgang mit der Shell sukzessive Compiler zu sein, also eben die üblichen UNIX-Basics. Wer von LINUX kommt oder sich dort bewegt, sollte damit aber kein Problem haben. Denn wir müssen den Shrew "from scratch" bauen, eine andere Lösung habe ich derzeit nicht gefunden. Ich würde ja auch gern einfach den ganzen Kram als .dmg oder .pkg/.mpkg veröffentlichen, mir ist es aber noch nicht ganz gelungen, die erforderlichen Libraries praktisch statisch einzubauen, so dass der User den Build-Prozess umgehen kann. Ich kann's derzeit nur dynamisch gegen OpenSSL und QT4 linken, was also bedingt, das auf den Macs compilieren zu müssen und die erforderlichen Pakete/Frameworks vorher bereitzustellen. Ideal wäre später mal eine Anpassung gegen QT5 und evtl. Nutzung des Apple-eigenen SSL-/Crypto-Krams weg von OpenSSL - das ist aber ein weiter Weg, besonders wegen QT5. Mal sehen, vielleicht mache ich mir irgendwann mal die Arbeit. Apple hat auch inzwischen einiges am Compiler gemacht, was den Einsatz älterer Sourcen etwas erschwert - meist sind das Änderungen hinsichtlich Sicherheit, man darf leider nicht mehr alles in system-relevante Bereiche verfrachten, was u.U. Änderungen an den Sourcen und/oder Art der Compilierung/Linkung nach sich zieht.
Beim Shrew waren die Änderungen aber noch überschaubar, es sind gar nicht sooo viele Anpassungen notwendig, so dass das auch der Otto-Advanced-User hinbekommen kann, ohne Softwareentwickler sein zu müssen.

Bis vor kurzem ging das auch ziemlich simpel per Homebrew - allerdings sind die Taps boneyard, wo der Shrew zu Hause war, inzwischen nicht mehr existent, auch ist mir mit der dortigen ruby-Anpassung die Compilierung zumindest der GUI-Tools (also die QT4 brauchen) nicht mehr geglückt, die zwei commandline-Tools iked (der ipsec-Daemon ) und ikec (der Client) kann man mit ein wenig Tricks noch direkt mit Homebrew hinbekommen. Aber auch Homebrew hat inzwischen einige Limitierungen (z.B. brew link geht nicht mehr, sudo-Sachen gehen auch nicht mehr wirklich). Natürlich alles in Sinne der Sicherheit :confused: , oh Pardon : "der für den User durch den Hersteller aufgezwungen imaginären Sicherheit". Also was ich auf meinen System für sicherheitsrelevant halte, entscheide nur ich - weder Apple noch sonstirgendjemand hat da was reinzupfuschen. Nachdem ja ALLE versagt haben bei den Ransomware-Wellen (zum Glück waren die Macs ja ziemlich verschont geblieben - das liegt aber nicht an Apple sondern am Basis-Konzept von UNIX im Allgemeinen gegenüber WIN), gebe ich auf das Sicherheitsgefasel, egal vom wem, nicht mehr viel. Ich stand diesen Sachen als IT-Profi schon immer skeptisch gegenüber, aber das hatte letztlich genau das bestätigt was ich immer schon vermutet hatte. Aber das ist ein anderes Thema...
 
Zuletzt bearbeitet:
  • Like
Reaktionen: ottomane

Master123of

Süsser Pfaffenapfel
Registriert
12.01.11
Beiträge
668
Das hört sich sehr gut an, hatte schon befürchtet dass es nicht all zu einfach sein wird. Wenn Du jemanden zum testen brauchst sag gerne Bescheid! Vielen Dank im Voraus! :)

Für mich wäre es auch denkbar Ipsecuritas als Alternative zu verwenden, leider habe ich es bis jetzt nicht geschafft mit den Daten aus der .vpn Datei eine funktionierende Konfiguration zu erzeugen, falls jemand hierzu Tipps hat wäre ich ebenfalls sehr dankbar :p
 

dg2dra

Idared
Registriert
02.10.17
Beiträge
24
Das hört sich sehr gut an, hatte schon befürchtet dass es nicht all zu einfach sein wird. Wenn Du jemanden zum testen brauchst sag gerne Bescheid! Vielen Dank im Voraus! :)

Für mich wäre es auch denkbar Ipsecuritas als Alternative zu verwenden, leider habe ich es bis jetzt nicht geschafft mit den Daten aus der .vpn Datei eine funktionierende Konfiguration zu erzeugen, falls jemand hierzu Tipps hat wäre ich ebenfalls sehr dankbar :p

Geht auch nicht so ohne weiteres. Letztlich musst Du die Parameter deiner VPN-Verbindung kennen und die dort "nachbauen" - ich war aber nie glücklich mit diesem IPSecuritas, vieles halte ich dort für umständlich und es geht auch nicht alles. NIE hab ich es geschaft, per automatischer IP-Adresszuweisung mit diesem Tool zu arbeiten. Man kann natürlich auch mit dem Apple-eigenen Kram - also build-in - VPN machen, da geht auch IPSec nach CISCO-Verfahren. Shrewsofts .vpn-Format ist letztlich deren eigenes, das lässt sich nun mal nicht in andere Clients importieren, es sei denn die hätten das implementiert (ist ja ausreichend dokumentiert), obwohl man beim Betrachten dieser .vpn-Datei (ist schlicht nur ASCII) unter Kenntnis von IPSec alles herauslesen kann, was die Parameter angeht - AUSSER Passwort, das ist BASE64 gehashed, also kein Klartext. VPN ist eben nicht VPN - ich benötige ausschliesslich einen flexiblen IPSec-Client, andere VPN-Technologien wie OpenVPN (kein IPSec, sondern SSL mit allen Vor- und Nachteilen bezüglich SSL) interessieren mich nicht UND ich muss zwischen Mac und WIN hin und her - und zwar mit der gleichen Datenbasis. Kann man übrigens mit dem Shrew hinbekommen, über meine private Cloud (owncloud) synce ich die VPN-Dateien zwischen Mac und WIN, und zwar "vollautomatisch". Geht auch, wird noch abschließender Teil meiner Doku werden. Und mal davon abgesehen - teilweise über 200 EUR für einen VPN-Client auszugeben, oder - noch schlimmer - Abo-Modell kommt mir nicht in Frage. Da stimmen die Relationen absolut nicht - wir reden hier von VPN-Clients und nicht von ganzen Applikationen wie Office oder was auch immer.

Getestet hab ich schon 3 verschiedene Macs, meinen MBP mit 10.13, meinen iMac mit 10.12 und das MPB meiner Frau mit 10.12. Hat überall funktioniert - gehe ich also davon aus, das ich das "in die Welt" entlassen kann.
 
Zuletzt bearbeitet:

Master123of

Süsser Pfaffenapfel
Registriert
12.01.11
Beiträge
668
Vermute mal dass es dann am Passwort gescheitert ist :eek: Den Rest konnte man sich relativ gut zusammen suchen.

Getestet hab ich schon 3 verschiedene Macs, meinen MBP mit 10.13, meinen iMac mit 10.12 und das MPB meiner Frau mit 10.12. Hat überall funktioniert - gehe ich also davon aus, das ich das "in die Welt" entlassen kann.

Das klingt sehr vielversprechend :) Freue mich schon die VM wieder abzulösen. :kiss:
 

dg2dra

Idared
Registriert
02.10.17
Beiträge
24
Vermute mal dass es dann am Passwort gescheitert ist :eek: Den Rest konnte man sich relativ gut zusammen suchen.
Das Passwort wird mittels BASE64 gehashed, deswegen könnte man ja den Rest durchaus importieren und einfach das Passwort weglassen, ist ja nicht unüblich solche Vorgehensweise. Der Aufbau der .vpn-Datei ist ja weitgehend und einigermassen gut dokumentiert und unter Kenntnis von IPSec und dessen Funktionen auch lesbar. Mit IPSecuritas hatte ich immer das Problem, vom VPN-Zugangspunkt (Router etc.) keine IP automatisch beziehen zu können, diese musste ich kennen und eintragen. Ausserdem hat nie wirklich funktioniert, mehrere Subnetze durch den Tunnel zu bekommen (ich hab Kunden die haben teilweise über 50 Tunnel an deren Routern dran - mache ich Fernwartung muss ich da durchkommen und zwar auf alle Subnetze, mit dem Shrew ging das immer).

Eine Bitte: Diese nun folgende Anleitung ist für User gedacht, die Grundkenntnisse im Umgang mit einer UNIX-Shell haben, wir bewegen uns hier nicht im Klicki-Bunti-Bereich der macOS-GUI !!! Ich kann und werde hier keinen Grundkurs in UNIX und dessen Bedienung "zu Fuss" abhalten - das setze ich voraus, das man sowas schon mal gemacht hat. Das ist also nichts für Anfänger und Einsteiger. Ich möchte wirklich Niemandem zu nahe treten, aber Kenntnisse im Umgang mit UNIX-Befehlen und den Tools der Shell sind hier wirklich essentiell ! Wer sich das also nicht zutraut - für den ist hier bereits Schluss, sorry. Diese Anleitung ist "as-is" zu verstehen, fachlich qualifizierte Fragen zum Thema können natürlich gern gestellt werden, ich werde versuchen, diese zu beantworten, sofern es möglich sein sollte.

Was Du schon mal vorbereiten kannst ist folgendes:
1. SIP (System Integrity Protection) muss/sollte abgeschalten werden, geht leider nur per Recovery boot (cmd + R beim Booten drücken) - dann wenn gestartet dort im Terminal "csrutil disable; reboot". Über Sinn oder Unsinn dieser Funktion kann man genauso streiten wie über UEFI. Mittels "csrutil status" kann man das beim normalen Start im Terminal prüfen, ob das geklappt hat. Wird übrigens ins EFI-BIOS/NVRAM geschrieben und überlebt sogar OS-Installationen - deswegen auch nur im Recovery-Mode machbar.
2. Der zweite wichtige Teil ist das Wiederaktivieren der Option "Apps-Download: Keine Einschränkungen" - die erstmal seit Sierra unsichtbar aber nicht weg ist - unter Systemeinstellungen => Sicherheit => Allgemein. Das geht mittels "sudo spctl --master-disable" im Terminal.
3. Wer also hier Bedenken hinsichtlich Sicherheit hat, muss hier stoppen. Für mich als IT-Profi stellt das kein Problem dar, die Abschaltung dieser Funktionen empfinde ich als handhabbar, da gibts ganz andere Probleme was die Sicherheit angeht - Stichwort Cloud. Muss also jeder mit sich selbst abmachen. Außerdem herrsche ich über mein System und sonst niemand - da bin ich absolut kompromisslos.

Keine Angst, kann man notfalls alles wieder rückgängig machen.

Fakt ist, es könnten Probleme beim Laden zweiter Kernel-Extensions geben, die wir aber benötigen. Genauer handelt es sich um die TUN/TAP Kernelmodule von hier: http://tuntaposx.sourceforge.net/. Diese installieren wir aber später per Homebrew, falls noch nicht erfolgt. Xcode9 installieren, mindestens 1x starten und EULA bestätigen, ich nutze die Komplettpackage aus dem MacAppStore, wobei wohl auch die Commandline-Tools reichen würden. Ohne das haben wir leider keinen Compiler ;) Weiterhin ist zu prüfen, ob ggf. schon QT5 neben QT4 installiert ist. QT5 sollte für unseren Zweck erstmal wieder ganz verschwinden. "brew uninstall qt" macht das, da inzwischen qt auf QT5 verlinkt wurde, QT4 gibts neuerdings mit qt@4. Wie das geht kann man hier nachlesen: https://github.com/cartr/homebrew-qt4

Mit QT5 lässt sich der Shrew nicht compilieren, da muss viel in den Sourcen von grundauf geändert werden, was einer teilweisen Neuentwicklung zumindest der GUI-Tools gleichkäme !!! Es wurde für QT4 entwickelt (sogar QT3 aber später an QT4 angepasst) und genau das müssen wir verwenden.

Der beste Ausgangspunkt wäre allerdings, Homebrew nochmals ganz zu entfernen, damit wir eine saubere Umgebung hinbekommen:
1. Alle installierten Pakete entfernen, am besten damit :
brew remove $(brew list) - meckert er rum oder kriegt nicht alle Pakete weg das probieren als Tritt in den Hintern:
brew remove --force $(brew list)
2. Dann Homebrew selber nochmal rausschmeissen:
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/uninstall)"
3. Homebrew wieder installieren:
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
Update: 3.1 TunTap nicht vergessen:
brew install Caskroom/cask/tuntap und prüfen, ob die geladen wurden und laufen:
kextstat | grep tuntap da muss dann was angezeigt werden wie hier z.B.:
heiko$ kextstat | grep tuntap
133 0 0xffffff7f83968000 0x7000 0x7000 net.sf.tuntaposx.tun (1.0) 95DD963D-E23D-3B0F-8DE8-A4D2F6BFA5CC <7 5 4 1>
134 0 0xffffff7f8396f000 0x7000 0x7000 net.sf.tuntaposx.tap (1.0) 23FDB715-3D0D-3A26-ACBA-E3794C231CB7 <7 5 4 1>

4. Dann am besten folgendes machen
brew install mc - installiert den Midnight Commander mc mit besten Grüßen an den Norton Commander aus DOS-Zeiten UND gleichzeitig schon OpenSSL, das hätten wir dann schon mal.
5. Jetzt QT4:
brew tap cartr/qt4
brew tap-pin cartr/qt4
brew install qt@4

Sierra installiert fertige binaries, High Sierra compiliert QT4 - dauert so um die 30min.
6. cmake brauchen wir noch:
brew install cmake

Sourcen vom Shrew werden noch benötigt: https://www.shrew.net/download/ike/ike-2.2.1-release.tgz

Altes Shrew-Zeug, falls vorhanden, entfernen:
rm -rf /Applications/Shrew*
rm -rf /usr/local/opt/shrew*
rm -rf /usr/local/bin/ikec
rm -rf /usr/local/sbin/iked


Hinweis: Immer wenn ein Befehl nicht geht mit "permission denied" fehlen entsprechende Rechte, dann dem Befehl ein sudo voranstellen (=superuser do). Pro shell-Sitzung erfolgt meist nur 1x beim erstmaligen Benutzen von sudo eine Passwortabfrage, danach macht er sudo einfach so, also nicht wundern. Früher hat man das als "root" gemacht, das ist nicht ganz ungefährlich, da UNIX eher selten nachfragt und einfach macht was man ihm sagt - und einen "zurück" Button gibts auch nicht ! Heute nutzen wir sudo, bleiben also im User-Kontext, da kann weniger "aus Versehen" passieren. Ja - ich habe auch schon mal unter Linux mein ganzes /etc geplättet - passiert schneller als man denkt.

und unter /Library/LaunchDaemons gucken, ob da was mit shrew dabei ist, wenn ja
sudo launchctl unload <filename>.plist entladen und
sudo rm <filename>.plist löschen
unter /usr/local/etc eine vorhandene iked.conf löschen
sudo rm /usr/local/etc/iked.conf

Wenn Du hier angekommen bist gib Bescheid - nur der Weg zum Ziel ist nicht mehr lang ;)
 
Zuletzt bearbeitet:

dg2dra

Idared
Registriert
02.10.17
Beiträge
24
Eigentlich kanns auch weitergehen:
1. Einen Ordner im Home-Verzeichnis erzeugen:
heiko$ mkdir src dort die ike-2.2.1-release.tgz reinkopieren
heiko$ cp /Users/heiko/Downloads/ike-2.2.1-release.tgz /Users/heiko/src
heiko$ cd /Users/heiko/src
heiko$ tar xzvf ike-2.2.1-release.tgz
heiko$ cd ike

Update 1.a: wenn mit Safari die Sourcen geladen werden, werden diese bereits entpackt. Dann so:
heiko$ mkdir src dort die ike-2.2.1-release.tar reinkopieren
heiko$ cp /Users/heiko/Downloads/ike-2.2.1-release.tar /Users/heiko/src
heiko$ cd /Users/heiko/src
heiko$ tar xvf ike-2.2.1-release.tar
heiko$ cd ike


2. Folgendes Rote in der CMakeLists.txt ergänzen (für mich als UNIX-Mensch nehme ich als Editor natürlich den vi bzw. vim - den kann ich im Schlaf bedienen, ist aber nicht jedermanns Sache)

project( IKE )

cmake_minimum_required( VERSION 2.4 )

set(CMAKE_INSTALL_PREFIX "/usr/local")

include_directories(/usr/local/Cellar/openssl/1.0.2l/include)
link_directories(/usr/local/Cellar/openssl/1.0.2l/lib)


if( COMMAND cmake_policy )


cmake_policy( SET CMP0003 NEW )


endif( COMMAND cmake_policy )

weiter unten in dieser Datei

set(
SEARCH_INC
/usr/local/Cellar/openssl/1.0.2l/include
/usr/local/include
/usr/include )

set(
SEARCH_LIB
/usr/local/Cellar/openssl/1.0.2l/lib
/usr/local/lib
/usr/lib )

set(
SEARCH_BIN
/usr/local/Cellar/openssl/1.0.2l/bin
/usr/local/bin
/usr/pkg/bin
/usr/bin )

set(
SEARCH_SYS
/usr/local/Cellar/openssl/1.0.2l/share
/usr/local
/usr/share
/usr )

das wars dann schon. Das /usr/local/Cellar/openssl/1.0.2l/ bitte prüfen ob vorhanden, das ist OpenSSL, was wir mit dem mc schon mitinstalliert hatten. Der Pfad kann differieren, falls eine andere Version vom OpenSSL da sein sollte. Dann auch in der CMakeLists.txt entsprechend anpassen ! Wie es aussieht, kann man keine gelinkten Pfade mehr nehmen, nur noch die Absolut-Pfade. Das hier war der knifflichste Teil, weil er immer wieder die .h Dateien aus dem include vom OpenSSL nicht finden wollte und abbrach.

cmake -DQTGUI=YES -DNATT=YES -DCMAKE_INSTALL_PREFIX=/usr/local \
-DQT_QMAKE_EXECUTABLE=/usr/local/Cellar/qt\@4/4.8.7_2/bin/qmake .
=> den letzten Punkt nicht vergessen, das ist kein Schreibfehler, aber mit Leerzeichen nach qmake !

in der Wurzel der Sourcen (!) aufrufen, also dort /Users/heiko/src/ike . Sollte normalerweise durchlaufen ohne nenneswerte Fehler oder Warnings.

Eigentlich legt man in den Sourcen einen Ordner build an, wechselt dort rein und ruft dann cmake <OPTION> .. auf.
Macht man das bei den Shrew-Sourcen, bricht das make später ab. Offensichtlich hat man die Pfadbeziehungen relativ ausgehend von der Source-Wurzel gesetzt. War auch so ein Stolperstein.

dann compilieren:
heiko$ make warten bis fertig - hoffentlich fehlerfrei - und installieren
heiko$ sudo make install => sudo ist hier entscheidend, denn er muss was nach /Library/Frameworks/ kopieren, das ist System-relevant und eben auch geschützt.

So jetzt sind wir schon fast fertig.
 
Zuletzt bearbeitet:

dg2dra

Idared
Registriert
02.10.17
Beiträge
24
im Quellcode-Verzeichnis
heiko$ cd script/macosx/

die net.shrew.iked.plist anpassen:
<array>
<string>/usr/local/sbin/iked</string>
<string>-F</string>
</array>

und die kopieren:
heiko$ sudo cp net.shrew.iked.plist /Library/LaunchDaemons

heiko$ sudo cp /usr/local/etc/iked.conf.sample /usr/local/etc/iked.conf => ohne die iked.conf startet der iked NICHT !!!

heiko$ sudo launchctl load net.shrew.iked.plist

nochmal raus geht mit
heiko$ sudo launchctl unload net.shrew.iked.plist

mit
heiko$ sudo ps x | grep iked prüfen ob der iked auch läuft wie bei mir (Zahlen können abweichen):
5507 ?? Ss 0:00.02 /usr/local/sbin/iked -F

Sollte der iked wirklich nicht starten, evtl. mal folgendes machen:
heiko$ sudo rm -fr /var/run/ikedi

SOOOO. Wenn alles so befolgt wurde, hast Du einen laufenden ShrewSoft-VPN-Client, den VPN Access Manager findest Du im Programmorder. Im Homeverzeichnis unter .ike gibts dann die Ordner certs und sites, unter sites liegen die *.vpn-Dateien.

Ich habe das auf 3 Macs umgesetzt - auf allen dreien GEHT DAS 100%. 2x 10.12 und 1x10.13, upgegraded inplace von 10.12. Ich kenne natürlich nicht jedes System - aber so sollte das funktionieren. Siehe mein Screenshot weiter oben in diesem Thread.

Editieren kann man im Terminal auch mit dem mc - deswegen die Empfehlung den zu installieren. Geiles Tool schon seit JAAAHREN unter Linux immer genutzt. Gehen die Funktionstasten beim Mac nicht, musst Du Fn+F1..F12 benutzen, Pageup oder Pagedown ebenfalls mit Fn+CursorHoch oder Fn+CursorRunter an den Pfeiltasten.

Die VPN-Dateien sollten auch wirklich auf .vpn enden, meine wollte der unter macOS nicht anzeigen, obwohl die da waren, WEIL ich keine Dateiendung .vpn hatte. Unter WIN ist das offensichtlich kein Problem, unter macOS wohl schon. Findet er die trotzdem nicht, mach mal heiko$ rm -fr .ike und starte den Access Manager neu, wird neu angelegt und dann nochmal unter .ike/sites neu reinkopieren.

Das TUNTAP-Zeugs ist deswegen erforderlich, weil er quasi ein virtuelles Netzwerkdevice (=Tunneladapter) erzeugen muss.

Es gab noch ein Stolperstein: Hast Du je das eingebaute VPN benutzt, KANN ES SEIN dass macOS den racoon - das ist der IPSec-Daemon vom macOS selbst autostartend mit dem LaunchD aktiviert. Beide nutzen natürlich die gleichen Ports geht also nicht zusammen, zumindest nach meinen Erkenntnissen. Startet also der iked NICHT - meist in den Logs a la "cannot bind socket" oder sowas , mal den racoon killen:
heiko$ sudo ps x | grep racoon
heiko$ sudo killall racoon


Ein SEEEHHR nützliches Helferlein, um den launchd zu steuern, wäre Peter Borgs LingonX : https://www.peterborgapps.com/lingon/ aktuell Version 5, kostet nur 10$ ist aber super. Kann man aber auch alles mittels launchctl machen, je nach Fähigkeiten :D
 
Zuletzt bearbeitet:

dg2dra

Idared
Registriert
02.10.17
Beiträge
24
Ergänzung: Sollte mit dem QT4-Zeugs was nicht gehen - lasse beim cmake mal das -DQTGUI weg, dann werden nur die commandline tools iked und ikec compiliert. Man kann nämlich die VPN-Verbindung auch so aufbauen:
heiko$ sudo /usr/local/sbin/iked falls man das mit dem launchd nicht hinbekommt startet das den iked einfach so
heiko$ cd .ike/sites
heiko$ ikec -r "<FILENAME>.vpn" -a
startet die VPN-Verbindung per commandline - interessant für scripting.

Leider kann man dann die VPN-Verbindung nicht so komfortabel editieren - oder besser gar nicht.

Der LaunchD ist sowas wie initd unter Linux, startet quasi services bzw. daemons, genaueres gibts mit
heiko$ man launchctl zu erfahren, die Steuerdateien sind halt XML-Dateien. Gibts auch ein schönes Tool von Herrn Bresink namens PerfEdit https://www.bresink.com/osx/PrefEdit-de.html, kostet aktuell EUR 10.57. Auch ein nützliches Helferlein für den Einen oder Anderen.

ToDo: Würde man es schaffen, alle Binaries samt deren benötigten Libs statisch zu linken und inkludieren, könnte man eine .DMG bzw. .pkg/.mpkg veröffentlichen. Soweit sind wird aber noch nicht ganz - habe ich aber noch auf dem Plan. Mal sehen.

Update 4.10.2017:
Sollten sich durch Update OpenSSL mal die Pfade zu OpenSSL ändern UND die jetzt gelinkte Version entfernt werden, so kann es passieren, dass der Shrew erst mal nicht mehr läuft. Wir linken direkt gegen die Libraries aus dem OpenSSL-Verzeichnis samt deren Pfade. Das ist so ähnlich wie mit DLLs unter WIN. Es sind dynamische Libs, die erst beim Starten der Binaries gebunden werden (=deswegen auch dynamic link libraries). Dann wären die neuen Pfade gemäß der obigen Anleitung in der CMakeLists.txt an die neuen/geänderten Pfade des OpenSSL anzupassen und der build/make-Prozess zu wiederholen.
Es gäbe noch die 2.Möglichkeit, auch OpenSSL from scatch zu bauen, die dann dort zu belassen und gegen diese zu linken. Bei QT4 wirds wohl keine Änderungen mehr geben - denke ich.


Summasumarum sind es letztlich nicht allzuviel Änderungen, die an den Sourcen gemacht werden mussten, aber bis das alles klar war und der Compiler endlich das gemacht hat was er sollte, hat schon viele Tests und Zeit in Anspruch genommen. Man hat da in den letzten XCode's wohl auch einiges geändert, auch am OS wurde wohl einiges abgeändert, meist wohl aus "Gründen der Systemsicherheit". Naja, wie dem auch sei, so wie ich das hier beschrieben habe, kann man den Shrew-Client zumindest lauffähig für macOS selbst bauen, wer ein bisschen fit ist oder unter Linux schon ähnliche Erfahrungen gesammelt hat, dem sollte da viel bekannt vorkommen - ich bin nun nicht der C/C++-Guru, habe aber speziell unter Linux schon KDE/QT-Software selbst entwickelt. So hab ich es als sportlichen Wettkampf verstanden, den Shrew wieder unter macOS fit zubekommen, weil ich auf den ungern verzichten möchte. Leider haben eben die Sourcen seit 2013 keine Anpassungen mehr erfahren - theoretisch müsste man den schon für QT5 fit machen, weil nicht klar ist, wie lange man QT4 noch in die aktuellen macOS reinwürgen kann - offiziell gibts da schon keinen Support mehr für 10.11/10.12/10.13.

Und noch was zum Augenzwinkern: Wer sich beschwert: "Aber bei mir gibts ja kein /Users/heiko" kommt die Faust durchs Forum :p
 
Zuletzt bearbeitet:

Master123of

Süsser Pfaffenapfel
Registriert
12.01.11
Beiträge
668
Hallo Heiko,

bei mir gibts ja kein /Users/heiko.

Kleiner Scherz, die Anleitung hat Tip-Top funktioniert und die VPN Verbindung steht schon. Ich kann Dir nur sagen dass ich sehr sehr dankbar für die Anleitung bin! Das hätte ich in 10 Jahren nicht geschafft! Ich bin mir sicher es gibt haufenweise User denen das hier helfen wird, man muss sich ja nur mal die Anzahl der Google Treffer zu dem Thema anschauen.

- Für Leute die normal nicht mit Xcode arbeiten: Ein mal starten und die AGBs akzeptieren (erscheint aber auch in der Fehlermeldung) :) (Xcode kann danach wieder weg)

- Was bei mir auch noch war: ike-2.2.1-release.tgz wurde nach dem download automatisch zu ".tar", einfach in den Befehlen ändern und dann klappt das.

Habe schon Angst vor mac OS high high Sierra :p

Vielen Dank nochmals!

Grüße
 
Zuletzt bearbeitet:

dg2dra

Idared
Registriert
02.10.17
Beiträge
24
Super das es alles geklappt hat - da war ja meine Anleitung benutzbar :D
Habe Deine Hinweise bereits ergänzt - über manches denke ich echt nicht nach, wie XCode starten oder .tar oder .tgz :oops:

1. Ja es ist richtig, Xcode muss einmal gestartet werden, EULA akzeptieren, weil danach installiert er noch verschiedende Dinge, hatte ich ganz vergessen darauf hinzuweisen. Es reicht allerdings e.E. auch zu, nur die command line tools (enthält u.a. den Compiler) zu installieren:
heiko$ xcode-select --install

Ich denke nur, im MacAppStore XCode zu suchen und zu installieren, ist für die Meisten der einfachere Weg - sind allerdings auch knapp 5 GB Download. :rolleyes:

2. Ja, Du nutzt vermutlich Safari zum Download. Der entzipped das schon, das ist richtig. Dann reicht das:
heiko$ tar xvf ike-2.2.1-release.tar

Die .tgz steht eigentlich für .tar.gz , also erst gunzip bzw. unzip und dann un-tar-en mit tar xvf <filename>.tar
Andere Browser wie Firefox oder Chrome machen das aber nicht, dort gilt dann tar xzvf <filename>.tgz
Die z-Option beim tar behandelt einfach Zeugs, was gezippt wurde.

3. Keine Angst vor 10.13. Shrew geht dort auch - nur QT4 wird dort compiliert, bei Sierra ist das schon eine Binary-Package. Dauert halt etwas länger - bei mir brauchte der Compiler ca. 30min für QT4. Ansonsten ist mein 10.13 wegen SSD natürlich auf APFS konvertiert worden. Ich konnte bis jetzt aber keine Probleme bei meinem MBP feststellen. Es läuft noch alles wie unter 10.12 . Den Shrew hatte ich schon bereits unter 10.12 drauf - damals noch komplett mit Homebrew gemacht, ging aber irgendwie nicht mehr seit der Geschichte mit Homebrew und deren Wechsel auf QT5, denke seit 10.12.6 war das so. Deswegen kam mir ja dann die Idee, "Nun wenn das mit Homebrew nicht geht - dann eben back to the roots und from scratch bauen - wie früher unter Linux". Hat ja dann auch geklappt.

Naja, wer noch nie C/C++ programmiert hat - was ja nicht schlimm ist - hat natürlich Schwierigkeiten, wenn der Compiler Fehler ausspuckt. Ich weiss diese ja zu interpretieren. Leider verhalten sich die Compiler unter den verschiedenen OS unterschiedlich - und BSD ist nicht Linux ist nicht macOS/Darwin. Und dieses cmake - bei Linux macht das meistens configure - ist schon eine ziemliche Herausforderung, denn auch von diesem cmake gibts verschiedene Versionen mit unterschiedlichen Verhalten.

Wir haben erst ein ernsthaftes Problem, wenn wir QT4 nicht mehr compiliert bekommen, dann ist wirklich erstmal Schicht im Schacht mit dem Shrew. Es gibt aber noch so viel Sourcen basierend auf QT(4) "in the wild" - das ist ja essentiell für den KDE unter Linux - das sich wohl später auch noch Wege finden werden, wobei der aktuelle KDE natürlich bereits an QT5 angepasst wurde, was man mit dem Shrew eigentlich auch machen müsste, um noch lange damit Spass zu haben.

Noch was zum Einsatz Shrew. Läuft bei mir mit:
- allen Fritzboxen
- LANCOM
- CISCO
- pfsense

im Prinzip alles was IPSec kann. Auch zertifikatsbasierendes VPN funktioniert - bei mir getestet speziell mit LANCOM-Routern. Es geht vor allen Dingen auch multi-Subnet-Routing durch den Tunnel, also mehr als nur ein Subnet auf der anderen Seite des Tunnels, was der Router dort also durch weitere eigene Tunnel dann weiterschickt.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: MacAlzenau

MacAlzenau

Golden Noble
Registriert
26.12.05
Beiträge
22.501
Ich finde das, auch wenn ich fast nichts verstanden habe im ersten Anlauf (vor allem mangels Bedarf, bisher jedenfalls, an VPN) super, wenn jemand hier so eine lange und detaillierte Anleitung postet. Ganz ganz herzlichen Dank, und ich speichere mir den Thread auf jeden Fall mal ab.
Auch wenn ich ziemlich sicher bin, bei Bedarf später mal an den Compilierungsproblemen mit den verschiedenen Qt-Versionen zu scheitern.

Das Problem, daß manche keinen Ordner /Users/heiko finden, kann man leicht beheben: wir richten einfach alle einen zweiten Benutzer ein namens heiko.
Denn einen zweiten Benutzer kann man immer brauchen.
 

dg2dra

Idared
Registriert
02.10.17
Beiträge
24
Noch eine Randbemerkung - wir sind ja hier im Business-Bereich. Der Einsatz eines VPN-Clients zieht ja Gründe nach sich, weil man mit dem Tunnel ja irgendwas machen will. Für diejenigen, die das auch zu Remote-Support/Fernwartungszwecken oder ähnlichen verwenden, noch ein Software-Tipp:

Seit ca. 2 Jahren arbeite ich mit dem Tool Royal TSX https://www.royalapplications.com/server/main/download .
Den gibts auch für WIN gleichermassen und kann:
- RDP
- VNC
- VMware ESX/vSphere
- Teamviewer
und noch einiges anderes, kostet so um die 55 EUR/Lizenz 1 User (Bundle WIN+Mac).
Dieses Tools hat auch einen Importer für den Remote Desktop Connection Manager (RDCMan) von M$, einem beliebten Tool für multiple RDP-Verbindungen, oft von uns Admins verwendet. Der Import war für mich superbequem, ich hatte ca. 300 RDP-Connections in dem bis dahin von mir genutzen RDCMan - die wollte ich nicht wirklich neu machen ;). Durch die Existenz einer macOS und WIN-Version lassen sich sogar via Cloud oder was auch immer, die Konfigdateien zwischen diesen beiden Systemen austauschen bzw. syncen. Ich nutze das in meiner Firma nun schon seit ca. 2 Jahren in Kombi mit dem Shrew - so konnte ich meine Supportaufgaben auch auf dem Mac gleichermassen bewerkstelligen - alles synchron zwischen macOS und WIN. Das nur mal so als Tipp nebenbei. Es gibt auch noch einen Server Royal TS Server - ich habe aber hier von den Clients gesprochen - gibt aber auch Kombolizenzen Server + Client.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: trexx

dg2dra

Idared
Registriert
02.10.17
Beiträge
24
Ich finde das, auch wenn ich fast nichts verstanden habe im ersten Anlauf (vor allem mangels Bedarf, bisher jedenfalls, an VPN) super, wenn jemand hier so eine lange und detaillierte Anleitung postet. Ganz ganz herzlichen Dank, und ich speichere mir den Thread auf jeden Fall mal ab.

Die Grundidee hinter Open Source - die ich sehr begrüße - ist ja das Sharing an Wissen und Offenheit. Ich habe ja den Shrew nicht entwickelt, was mich eigentlich zumindest lt. GPL (beim Shrew ist mir das Lizenzmodell allerdings nicht zu 100% klar - trifft wohl so nur für die UNIX-Version zu - die Sourcen zu der WIN-Version sind ja nicht Open Source) dazu verpflichtet, meine Änderungen zu veröffentlichen - was ich ja hiermit getan habe. Ich nutze ja genauso Wissen Anderer. Funktioniert also nur mit Geben und Nehmen.

Mein Umstieg auf den Mac - beginnend damals mit dem Erscheinen des ersten Mac mini G4 - war darin begründet, das was ich davor unter Linux gemacht habe, auf einem anderen System auch wieder machen zu können plus eben das was den Mac sonst noch so ausmacht. Ich komme von der Ausbildung her aus dem UNIX-Bereich, auch wenn ich heute beruflich primär WINDOWS machen muss, weil das eben bei meinen Kunden im Business-Bereich nun mal omnipräsent ist. Linux - meist für Serverplattformen - ist auch noch dabei und macOS eben auch. Muss ich alles können - der Kunde setzt das voraus. So bewege ich mich eben zwischen den (OS-)Welten, was interessant ist und nie langweilig wird - und gelegentlich zu "sportlichen Wettkämpfen" führt.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: trexx