Cisco SSL-AnyConnect-VPN Tester gesucht
Karl Gaissmaier
ich könnte ein paar versierte Tester brauchen.
Wer hat Lust den Cisco SSL-VPN Client zu testen?
Im Gegensatz zu IPSec ist das Userland und auch für Linux 64 Bit verfügbar.
Die Tests gerne aber auch mit Windows und MAC machen.
Die aktuellen Binaries und Dokumentation findet ihr unter:
http://www.uni-ulm.de/~gaissmai/downloads/anyconnect/
Einfach installieren und dann mit dem Server: vpn.uni-ulm.de
verbinden.
Insbesondere darauf achten, dass KEINE Zertifikatswarnungen
kommen dürfen Wenn doch, dann einen Screenshot machen und zusammen
mit Angaben zum Betriebssystem hier wieder posten. Bitte die Installation
in dem Fall abbrechen, insbesondere nicht "... trotzdem vertrauen"
anklicken.
Der AnyConnect Client soll den/die IPSec Clients auf all den Systemen
ersetzen auf denen er zur Verfügung steht. Für Apple iOS 4.x ist er angekündigt
aber noch nicht fertig. Also benötigen iOS 4.x Nutzer weiterhin Geduld, da
der mit dem iOS 4.x ausgelieferte VPN Client buggy ist und sich nicht mit
mittels 'IKE Hybrid XAUTH mode' gegen unsere VPN Server authentisieren kann.
Gruß und Dank
Charly
Michael Hellwig
> Insbesondere darauf achten, dass KEINE Zertifikatswarnungen
> kommen dürfen Wenn doch, dann einen Screenshot machen und zusammen
> mit Angaben zum Betriebssystem hier wieder posten. Bitte die Installation
> in dem Fall abbrechen, insbesondere nicht "... trotzdem vertrauen"
> anklicken.
>
darf ich auch einfach die Warnung pasten?
Warning: The following Certificate received from the Server could not be verified:
Name: C=DE, O=Universitaet Ulm, CN=vpn.uni-ulm.de, unstructuredName=vpn.uni-ulm.de
Common Name: vpn.uni-ulm.de
Company: Universitaet Ulm
Country: DE
Fingerprint: F4B701CC5B10670BF3ECF6A62CD10236DFBBB4A0
Angaben zum Betriebssystem:
32 bit Linux (ArchLinux) .. mehr Info nötig?
soeben getestet von 134.60.83.19 aus
Karl Gaissmaier
> On Tue, 10 Aug 2010 16:32:40 +0200, Karl Gaissmaier wrote:
>> Insbesondere darauf achten, dass KEINE Zertifikatswarnungen
>> kommen dürfen Wenn doch, dann einen Screenshot machen und zusammen
>> mit Angaben zum Betriebssystem hier wieder posten. Bitte die Installation
>> in dem Fall abbrechen, insbesondere nicht "... trotzdem vertrauen"
>> anklicken.
>>
>
> darf ich auch einfach die Warnung pasten?
yep
>
> Warning: The following Certificate received from the Server could not be verified:
> Name: C=DE, O=Universitaet Ulm, CN=vpn.uni-ulm.de, unstructuredName=vpn.uni-ulm.de
> Common Name: vpn.uni-ulm.de
> Company: Universitaet Ulm
> Country: DE
> Fingerprint: F4B701CC5B10670BF3ECF6A62CD10236DFBBB4A0
>
> Angaben zum Betriebssystem:
> 32 bit Linux (ArchLinux) .. mehr Info nötig?
> soeben getestet von 134.60.83.19 aus
auch das:
Welcher Browser und welche Version des Browsers wird eingesetzt?
Sieht so aus als ob das was Älteres ist. Wahrscheinlich ist das
"Deutsche Telekom Root CA 2" noch nicht in den
"Zertifizierungsstellen" mit ausgeliefert. Kann das sein?
Gruß
Charly
Michael Hellwig
hmmmmnein?
eye@fga:~> pacman -Q firefox
firefox 3.6.8-1
sollte doch neu genug sein, nicht?
heisst das, das cisco dingens nutzt die jeweilige Browser-Installation
für Zertifikats-foo?
Karl Gaissmaier
dann schau mal bitte nach im Firefox ob er das besagte ROOT cert drin hat.
> heisst das, das cisco dingens nutzt die jeweilige Browser-Installation
> für Zertifikats-foo?
Im Prinzip ja, ...
Bei den Betriebssystemen, die einen OS spezifischen Cert store haben,
verwendet er den. Bei Linux verwendet er soweit ich weiß den den
Firefox cert-store oder man muss das Root CA was unter:
/opt/cisco/vpn/ca?? schlag mich tot
deployen.
Also schau bitte nach, ob du das Telekom Root CA 2 im Firefox
hast. Bitet solange nicht mit der Installation weiter machen.
Vielen Dank fürs Testen!
Charly
Michael Hellwig
> dann schau mal bitte nach im Firefox ob er das besagte ROOT cert drin hat.
>
der firefox preferences-Dialog behauptet mal dass ja.
Karl Gaissmaier
browse mit dem Firefox bitte mal auf: vpn.uni-ulm.de
und schau ob die Verbindung mit dem Browser ohne Zertifkatfehler
klappt.
Die Meldung, dass nicht die ganze Verbingung verschlüsselt sei kannst
du ignorieren, da du hier ja keine sensitiven Daten eingaben kannst
(hab ich extra vernagelt).
Danach sollte der Firefox neben de Telekom root cert noch ein DFN
und erin Uni-Ulm Global cert im cert-store aufweisen.
Stimmt das?
Und jetzt probier bitte nochmals mit dem AnyConnect client
auf vpn.uni-ulm.de zu verbinden.
Kommt immer noch ein Cert Fehler?
Wenn ja, versuch mal mit ltrace festzustellen welchen cert-store er
denn so probiert.
Vielen Dank für die Mühe
Charly
Michael Hellwig
> Am 10.08.2010 20:07, schrieb Michael Hellwig:
>> der firefox preferences-Dialog behauptet mal dass ja.
>
> browse mit dem Firefox bitte mal auf: vpn.uni-ulm.de
>
> und schau ob die Verbindung mit dem Browser ohne Zertifkatfehler
> klappt.
>
ja
> Die Meldung, dass nicht die ganze Verbingung verschlüsselt sei kannst
> du ignorieren, da du hier ja keine sensitiven Daten eingaben kannst
> (hab ich extra vernagelt).
>
> Danach sollte der Firefox neben de Telekom root cert noch ein DFN
> und erin Uni-Ulm Global cert im cert-store aufweisen.
>
> Stimmt das?
>
ja
> Und jetzt probier bitte nochmals mit dem AnyConnect client
> auf vpn.uni-ulm.de zu verbinden.
>
> Kommt immer noch ein Cert Fehler?
>
ja, der kommt noch.
mehr testen von mir leider erst morgen, muss jetz noch ein Stückl Auto
fahren. Melde mich dann morgen mit weiteren Ergebnissen.
Joerg Fiedler
> Wer hat Lust den Cisco SSL-VPN Client zu testen?
Läuft zumindest Uni-Intern fehlerlos.
Einzig die Time-Out Zeit ist etwas kurz. Ich konnte den Netzwerkzugriff gar
nicht so schnell bestätigen, bevor der Fehler kam. Kann natürlich auch an der
aktuellen Uhrzeit liegen ;)
Beim 2ten Start lief alles fehlerfrei.
Werde heute Abend den Client unter TKom-Bedingungen mal testen und berichten.
Mit freundlichen Grüßen,
Jörg Fiedler
Karl Gaissmaier
Joerg Fiedler schrieb:
> Karl Gaissmaier schrieb:
>> Wer hat Lust den Cisco SSL-VPN Client zu testen?
> Habe gerade unter Mac OS 10.6.4 den Client installiert und getestet.
> Läuft zumindest Uni-Intern fehlerlos.
> Einzig die Time-Out Zeit ist etwas kurz. Ich konnte den Netzwerkzugriff
> gar nicht so schnell bestätigen, bevor der Fehler kam. Kann natürlich
> auch an der aktuellen Uhrzeit liegen ;)
hm, der Idle-Timeout liegt im mehreren 10min Bereich.
Wie lautete denn der Fehler. That's what the tests are for! ;-)
> Beim 2ten Start lief alles fehlerfrei.
> Werde heute Abend den Client unter TKom-Bedingungen mal testen und
> berichten.
Bin auf den Bericht gespannt.
Gruß und Dank
Charly
Hermann Schmidt
Karl Gaissmaier schrieb:
> Wer hat Lust den Cisco SSL-VPN Client zu testen?
Unter WinXP SP3 hats (fast) auf Anhieb funktioniert.
Beim ersten Versuch gabs vermutlich ein Problem mit dem virtuellen
Netzwerkadapter, der Verbindungsversuch brach mit folgenden
Fehlermeldungen ab:
"The VPN client driver has encountered an error."
"AnyConnect was not able to establish a connection to the specified
secure gateway. Please try connecting again."
Ein einfacher Reconnect hat dann funktioniert, ich hab es auch nicht
mehr geschafft, den Fehler zu reproduzieren.
viele Grüße,
Hermann
Karl Gaissmaier
Danke.
Gruß
Charly
Hermann Schmidt
Hermann Schmidt schrieb:
> Karl Gaissmaier schrieb:
>> Wer hat Lust den Cisco SSL-VPN Client zu testen?
>
> Unter WinXP SP3 hats (fast) auf Anhieb funktioniert.
ok, nach 5 Stunden bin ich jetzt mit folgender Meldung rausgeflogen :)
The secure gateway has terminated the VPN connection.
The following message was received from the secure gateway: Max time
exceeded
Reconnect war problemlos möglich. Bis dahin war die Verbindung (aus dem
Kabel-BW-Netz) sehr stabil, kein Vergleich zu OpenVPN.
viele Grüße,
Hermann
Karl Gaissmaier
> Hallo,
>
> Hermann Schmidt schrieb:
>> Karl Gaissmaier schrieb:
>>> Wer hat Lust den Cisco SSL-VPN Client zu testen?
>> Unter WinXP SP3 hats (fast) auf Anhieb funktioniert.
>
> ok, nach 5 Stunden bin ich jetzt mit folgender Meldung rausgeflogen :)
>
> The secure gateway has terminated the VPN connection.
> The following message was received from the secure gateway: Max time
> exceeded
yep, das ist Absicht und so bisher von mir konfiguriert. Es gibt einen
idle-timeout und einen max-connect timeout.
Man bedenke für was VPN eingesetzt werden soll. Es ist nicht dazu gedacht,
dass man stundenlang mittels einer Uni Adresse aus dem Internet
downloaded. VPN ist dazu da, Uni Ressourcen zu nutzen die auf den IP Adressbereich
der Uni-Ulm beschränkt sind, Punkt.
Gruß
Charly
Karl Gaissmaier
...
>
> ja, der kommt noch.
> mehr testen von mir leider erst morgen, muss jetz noch ein Stückl Auto
> fahren. Melde mich dann morgen mit weiteren Ergebnissen.
bin gespannt was du herausgefunden hast ...
Ok, ok, Geduld war noch nie meine Stärke ;-)
Danke im voraus
Charly
Hermann Schmidt
> Man bedenke für was VPN eingesetzt werden soll. Es ist nicht dazu gedacht,
> dass man stundenlang mittels einer Uni Adresse aus dem Internet
> downloaded. VPN ist dazu da, Uni Ressourcen zu nutzen die auf den IP
> Adressbereich
> der Uni-Ulm beschränkt sind, Punkt.
Gut, das ist soweit klar.
VPN im welcome zu benutzen, um "Lauscher" auszusperren ist also nicht
sinnvoll? Das wirklich vertraulich Daten trotzdem verschlüsselt werden,
ist ja klar :)
Das wäre mir jetzt als Verwendungszweck auch noch eingefallen.
viele Grüße,
Hermann
Karl Gaissmaier
ich weiß, ich weiß, viele Unis verwurschteln mit dem VPN
Authorization und Verschlüsselung.
Ich halte gar nichts vom erzwungenen VPN im WLAN, da spätestens nach unserem VPN-Server
die "vertraulichen Daten" ausgepackt und im Klartext on-the-wire gehen.
Vertrauliche Daten sollten mit einem vertraulichen end-to-end Protokoll
übertragen werden, also SSL/TLS, ssh, ...
Irgendwann in 2010 wird es hier auch 802.1X und eduroaming geben, dann kann
man im WLAN WPA2 machen und es gibt keinen Grund VPN für den Zweck zu
verwenden.
Gruß
Charly
Joerg Fiedler
>Wer hat Lust den Cisco SSL-VPN Client zu testen?
>Habe gerade unter Mac OS 10.6.4 den Client installiert und getestet.
>Läuft zumindest Uni-Intern fehlerlos.
>Einzig die Time-Out Zeit ist etwas kurz. Ich konnte den
>Netzwerkzugriff gar nicht so schnell bestätigen, bevor der Fehler kam.
>Kann natürlich auch an der aktuellen Uhrzeit liegen ;)
>hm, der Idle-Timeout liegt im mehreren 10min Bereich.
>Wie lautete denn der Fehler. That's what the tests are for! ;-)
Connection timed out
(gefühlte Zeit: 5s)
OK, habe gerade des Test gemacht.
Mit der Verbindung zum VPN-Ulm Server scheint alles zu klappen.
Nur Firefox weigert sich daraufhin, irgendwelche Seiten zu finden.
Selbiges mit Safari. Auch keine Seiten aus "uni-ulm.de"
Vienna (Newsfeed reader) findet neue Artikel nur von dem Ulmer VTS-Server.
Die CiscoAnyConnectStats kommen per Email.
Karl Gaissmaier
hm, hört sich nach einem DNS Problem an.
Ist ein anderer IPSec Client auf dem System installiert und ein
ipsec-kernel-modul geladen?
Also bitte nicht mit www-Browsern testen sondern mal
explizit mit nslookup oder wie auch immer das unter Mac
heißt.
Wenn die Namensauflösung außerhalb der Browser geht sieht es nach einem
Proxy Problem aus. Ist vor und nach dem Starten des AnyConnect Client die
Proxyeinstzellung des Systems/Browsers unterschiedlich?
Gruß und Dank
Charly
Karl Gaissmaier
> Karl Gaissmaier schrieb:
> >Wer hat Lust den Cisco SSL-VPN Client zu testen?
> >Habe gerade unter Mac OS 10.6.4 den Client installiert und getestet.
> >Läuft zumindest Uni-Intern fehlerlos.
> >Einzig die Time-Out Zeit ist etwas kurz. Ich konnte den
> >Netzwerkzugriff gar nicht so schnell bestätigen, bevor der Fehler kam.
> >Kann natürlich auch an der aktuellen Uhrzeit liegen ;)
>
> >hm, der Idle-Timeout liegt im mehreren 10min Bereich.
> >Wie lautete denn der Fehler. That's what the tests are for! ;-)
>
> Connection timed out
> (gefühlte Zeit: 5s)
>
> OK, habe gerade des Test gemacht.
> Mit der Verbindung zum VPN-Ulm Server scheint alles zu klappen.
> Nur Firefox weigert sich daraufhin, irgendwelche Seiten zu finden.
> Selbiges mit Safari. Auch keine Seiten aus "uni-ulm.de"
schau mal was er für nameserver verwendet, vor und nach dem Start
des AnyConnect Clients.
Gruß und Dank
Charly
Steffen Moser
> Also bitte nicht mit www-Browsern testen sondern mal
> explizit mit nslookup oder wie auch immer das unter Mac
> heißt.
Ja, sowohl "nslookup" als auch "dig" sind unter Mac OS X
verfügbar.
Gruß
Steffen
Joerg Fiedler
> hm, hört sich nach einem DNS Problem an.
> Ist ein anderer IPSec Client auf dem System installiert und ein
> ipsec-kernel-modul geladen?
Der Cisco VPNClient (4.9.01 (0100)) ist auf dem Rechner installiert.
(War beim Test aber nicht gestartet)
>
> Also bitte nicht mit www-Browsern testen sondern mal
> explizit mit nslookup oder wie auch immer das unter Mac
> heißt.
Werd ich probieren
> Wenn die Namensauflösung außerhalb der Browser geht sieht es nach einem
> Proxy Problem aus. Ist vor und nach dem Starten des AnyConnect Client die
> Proxyeinstzellung des Systems/Browsers unterschiedlich?
Nein, da ändert sich nichts.
Gruß
Michael Hellwig
> Michael Hellwig schrieb:
> ...
>> ja, der kommt noch.
>> mehr testen von mir leider erst morgen, muss jetz noch ein Stückl Auto
>> fahren. Melde mich dann morgen mit weiteren Ergebnissen.
>
>
> bin gespannt was du herausgefunden hast ...
>
Familien-Urlaubstag und Computer .. don't mix well.
anyway, was ich jetz grad rausgefunden hab, is dass es schwierig wird,
das zu debuggen. Weil: sobald ich ltrace auf den vpn-prozess ansetze
beendet sich der. Also direkt von Anfang an mit ltrace starten führt zu
länglichem output im terminal und dann einem Segfault.
Jetz hab ich den vpnui erstmal einfach so gestartet und dann, als er
schon lief (also halt direkt bevor ich auf "connect" klicken wollte)
ltrace -p <pid des vpn prozesses>
aufgerufen.
Das führt zu einem sofortigen beenden von vpnui mit der Meldung "trace
trap". Na fein.
any ideas?
ausserdem wärs sicher wertvoll wenn jemand mit einer weiter verbreiteten
Distribution (zB Ubuntu) da auch mal testen würde.
schaich alonso
Hallo,
Ich kanns vom Telekom-Netz aus ( ich bin p5B1672EF.dip.t-dialin.net ) gerade
mit Linux x86-64 nicht testen, weil der Uni-Webserver mich nicht auf die von
dir gepostete URL zugreiffen laesst (HTTP 403).
Gruss,
Alonso
schaich alonso
> Hallo,
>
> Ich kanns vom Telekom-Netz aus ( ich bin p5B1672EF.dip.t-dialin.net )
> gerade mit Linux x86-64 nicht testen, weil der Uni-Webserver mich nicht
> auf die von dir gepostete URL zugreiffen laesst (HTTP 403).
>
> Gruss,
> Alonso
Ignorier mich :P
Ich lad's mir grad von corona via ssh runter.
Alonso
Arno Luppold
> ausserdem wärs sicher wertvoll wenn jemand mit einer weiter verbreiteten
> Distribution (zB Ubuntu) da auch mal testen würde.
Mit Debian/testing (64 bit) tritt die exakt gleiche Zertifikats-Warnung
auf.
Und ltrace führt auch hier (sowohl beim vpngui als auch beim CLI-Tool)
zum von Dir beschriebenen segfault.
Grüße
Arno
schaich alonso
Das selbe auch auf gentoo.
Firefox oder Opera ist nicht und war nie installiert, mit konqueror auf
vpn.uni-ulm.de kann ich ebenfalls ohne Warnung verbinden, und der vpn Client
vertraut dem Zertifikat anschliessend trotzdem nicht.
Symbole aus diesen Bibliotheken laedt der Client bei mir ( LD_DEBUG ):
/lib/libc.so.6
/lib/libdl.so.2
/lib/libm.so.6
/lib/libnsl.so.1
/lib/libnss_dns.so.2
/lib/libnss_nis.so.2
/lib/libnss_files.so.2
/lib/libpthread.so.0
/lib/libz.so.1
/opt/cisco/vpn/lib/libcrypto.so.0.9.8
/opt/cisco/vpn/lib/libssl.so.0.9.8
/usr/lib/libxml2.so.2
Also glibc, zlib, libxml2 und cisco-mitgelieferte.
Arno Luppold
> Und ltrace führt auch hier (sowohl beim vpngui als auch beim CLI-Tool)
> zum von Dir beschriebenen segfault.
Ok, ltrace führt zwar zu einem segfault, aber strace funktioniert. :>
Output geht per Mail raus...
Grüße
Arno
Karl Gaissmaier
direkt aus den Release-Notes:
klopft Eure Systeme mal bzgl. der Firefox Randbedingungen ab.
Danke
Charly
##########################################
• x86 instruction set.
• 32-bit or biarch 64-bit processor
• 32 MB RAM.
• 20 MB hard disk space.
• Superuser privileges.
• libstdc++ users must have libstdc++ version 3.3.2 (libstdc++.so.5) or higher, but below version 4.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
hier wird es interessant bzgl. der Cert-Warnungen
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
• Firefox 2.0 or later with libnss3.so installed in /usr/local/lib, /usr/local/firefox/lib, or /usr/lib.
Firefox must be installed in /usr/lib or /usr/local, or there must be a symbolic link in /usr/lib or
/usr/local called firefox that points to the Firefox installation directory.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
• libcurl 7.10 or later.
• openssl 0.9.7a or later.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Java ist nicht notwendig, da ich das Webdeployment gleich ganz abgedreht
habe. Das bekomme ich nie und nimmer ohne Service-Nightmare hin.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
• Java 5 (1.5) or later. Iced Tea is the default Java package on Fedora 8. The only version that works for web installation is Sun Java. You must install Sun Java and configure your browser to use that instead of the default package.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
• zlib or later.
• gtk 2.0.0, gdk 2.0.0, libpango 1.0.
• iptables 1.2.7a or later.
• tun module supplied with kernel 2.4.21 or 2.6.
##############################################################
Arno Luppold
> an alle Linux Tester ohne mainstream Distribution:
Ich fühle mich mal angesprochen... ;)
> ##########################################
>
> • x86 instruction set.
>
> • 32-bit or biarch 64-bit processor
>
> • 32 MB RAM.
>
> • 20 MB hard disk space.
>
> • Superuser privileges.
Ja.
> • libstdc++ users must have libstdc++ version 3.3.2 (libstdc++.so.5) or
> higher, but below version 4.
libstdc++ 3.3.6 ist installiert.
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> hier wird es interessant bzgl. der Cert-Warnungen
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>
> • Firefox 2.0 or later with libnss3.so installed in /usr/local/lib,
> /usr/local/firefox/lib, or /usr/lib.
liegt unter /usr/lib und wird auch gefunden (laut strace).
> Firefox must be installed in /usr/lib or /usr/local, or there must be a
> symbolic link in /usr/lib or
/usr/lib/firefox existiert.
> /usr/local called firefox that points to the Firefox installation
> directory.
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Testweise gerade die aktuelle Firefox-Version heruntergeladen und unter
/usr/local/firefox/ platziert.
Laut strace benutzt er dann auch die /usr/local/firefox/libnss3.so
Aber: Weiterhin Zertifikatswarnung.
> • libcurl 7.10 or later.
7.21.0 ist installiert
> • openssl 0.9.7a or later.
0.9.8o ist installiert.
> • zlib or later.
zlib 1.2.3.4 ist installiert
Grüße
Arno
Karl Gaissmaier
> Einfach installieren und dann mit dem Server: vpn.uni-ulm.de
an alle Tester mit Zertifikatsfehler:
Seid ihr auch alle sicher, dass ihr versucht mit: vpn.uni-ulm.de
zu verbinden und NICHT mit vpn.RZ.uni-ulm.de ???
Gruß
Charly
Michael Hellwig
ja. _ganz_ sicher.
Arno Luppold
> Seid ihr auch alle sicher, dass ihr versucht mit: vpn.uni-ulm.de
> zu verbinden und NICHT mit vpn.RZ.uni-ulm.de ???
--------------
root:/opt/cisco/vpn/bin# ./vpn
Cisco AnyConnect VPN Client (version 2.5.0217) .
Copyright (c) 2004 - 2010 Cisco Systems, Inc.
All Rights Reserved.
>> state: Disconnected
>> warning: No profile is available. Please enter host to "Connect to".
>> notice: VPN Service is available.
>> registered with local VPN subsystem.
>> state: Disconnected
>> notice: VPN Service is available.
VPN> connect vpn.uni-ulm.de
>> contacting host (vpn.uni-ulm.de) for login information...
>> notice: Contacting vpn.uni-ulm.de.
>> warning: Unable to process response from vpn.uni-ulm.de.
>> notice: Please respond to Server Certificate Acceptance Request.
VPN>
Warning: The following Certificate received from the Server could not be
verified:
Name: C=DE, O=Universitaet Ulm, CN=vpn.uni-ulm.de,
unstructuredName=vpn.uni-ulm.de
Common Name: vpn.uni-ulm.de
Company: Universitaet Ulm
Country: DE
Fingerprint: F4B701CC5B10670BF3ECF6A62CD10236DFBBB4A0
accept? [y/n]: n
>> notice: Connection attempt terminated.
>> state: Disconnected
VPN> quit
goodbye...
root:/opt/cisco/vpn/bin#
---------------------
Grüße
Arno
Karl Gaissmaier
OK, nachdem die Fehlerquelle wohl ausgeschlossen ist, kann
es noch bei x64-bit Linux Probleme bereiten.
Bis zur Version 2.3 stand Folgendes in den Release Notes:
=========================================================
Fulfilling Requirements for Biarch Linux
If you are running 64-bit Linux, prepare it to run 32-bit AnyConnect binary files, as follows:
Step 1 Install the following packages:
. ia32-libs
. lib32nss-mdns.
Step 2 Install 32-bit Firefox into the /usr/local/firefox directory.
Step 3 Copy or link the following files from /usr/local/firefox to either /usr/lib32 or /opt/cisco/vpn/lib:
. libnssutil3.so
. libplc4.so
. libplds4.so
. libnspr4.so
. libsqlite3.so
. libnssdbm3.so
. libfreebl3.so
===========================================================================================================
ab 2.4 haben Sie die Requierements dahingehend geändert, dass sie
nur noch bestimmte Distributionen zulassen:
===========================================
Linux Distributions
. Red Hat Enterprise Linux 5 Desktop
. Ubuntu 9.x and 10.x
We do not validate other Linux distributions. We will consider requests to validate other Linux
distributions for which you experience issues, and provide fixes at our discretion.
==================================================================================================
Wahrscheinlich sind bei den Distros die obigen Anforderungen bereits
erfüllt.
Die x64-bit Linuxer mit cert-Warnungen könnten nun das Zeugs nachinstallieren, aber
leichter wäre es, wenn ich den Fingerprint des Certs für diesen Fall mit auf die
Anleitungsseite schreibe.
Was meint ihr?
Michael, Arno und Alonso, könnt ihr das Zertifkat mal akzeptieren, der
Fingerprint lautet:
Fingerprint: F4B701CC5B10670BF3ECF6A62CD10236DFBBB4A0
Mal sehen ob es dann weiter geht bzw. wie weit wir dann kommen und ob er jedesmal
wieder nachfragt. Ich weiß, dass er den Fingerprint im $HOME/.anyconnect
speichert. In den cert-Speicher kann er es ja nicht schreiben, da der
Zugriff ja definitiv nicht klappt.
Gruß
Charly
Michael Hellwig
> Karl Gaissmaier schrieb:
>> an alle Tester mit Zertifikatsfehler:
>>
>> Seid ihr auch alle sicher, dass ihr versucht mit: vpn.uni-ulm.de
>> zu verbinden und NICHT mit vpn.RZ.uni-ulm.de ???
>
> OK, nachdem die Fehlerquelle wohl ausgeschlossen ist, kann
> es noch bei x64-bit Linux Probleme bereiten.
>
nota bene, bei mir (ARCH auf Thinkpad X31) handelt sichs um ein 32 bit
Linux.
> Die x64-bit Linuxer mit cert-Warnungen könnten nun das Zeugs nachinstallieren, aber
> leichter wäre es, wenn ich den Fingerprint des Certs für diesen Fall mit auf die
> Anleitungsseite schreibe.
>
> Was meint ihr?
>
> Michael, Arno und Alonso, könnt ihr das Zertifkat mal akzeptieren, der
> Fingerprint lautet:
>
> Fingerprint: F4B701CC5B10670BF3ECF6A62CD10236DFBBB4A0
>
> Mal sehen ob es dann weiter geht bzw. wie weit wir dann kommen und ob er jedesmal
> wieder nachfragt. Ich weiß, dass er den Fingerprint im $HOME/.anyconnect
> speichert. In den cert-Speicher kann er es ja nicht schreiben, da der
> Zugriff ja definitiv nicht klappt.
>
a) connect klappt nach dem akzeptieren problemlos (also ich krieg noch
eine "all connectsions are logged!" Warnung, aber ich vermute mal die
ist Absicht). Und dann laufen Verbindungen auch via VPN.
b) wiederholte Verbindung führt zu keinen weiteren Warnungen. Jedenfalls
direkt nachher (also vpnui beendet hab ich schon dazwischen).
Karl Gaissmaier
okay, also damit könnte man leben.
Kannst Du im GUI mal "Enable Local LAN Access"
(hinter den Zahnrädern versteckt) ankreuzen und schauen
ob du Rechner im lokalen Netz pingen kannst. Sowas
ist nämlich zuhause manchmal nice to have um auch noch
gleichzeitig drucken zu können, etc.
Wie sieht dein iptables -nL aus?
Leider fummelt er da dran rum obwohl ich in der
cfg bestimme, dass er nichts machen soll.
Bei mir verhindert das den lokal LAN access, ich flushe dann
immer die ciscofw entries von Hand.
Passiert das bei Dir auch?
Gruß und Dank
Charly
Arno Luppold
> Was meint ihr?
Von mir aus kein Problem. Man kann die Validität ja auch im Browser
überprüfen... Wenn dann der Fingerprint im AnyConnect mit dem des
validen Zertifikats im Browser übereinstimmt --> Toll.
Wobei Fingerprint mit in die Anleitung schreiben vermutlich etwas
massentauglicher ist.
> Mal sehen ob es dann weiter geht bzw. wie weit wir dann kommen und ob er
> jedesmal
> wieder nachfragt.
Es funktioniert (auch ohne root-rechte), und er bringt bei weiteren
Verbindungsaufbauten keine Zertifikatswarnungen mehr.
Der vpnagentd muss allerdings im Vorfeld manuell gestartet werden (oder
manuell in irgendein Startupskript eingetragen werden).
Nach einem Reboot wurde der vpnagentd bei mir nicht automatisch gestartet.
Da der allerdings ein gesetztes s-bit hat geht auch das ohne root-Rechte.
Ich hatte allerdings ein nicht reproduzierbares Routing-Problem (DNS hat
funktioniert), Datenverkehr innerhalb der Uni (www.uni-ulm.de im Browser
aufrufen) auch, externe Hosts hatten einen Timeout.
disconnect und erneutes Verbinden hat das Problem behoben, und es lässt
sich jetzt nicht mehr reproduzieren.
Grüße
Arno
schaich alonso
> Die x64-bit Linuxer mit cert-Warnungen könnten nun das Zeugs
> nachinstallieren, aber leichter wäre es, wenn ich den Fingerprint des
> Certs für diesen Fall mit auf die Anleitungsseite schreibe.
>
> Was meint ihr?
>
> Michael, Arno und Alonso, könnt ihr das Zertifkat mal akzeptieren, der
> Fingerprint lautet:
>
> Fingerprint: F4B701CC5B10670BF3ECF6A62CD10236DFBBB4A0
>
> Mal sehen ob es dann weiter geht bzw. wie weit wir dann kommen und ob er
> jedesmal wieder nachfragt. Ich weiß, dass er den Fingerprint im
> $HOME/.anyconnect speichert. In den cert-Speicher kann er es ja nicht
> schreiben, da der Zugriff ja definitiv nicht klappt.
>
> Gruß
> Charly
Ich denke ich disqualifiziere mich als Tester, da ich von den obigen
Vorraussetzungen quasi garnichts ( ausser libsqlite ) erfuelle, und meine
glibc keinen 32-bit support hat ( d.h. ich kann die auch nicht einfach
nachinstallieren ).
Falls ich das ignoriere und es trotzdem versuche passiert follgendes
(wiederholbar):
VPN> connect vpn.uni-ulm.de
>> contacting host (vpn.uni-ulm.de) for login information...
>> notice: Contacting vpn.uni-ulm.de.
>> warning: Unable to process response from vpn.uni-ulm.de.
>> notice: Please respond to Server Certificate Acceptance Request.
VPN>
Warning: The following Certificate received from the Server could not be
verified:
Name: C=DE, O=Universitaet Ulm, CN=vpn.uni-ulm.de, unstructuredName=vpn.uni-
ulm.de
Common Name: vpn.uni-ulm.de
Company: Universitaet Ulm
Country: DE
Fingerprint: F4B701CC5B10670BF3ECF6A62CD10236DFBBB4A0
accept? [y/n]: y
>> Please enter your username and password.
Username: s_wschai
Password:
>> notice: Please respond to banner.
VPN>
All connections are logged!
accept? [y/n]: y
>> state: Connecting
>> notice: Establishing VPN session...
>> notice: Checking for profile updates...
>> notice: Downloading uni-ulm.xml - 100%
>> notice: Checking for product updates...
>> notice: Downloading - 100%
>> notice: Checking for customization updates...
>> notice: Checking for localization updates...
>> error: The VPN client agent has encountered an error.
>> error: AnyConnect was not able to establish a connection to the
specified secure gateway. Please try connecting again.
>> notice: Connection attempt has failed.
>> state: Disconnected
Wie du gesagt hast wurde $HOME/.anyconnect erstellt und mit xml-Daten
gefuellt. Nach einmaligem vertrauthaben des Zertifikats werde ich also auch
nicht mehr auf dessen "Ungueltigkeit" hingewiesen.
Gruss,
Alonso
Stefan Zaiser
bei mir läuft unter 32 Bit Ubuntu 10.04 alles bisher problemlos, es gab
keinerlei Zertifikatswarnungen.
Viele Grüße
Stefan
Joerg Fiedler
VOR CiscoAnyconnect
<Homer:~ jf$ nslookup
<> 134.60.81.1
<Server: 85.214.73.63
<Address: 85.214.73.63#53
<
<Non-authoritative answer:
<1.81.60.134.in-addr.arpa name = 81-gw-vrrp.rz.uni-ulm.de.
<
<Authoritative answers can be found from:
<81.60.134.in-addr.arpa nameserver = dns3.belwue.de.
<81.60.134.in-addr.arpa nameserver = dns1.belwue.de.
<81.60.134.in-addr.arpa nameserver = dns1.uni-ulm.de.
<81.60.134.in-addr.arpa nameserver = dns2.uni-ulm.de.
Ab hier NACH dem Start von CiscoAnyConnect
<> 134.60.82.77
<Server: 85.214.73.63
<Address: 85.214.73.63#53
<
<Non-authoritative answer:
<77.82.60.134.in-addr.arpa name = godfather.medizin.uni-ulm.de.
<
<Authoritative answers can be found from:
<82.60.134.in-addr.arpa nameserver = dns2.uni-ulm.de.
<82.60.134.in-addr.arpa nameserver = dns1.belwue.de.
<82.60.134.in-addr.arpa nameserver = dns1.uni-ulm.de.
<82.60.134.in-addr.arpa nameserver = dns3.belwue.de.
<> www.macnews.de
<Server: 85.214.73.63
<Address: 85.214.73.63#53
<
<Non-authoritative answer:
<Name: www.macnews.de
<Address: 193.164.134.215
Ein Aufruf der letzten Adresse via Browser geht nicht.
Dito Mail (keine Verbindung zum Imap-Dienst) - eigentlich keine Netzverbindung
nach "draussen".
Ein beenden von Cisco: Alles geht wieder.
Ein Ausdruck der Konsolen-Meldungen zum Cisco kommt per Email.
Dr. Rainer Kaluscha
ich habe das schöne Wetter :-< auch genutzt, um mal von daheim zu testen:
1. WinXP: problemlose Installation und Verbindungsaufbau (auch als
normaler User mit Netzwerk-Admin-Rechten)
2. Linux 32-bit (eine aufgemotzte OpenSuSE): Leider ein ziemliches Desaster:
Nach der obligatorischen Zertifikatswarnung konnte ich zwar zum
VPN-Server connecten. Danach klappten aber weder Zugriffe ins Uni-Netz
noch zum Rest der Welt. Ciscovpn setzt anscheinend die Routen nicht richtig:
Destination Gateway Genmask Flags Metric Ref Use
Iface
217.0.X.Y 0.0.0.0 255.255.255.255 UH 0 0 0 dsl0
10.X.Y.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
134.60.240.0 0.0.0.0 255.255.254.0 U 0 0 0
cscotun0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 dsl0
Ich hätte zumindest noch eine Route zu 134.60.0.0/16 erwartet ... Wenn
ich die manuell setze, komme ich zumindest ins Uni-Netz. Webseiten kann
ich aber nur direkt abrufen, nicht über meinen lokalen Proxy.
Ausserdem werden von Cisco etliche Firewall-Regeln neu gesetzt;
inwieweit diese mit meinen harmonieren, überblicke ich auf die Schnelle
nicht. Das muss ich mir mal in Ruhe anschauen ...
So long,
Rainer
Michael Hellwig
> Kannst Du im GUI mal "Enable Local LAN Access"
> (hinter den Zahnrädern versteckt) ankreuzen und schauen
> ob du Rechner im lokalen Netz pingen kannst. Sowas
> ist nämlich zuhause manchmal nice to have um auch noch
> gleichzeitig drucken zu können, etc.
>
nope, das mag nicht. Angehakt, trotzdem keine Verbindung ins lokale
Netz.
> Wie sieht dein iptables -nL aus?
>
hain INPUT (policy ACCEPT)
target prot opt source destination
ciscovpn all -- 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ciscovpn all -- 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain ciscovpn (2 references)
target prot opt source destination
ciscovpnfw all -- 127.0.0.1 127.0.0.1
ciscovpnfw tcp -- 192.168.1.104 193.197.62.198 tcp dpt:443
ciscovpnfw tcp -- 193.197.62.198 192.168.1.104 tcp spt:443
ciscovpnfw udp -- 192.168.1.104 193.197.62.198 udp dpt:443
ciscovpnfw udp -- 193.197.62.198 192.168.1.104 udp spt:443
ciscovpnfw udp -- 0.0.0.0/0 0.0.0.0/0 udp spt:68 dpt:67
ciscovpnfw udp -- 0.0.0.0/0 0.0.0.0/0 udp spt:67 dpt:68
ciscovpnfw udp -- 0.0.0.0/0 0.0.0.0/0 udp spt:546 dpt:547
ciscovpnfw udp -- 0.0.0.0/0 0.0.0.0/0 udp spt:547 dpt:546
ciscovpnfw all -- 134.60.240.173 0.0.0.0/0
ciscovpnfw all -- 0.0.0.0/0 134.60.240.173
ciscovpnfw all -- 134.60.240.0/23 134.60.241.255
ciscovpnfw all -- 134.60.240.173 134.60.241.255
ciscovpnfw udp -- 134.60.240.0/23 224.0.0.251 udp dpt:5353
ciscovpnfw udp -- 134.60.240.173 224.0.0.251 udp dpt:5353
ciscovpnfw all -- 0.0.0.0/0 255.255.255.255
ciscovpnfw all -- 134.60.240.173 255.255.255.255
DROP all -- 0.0.0.0/0 0.0.0.0/0
Chain ciscovpnfw (17 references)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
> Leider fummelt er da dran rum obwohl ich in der
> cfg bestimme, dass er nichts machen soll.
>
rumfummeln ist noch gar kein Ausdruck.
> Bei mir verhindert das den lokal LAN access, ich flushe dann
> immer die ciscofw entries von Hand.
>
> Passiert das bei Dir auch?
>
ah, das könnt ich noch testen, sekündchen
[Pause]
stimmt. Nachdem ich INPUT und OUTPUT geflusht hab gehts wieder.
Karl Gaissmaier
Joerg Fiedler schrieb:
...
> Hier der Ausdruck von nslookup:
>
> VOR CiscoAnyconnect
> <Homer:~ jf$ nslookup
> <> 134.60.81.1
> <Server: 85.214.73.63
> <Address: 85.214.73.63#53
> <
> <Non-authoritative answer:
> <1.81.60.134.in-addr.arpa name = 81-gw-vrrp.rz.uni-ulm.de.
> <
> <Authoritative answers can be found from:
> <81.60.134.in-addr.arpa nameserver = dns3.belwue.de.
> <81.60.134.in-addr.arpa nameserver = dns1.belwue.de.
> <81.60.134.in-addr.arpa nameserver = dns1.uni-ulm.de.
> <81.60.134.in-addr.arpa nameserver = dns2.uni-ulm.de.
>
>
> Ab hier NACH dem Start von CiscoAnyConnect
> <> 134.60.82.77
> <Server: 85.214.73.63
da stimmt was nicht, denn nach dem Tunnelaufbau
sollten eigentlich deine DNS Server umgeschrieben werden zu
134.60.1.111 und 134.60.111.111
da liegt der Hase im Pfeffer.
Warum das bei Deiner Installation nicht geht: ???
Gruß
Charly
Karl Gaissmaier
...
da müsste man nun mittels wireshark schauen, auf welchem
Interface er die DNS Anfragen stellt.
Wenn alles richtig wäre, müsste er es über das virtuelle tun
Interface schicken und nicht über das unverschlüsselte eth.
Hast du eine spezielle Installation als Rechner ist auch
Router Richtung LAN oder sowas ähnliches oder ist das ein mehr oder
weniger vanilla MacOS?
Sieht so aus, als ob wir hier remote nicht weiter kommen.
FRragen über Fragen.
Gruß
Charly
Karl Gaissmaier
> On Thu, 12 Aug 2010 17:32:27 +0200, Karl Gaissmaier wrote:
>> Kannst Du im GUI mal "Enable Local LAN Access"
>> (hinter den Zahnrädern versteckt) ankreuzen und schauen
>> ob du Rechner im lokalen Netz pingen kannst. Sowas
>> ist nämlich zuhause manchmal nice to have um auch noch
>> gleichzeitig drucken zu können, etc.
>>
>
> nope, das mag nicht. Angehakt, trotzdem keine Verbindung ins lokale
> Netz.
analog bei mir. Ich habe jetzt mal folgenden Trick auf dem Server gemacht:
Tunnelpolicy: Alles ABER schicke folgende Ausnahmen NICHT in den Tunnel:
10.0.0.0/8
169.254.0.0/16
172.16.0.0/12
192.168.0.0/16
Damit sollten die meisten Heimnetze hinter einem NAT-Router
glücklich werden. Diese Netze sollte man sowieso nicht in den
Tunnel schicken, da sie am ncähsten Router an der Uni-Ulm sowieso
verworfen werden.
Das mit dem "Allow local LAN access" nehme ich komplett
aus dem Profil raus. Nützt ja nichts wenn es nicht richtig funktioniert.
Bitte damit auch nochmals testen.
Vielen Dank
Charly
Karl Gaissmaier
> Michael Hellwig schrieb:
>> On Thu, 12 Aug 2010 17:32:27 +0200, Karl Gaissmaier wrote:
>>> Kannst Du im GUI mal "Enable Local LAN Access"
>>> (hinter den Zahnrädern versteckt) ankreuzen und schauen
>>> ob du Rechner im lokalen Netz pingen kannst. Sowas
>>> ist nämlich zuhause manchmal nice to have um auch noch
>>> gleichzeitig drucken zu können, etc.
>>>
>>
>> nope, das mag nicht. Angehakt, trotzdem keine Verbindung ins lokale
>> Netz.
>
> analog bei mir. Ich habe jetzt mal folgenden Trick auf dem Server gemacht:
>
> Tunnelpolicy: Alles ABER schicke folgende Ausnahmen NICHT in den Tunnel:
>
> 10.0.0.0/8
> 169.254.0.0/16
> 172.16.0.0/12
> 192.168.0.0/16
arrgh, bringt ev. auch nichts, wir eich gerade hier an meiner Routingtabelle
sehe. Muss ich zuhause nochmals testen, denn da habe ich ein Netz aus dem 192.168.0.0/16
Bereich. Hier versucht er die Routingtabelle so umzuschreiben, dass er diese Netze
an das ehemalige DefaultGateway schickt.
Mal sehen was passiert, wenn eins der Netze directly connected wäre.
Gruß
Charly
Joerg Fiedler
> Hallo,
> da stimmt was nicht, denn nach dem Tunnelaufbau
> sollten eigentlich deine DNS Server umgeschrieben werden zu
> 134.60.1.111 und 134.60.111.111
>
> da liegt der Hase im Pfeffer.
>
> Warum das bei Deiner Installation nicht geht: ???
gewünscht. Zugriff auf Zeitschriften, die über den Uni laufen müssen, klappt
alles etc etc.
Kann es evtl. an dem Mac-Port von ConnectAnywhere liegen - provokant gefragt...
Karl Gaissmaier
natürlich haben wir auch schon Macs damit getestet, aber ein Feldtest
immer was anderes.
Ich bin jetzt erstmal 3 Wochen im Urlaub, lese die E-Mails also
nur sporadisch bei schlechtem Wetter.
Gruß und Dank
Charly
Arno Luppold
> Der vpnagentd muss allerdings im Vorfeld manuell gestartet werden (oder
> manuell in irgendein Startupskript eingetragen werden).
> Nach einem Reboot wurde der vpnagentd bei mir nicht automatisch gestartet.
Ich weiß jetzt, warum das nicht funktioniert hat...
Das init-Skript ist nicht LSB-Konform. Es fehlt der komplette
### BEGIN INIT INFO
### END INIT INFO
Block
Des Weiteren wird auch nicht
/usr/lib/lsb/install_initd
zur Einrichtung verwendet sondern einfach nach /etc/init.d kopiert.
Vermutlich aufgrund des concurrent init-Systems zerschießt das Einiges
und führt beispielsweise dazu, dass sich bei mir über die
Debian-Paketverwaltung keine Pakete mehr
installieren/deinstallieren/rekonfigurieren lassen, die ebenfalls das
Init-System nutzen.
Entsprechende LSB-Referenz:
http://refspecs.freestandards.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic/initscrcomconv.html
Und ist eigentlich irgendwo dokumentiert, was das iptables-Target
"ciscovpnfw" mit den Paketen anstellt, die es da durchschickt?
Grüße
Arno
Karl Gaissmaier
Am 13.08.2010 19:11, schrieb Arno Luppold:
> Am 12.08.2010 17:34, schrieb Arno Luppold:
>
>> Der vpnagentd muss allerdings im Vorfeld manuell gestartet werden (oder
>> manuell in irgendein Startupskript eingetragen werden).
>> Nach einem Reboot wurde der vpnagentd bei mir nicht automatisch gestartet.
>
> Ich weiß jetzt, warum das nicht funktioniert hat...
> Das init-Skript ist nicht LSB-Konform. Es fehlt der komplette
> ### BEGIN INIT INFO
> ### END INIT INFO
> Block
>
> Des Weiteren wird auch nicht
> /usr/lib/lsb/install_initd
> zur Einrichtung verwendet sondern einfach nach /etc/init.d kopiert.
>
> Vermutlich aufgrund des concurrent init-Systems zerschießt das Einiges
> und führt beispielsweise dazu, dass sich bei mir über die
> Debian-Paketverwaltung keine Pakete mehr
> installieren/deinstallieren/rekonfigurieren lassen, die ebenfalls das
> Init-System nutzen.
oh jeh. aber debian wird ja auch laut Release-Notes nicht
unterstützt ;-), das hat Cisco also seit Rel. 2.3 dazugelernt.
>
> Entsprechende LSB-Referenz:
> http://refspecs.freestandards.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic/initscrcomconv.html
>
>
> Und ist eigentlich irgendwo dokumentiert, was das iptables-Target
> "ciscovpnfw" mit den Paketen anstellt, die es da durchschickt?
keep on dreaming
Gruß
Charly
Karl Gaissmaier
Steffen Moser
Da habe ich auch keine Ahnung. Ich kann nur feststellen, dass es
bei mir (Mac OS X 10.6.4) ohne Probleme tut. Ohne VPN-Verbindung
habe ich die "192.168.1.1" als IP-Adresse für den Nameserver
aktiv, beim Aufbau der VPN-Sitzung mit dem Cisco-AnyConnect-Client
ändert sich das automatisch in "134.60.1.111" und in "134.60.111.111".
Viele Grüße
Steffen
Joachim Becker
Hi,
sorry, hab's erst jetzt gelesen.
Die Installation auf meinem MacBookPro OS X 10.5.8 ging mit einem Klick,
Verbinden, alles klar, https auf verschiedene Server auch mit eigenen
Zertifikaten auf den ersten Blick absolut schmerzfrei.
Ich probiers heute abend mal von Zuhause und werd es als Ersatz für den
VPNClient einsetzen. Wenn Ihr nix mehr von mir hört, läuft alles prima
in der Welt der Äpfel (mit Mac statt i vornedran!).
Schöne Grüße,
Joachim
Tobias Herrmann
Sorry, dass ich mich hier so spät noch dranhänge, aber beim Thema
Routing würde mich interessieren, ob es beabsichtigt ist, auch für
Anyconnect eine Split-Verbindung einzurichten, dass nur Verkehr in den
Uni-Adressbereich durchs VPN geht.
Anyconnect-Installation und Verbindung (Win XP Pro) klappt einwandfrei,
nur setzt er immer den Uni-Gateway als Default und ich hab keine Chance,
meinen Router hier (zuhause) wieder als Default Gateway zu setzen, weil
Anyconnect das sofort wieder auf Uni umstellt.
Gruß
Tobias
Karl Gaissmaier
...
> Sorry, dass ich mich hier so spät noch dranhänge, aber beim Thema
no problem, ist ja auch immer noch nicht 'officially released'.
> Routing würde mich interessieren, ob es beabsichtigt ist, auch für
> Anyconnect eine Split-Verbindung einzurichten, dass nur Verkehr in den
> Uni-Adressbereich durchs VPN geht.
Nein, im Gegensatz zum alten IPSec mit dem zusätzlich angebotenen
split-tunnel Profil sehe ich davon nun aus leidvoller Erfahrung explizit ab.
Grund: Wenn man die digitale Biblio der Uni verwenden
will, führen zuviel Links aus der uni-ulm.de. domain heraus.
Der Traffic geht dann am Tunnel vorbei und es fehlt dadurch
die Erlaubnis auf diese Datenbanken zuzugreifen.
Der unbedarfte Nutzer meint dann, dass es ein Problem bei uns
sei und stellt unnötige Service Anfragen.
Der einzelne Nutzer muss eben wissen, wann er einen Tunnel an die
Uni machen will. Wenn er mit der Arbeit fertig ist muss er den
Tunnel eben abbauen bevor er wieder zu seiner üblichen Filesharing
Arbeit wechselt um Copyright geschütztes Material zu ziehen :-(
> Anyconnect-Installation und Verbindung (Win XP Pro) klappt einwandfrei,
> nur setzt er immer den Uni-Gateway als Default und ich hab keine Chance,
> meinen Router hier (zuhause) wieder als Default Gateway zu setzen, weil
> Anyconnect das sofort wieder auf Uni umstellt.
s.o.
Gruß
Charly
Tobias Herrmann
> Tobias Herrmann schrieb:
> ...
>> Sorry, dass ich mich hier so spät noch dranhänge, aber beim Thema
>
> no problem, ist ja auch immer noch nicht 'officially released'.
>
>> Routing würde mich interessieren, ob es beabsichtigt ist, auch für
>> Anyconnect eine Split-Verbindung einzurichten, dass nur Verkehr in den
>> Uni-Adressbereich durchs VPN geht.
>
> Nein, im Gegensatz zum alten IPSec mit dem zusätzlich angebotenen
> split-tunnel Profil sehe ich davon nun aus leidvoller Erfahrung explizit
> ab.
>
> Grund: Wenn man die digitale Biblio der Uni verwenden
> will, führen zuviel Links aus der uni-ulm.de. domain heraus.
> Der Traffic geht dann am Tunnel vorbei und es fehlt dadurch
> die Erlaubnis auf diese Datenbanken zuzugreifen.
> Der unbedarfte Nutzer meint dann, dass es ein Problem bei uns
> sei und stellt unnötige Service Anfragen.
>
Dieses Argument verstehe ich voll und ganz.
> Der einzelne Nutzer muss eben wissen, wann er einen Tunnel an die
> Uni machen will. Wenn er mit der Arbeit fertig ist muss er den
> Tunnel eben abbauen bevor er wieder zu seiner üblichen Filesharing
> Arbeit wechselt um Copyright geschütztes Material zu ziehen :-(
>
Es geht nicht um Filesharing, ich denke, aus dem Alter sind wir raus,
oder? ;)
Sondern darum, dass ich
a) einfach nicht möchte, dass all mein Traffic während der Zeit, in der
ich im Uni-VPN bin, über die Uni läuft, bzw. meine anderweitig
bestehende VPN-Verbindung ständig abreißt, nur weil ich das Uni-VPN
angeworfen habe, um im E-Book eine Seite weiter zu blättern.
b) gedacht habe, die Uni-Leitungen mit meinem Privat-Traffic nicht
unnötig belasten zu wollen.
Aber ich kann es nicht beurteilen, ob das Support- oder das
Traffic-Argument schwerer wiegt.
>> Anyconnect-Installation und Verbindung (Win XP Pro) klappt
>> einwandfrei, nur setzt er immer den Uni-Gateway als Default und ich
>> hab keine Chance, meinen Router hier (zuhause) wieder als Default
>> Gateway zu setzen, weil Anyconnect das sofort wieder auf Uni umstellt.
>
> s.o.
>
> Gruß
> Charly
Macht aber nichts, wenn es weiterhin so gut funktioniert, kann man mit
der Trennerei gut leben.
Danke für die schnelle Antwort!
Gruß
Tobias
Karl Gaissmaier
Tobias Herrmann schrieb:
...
>> Grund: Wenn man die digitale Biblio der Uni verwenden
>> will, führen zuviel Links aus der uni-ulm.de. domain heraus.
>> Der Traffic geht dann am Tunnel vorbei und es fehlt dadurch
>> die Erlaubnis auf diese Datenbanken zuzugreifen.
> Dafür nutze ich den Uni-Proxy-Server
hm, das sollte von extern nicht möglich sein, das wäre dann ja
ein offener Proxy. Wenn da wirklich eine Lücke ist, was
ich nicht so richtig glauben kann, dann müssen wir die schließen.
Von welchem Netz kommst du? Auf welchen Service greifst du zu?
Oder meinst du den WebVPN Service?
>
>> Der unbedarfte Nutzer meint dann, dass es ein Problem bei uns
>> sei und stellt unnötige Service Anfragen.
>>
> Dieses Argument verstehe ich voll und ganz.
>
>> Der einzelne Nutzer muss eben wissen, wann er einen Tunnel an die
>> Uni machen will. Wenn er mit der Arbeit fertig ist muss er den
>> Tunnel eben abbauen bevor er wieder zu seiner üblichen Filesharing
>> Arbeit wechselt um Copyright geschütztes Material zu ziehen :-(
>>
> Es geht nicht um Filesharing, ich denke, aus dem Alter sind wir raus,
> oder? ;)
War ja auch nicht persönlich gemeint sondern absichtlich etwas
zugespitzt formuliert ;-) Die langjährige Tätigkeit mit großen
Nutzergruppen macht einen vielleicht etwas sarkastisch.
Oftmals hat man eben mit Wünschen zu tun, die vortäuschen
A zu brauchen, dabei soll mit der Anfrage nur B versteckt werden.
> Sondern darum, dass ich
>
> a) einfach nicht möchte, dass all mein Traffic während der Zeit, in der
> ich im Uni-VPN bin, über die Uni läuft, bzw. meine anderweitig
> bestehende VPN-Verbindung ständig abreißt, nur weil ich das Uni-VPN
> angeworfen habe, um im E-Book eine Seite weiter zu blättern.
>
> b) gedacht habe, die Uni-Leitungen mit meinem Privat-Traffic nicht
> unnötig belasten zu wollen.
Die tunnel-all Policy kann natürlich nicht alle Arbeitsmuster optimal
abbilden, aber ist für die meisten Nutzer automatisch die bessere Wahl.
>
> Aber ich kann es nicht beurteilen, ob das Support- oder das
> Traffic-Argument schwerer wiegt.
Das Support Argument wiegt schwerer, sigh.
Beste Grüße
Charly
Michael Hellwig
> Tobias Herrmann schrieb:
>>> Grund: Wenn man die digitale Biblio der Uni verwenden
>>> will, führen zuviel Links aus der uni-ulm.de. domain heraus.
>>> Der Traffic geht dann am Tunnel vorbei und es fehlt dadurch
>>> die Erlaubnis auf diese Datenbanken zuzugreifen.
>
>> Dafür nutze ich den Uni-Proxy-Server
>
> hm, das sollte von extern nicht möglich sein, das wäre dann ja
> ein offener Proxy. Wenn da wirklich eine Lücke ist, was
> ich nicht so richtig glauben kann, dann müssen wir die schließen.
>
> Von welchem Netz kommst du? Auf welchen Service greifst du zu?
>
> Oder meinst du den WebVPN Service?
>
*Glaskugel* ich würde mal raten dass man ja sagen könnte, man kommt von
extern, nutzt das cisco vpn um auf den Uni-Proxy zu kommen und benutzt
dann den zum Fachliteratur-ansurfen (egal wo die dann wirklich liegt).
Karl Gaissmaier
aber dann würde split-tunneling für http/[proxied-proto] auch nichts
bringen, denn das ginge dann ja auch via uni proxy.
rätsel, rätsel
Gruß
Charly
Tobias Herrmann
Die Glaskugrl hat recht...
Tobias Herrmann
> Hallo,
>
> Tobias Herrmann schrieb:
> ...
>
>>> Grund: Wenn man die digitale Biblio der Uni verwenden
>>> will, führen zuviel Links aus der uni-ulm.de. domain heraus.
>>> Der Traffic geht dann am Tunnel vorbei und es fehlt dadurch
>>> die Erlaubnis auf diese Datenbanken zuzugreifen.
>
>> Dafür nutze ich den Uni-Proxy-Server
>
> hm, das sollte von extern nicht möglich sein, das wäre dann ja
> ein offener Proxy. Wenn da wirklich eine Lücke ist, was
> ich nicht so richtig glauben kann, dann müssen wir die schließen.
>
> Von welchem Netz kommst du? Auf welchen Service greifst du zu?
s. meine Antwort vom 9.9.2010, 18:56
>
> Oder meinst du den WebVPN Service?
Ne.
Ich hab 2 Browser offen, einer geht über den Split-Tunnel und den
Uni-Proxy ins WWW zum Literatur lesen.
Der andere geht ohne Proxy direkt ins Netz.
Also ne Lücke im Proxy gibts soweit ich bisher weiß keine...
Karl Gaissmaier
Tobias Herrmann schrieb:
...
>
> Ich hab 2 Browser offen, einer geht über den Split-Tunnel und den
> Uni-Proxy ins WWW zum Literatur lesen.
>
> Der andere geht ohne Proxy direkt ins Netz.
> Also ne Lücke im Proxy gibts soweit ich bisher weiß keine...
hoffen wir mal. Bei Deiner Art der Nutzung ist der split-tunnel
zwar praktisch aber du gehörst wohl eher zu einer Randgruppe.
Wenn ich dafür, wie in der Vergangenheit, extra Lösungen anbiete
verunsichere eher die große Masse.
Ich bin mir sicher, dass versierte Nutzer auch ohne split-tunnel eine
individuell sinnvolle Lösung basteln können.
Du könntest z.B. einen ssh Tunnel an die Uni für SOCKS verwenden und den Browser
zum Literatur lesen auf den dann lokalen SOCKS socket stellen.
Dies ist z.B. eine Lösung für Poweruser die mit den 0815 Lösungen
(die aber auch skalieren) für den Rest nicht glücklich werden.
Beste Grüße
Charly
Tobias Herrmann
> Hallo Tobias,
>
> Tobias Herrmann schrieb:
> ...
>>
>> Ich hab 2 Browser offen, einer geht über den Split-Tunnel und den
>> Uni-Proxy ins WWW zum Literatur lesen.
>>
>> Der andere geht ohne Proxy direkt ins Netz.
>> Also ne Lücke im Proxy gibts soweit ich bisher weiß keine...
>
> hoffen wir mal. Bei Deiner Art der Nutzung ist der split-tunnel
> zwar praktisch aber du gehörst wohl eher zu einer Randgruppe.
>
> Wenn ich dafür, wie in der Vergangenheit, extra Lösungen anbiete
> verunsichere eher die große Masse.
>
> Ich bin mir sicher, dass versierte Nutzer auch ohne split-tunnel eine
> individuell sinnvolle Lösung basteln können.
>
> Du könntest z.B. einen ssh Tunnel an die Uni für SOCKS verwenden und den
> Browser
> zum Literatur lesen auf den dann lokalen SOCKS socket stellen.
>
Guter Tipp! Danke!
Karl Gaissmaier
> Hallo zusammen,
>
> ich könnte ein paar versierte Tester brauchen.
>
> Wer hat Lust den Cisco SSL-VPN Client zu testen?
>
> Die Tests gerne aber auch mit Windows und MAC machen.
>
> Die aktuellen Binaries und Dokumentation findet ihr unter:
>
> http://www.uni-ulm.de/~gaissmai/downloads/anyconnect/
>
> Einfach installieren und dann mit dem Server: vpn.uni-ulm.de
> verbinden.
uh, oh, hatte mich wohl neulich 'verkonfiguriert', jedenfalls stelle
ich gerade fest, dass der SSL Tunnel nicht erlaubt war. Sollte jetzt
aber wieder gehen.
Sorry
Charly