VPN Verbindung mit Sonicwall unter Windows 7

[Dirk Wagner]

Hi Leute,

ich habe hier eine ältere Sonicwall SoHo 3 ohne GVC Lizenzen.

Mit hilfe des alten VPN-Clients von Sonicwall kann ich eine Verbindung
zur Sonicwall herstellen.

Leider funktioniert dieser Client aber nicht mehr unter Windows 7.

Man findet zwar eine Menge Treffer bei der Suche nach Sonicwall VPN
Client und Windows 7 - aber dabei handelt es sich meist um einen Trick,
um den Global VPN Client unter Windows 7 zum laufen zu bekommen.

Leider wird das der dort beschriebene IPSec Driver vom alten Client erst
gar nicht installiert.

Gibt es die Möglichkeit, ohne den Sonicwall Client mit
"Windows-Bordmitteln" eine Verbindung zur Sonicwall aufzubauen?

Ciao

dirk

[Juergen Ilse]

Hallo,

Dirk Wagner <usenet...@diwasoft.de> wrote:
> ich habe hier eine ältere Sonicwall SoHo 3 ohne GVC Lizenzen.
> Mit hilfe des alten VPN-Clients von Sonicwall kann ich eine Verbindung
> zur Sonicwall herstellen.
> Leider funktioniert dieser Client aber nicht mehr unter Windows 7.

Hast du mal den (freen) "shrewsoft" VPN-Client probiert?

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.

[Dirk Wagner]

Juergen Ilse <jue...@usenet-verwaltung.de> wrote:

> Hast du mal den (freen) "shrewsoft" VPN-Client probiert?

Danke für den Tipp.

Der baut immerhin schon mal die Verbindung auf und "spricht" mit der
Sonic-Wall.
Jetzt muss ich nur noch herausfinden, wie die Begrifflichkeiten des
SonicWall Clients auf den Shrewsoft Client zu übertragen sind.

Momentan hängt der Verbindungsaufbau in Phase 1:
Notify:Invalid_ID_Info

Im Sonicwall Client habe ich unter "My Identity" als ID Type "Domain
Name" und als ID die Seriennummer der SonicWall.

Aber egal, welchen der 4 möglichen Typen der "Local Identity" ich beim
Shrewsoft Client auswähle undd ort die Seriennummer als ID eingebe (bzw.
die IP bei der entsprechenden Auswahl - die Verbindung kommt nicht
zustande.

Bei "Key Identifier" kommt ein Timeout
Bei den anderen Möglichkeiten kommt "Gateway authentification error"

Ciao

dirk

[Dirk Wagner]

Dirk Wagner <usenet...@diwasoft.de> wrote:

> Danke f�r den Tipp.

Nach ein wenig st�bern auf der Webseite habe ich leider die Aussage
gefunden, dass SonicWall PRodukte noch nicht vom ShrewSoft VPN Client
unterst�tzt werden ;-(

Ciao

dirk

[Burkhard Ott]

On Wed, 07 Mar 2012 12:59:51 +0100, Dirk Wagner wrote:


> Momentan hängt der Verbindungsaufbau in Phase 1: Notify:Invalid_ID_Info
>
> Im Sonicwall Client habe ich unter "My Identity" als ID Type "Domain
> Name" und als ID die Seriennummer der SonicWall.
> Aber egal, welchen der 4 möglichen Typen der "Local Identity" ich beim
> Shrewsoft Client auswähle undd ort die Seriennummer als ID eingebe (bzw.
> die IP bei der entsprechenden Auswahl - die Verbindung kommt nicht
> zustande.
>
> Bei "Key Identifier" kommt ein Timeout Bei den anderen Möglichkeiten
> kommt "Gateway authentification error"

Benutzt Du aggressive oder main mode?

cheers

[Dirk Wagner]

Burkhard Ott <news...@derith.de> wrote:

> Benutzt Du aggressive oder main mode?

aggressive...

Ich habe versucht, die auf einem XP-Rechner funktionierende
Konfiguration des SonicWall Clients auf den Shrewsoft zu übertragen...

ciao

dirk

[Burkhard Ott]

Ich hatte, allerdings vor Jahren Openswan unter linux laufen, Zieldevice
war eine 5600 oder sowas. Generell ist Sonicwall etwas 'crappy' aber
IPSec sollte schon funktionieren.
So wie es aussieht schlaegt in Phase 1 die Authentifizierung fehl, check
das Du auf beiden Seiten mode und die Proposals (Verschlusselungs und
Integritaets alg) gleich ist.
Was sagt die sonicwall im Log?

[Dirk Wagner]

Sind gleich...

> Was sagt die sonicwall im Log?

03/07/2012 17:41:07.160 SENDING>>>> ISAKMP OAK INFO (InitCookie
0xf489476e3aa956fc, MsgID: 0x0) (NOTIFY:INVALID_ID_INFO) 192.168.15.2,
500 10.10.10.10, 500

03/07/2012 17:41:07.160 IKE Responder: Received Aggressive Mode request
(Phase 1) 10.10.10.10 192.168.15.2

03/07/2012 17:41:07.144 RECEIVED<<< ISAKMP OAK AG (InitCookie
0xf489476e3aa956fc, MsgID: 0x0) (SA, KE, NON, ID, VID, VID, VID, VID,
VID, VID, VID, VID, VID, VID, VID) 10.10.10.10, 500 192.168.15.2, 500

03/07/2012 17:41:02.160 SENDING>>>> ISAKMP OAK INFO (InitCookie
0xf489476e3aa956fc, MsgID: 0x0) (NOTIFY:INVALID_ID_INFO) 192.168.15.2,
500 10.10.10.10, 500

03/07/2012 17:41:02.160 IKE Responder: Received Aggressive Mode request
(Phase 1) 10.10.10.10 192.168.15.2

03/07/2012 17:41:02.160 RECEIVED<<< ISAKMP OAK AG (InitCookie
0xf489476e3aa956fc, MsgID: 0x0) (SA, KE, NON, ID, VID, VID, VID, VID,
VID, VID, VID, VID, VID, VID, VID) 10.10.10.10, 500 192.168.15.2, 500

03/07/2012 17:40:57.160 SENDING>>>> ISAKMP OAK INFO (InitCookie
0xf489476e3aa956fc, MsgID: 0x0) (NOTIFY:INVALID_ID_INFO) 192.168.15.2,
500 10.10.10.10, 500

03/07/2012 17:40:57.160 IKE Responder: Received Aggressive Mode request
(Phase 1) 10.10.10.10 192.168.15.2

03/07/2012 17:40:57.160 RECEIVED<<< ISAKMP OAK AG (InitCookie
0xf489476e3aa956fc, MsgID: 0x0) (SA, KE, NON, ID, VID, VID, VID, VID,
VID, VID, VID, VID, VID, VID, VID) 10.10.10.10, 500 192.168.15.2, 500


Leider ist das Log des Clients nicht wirklich aussagekräftig - und die
"Trace" Applikation tut nicht das, was ich von ihr erwarte ;-)

ciao

dirk

[Burkhard Ott]

On Wed, 07 Mar 2012 17:52:16 +0100, Dirk Wagner wrote:

> Burkhard Ott <news...@derith.de> wrote:
>
>> On Wed, 07 Mar 2012 17:25:24 +0100, Dirk Wagner wrote:
>>
>> > Burkhard Ott <news...@derith.de> wrote:
>> >
>> >> Benutzt Du aggressive oder main mode?
>> >
>> > aggressive...
>> >
>> > Ich habe versucht, die auf einem XP-Rechner funktionierende
>> > Konfiguration des SonicWall Clients auf den Shrewsoft zu
>> > übertragen...
>>
>> Ich hatte, allerdings vor Jahren Openswan unter linux laufen,
>> Zieldevice war eine 5600 oder sowas. Generell ist Sonicwall etwas
>> 'crappy' aber IPSec sollte schon funktionieren.
>
>> So wie es aussieht schlaegt in Phase 1 die Authentifizierung fehl,
>> check das Du auf beiden Seiten mode und die Proposals (Verschlusselungs
>> und Integritaets alg) gleich ist.
>
> Sind gleich...
>
>> Was sagt die sonicwall im Log?
>
> 03/07/2012 17:41:07.160 SENDING>>>> ISAKMP OAK INFO (InitCookie
> 0xf489476e3aa956fc, MsgID: 0x0) (NOTIFY:INVALID_ID_INFO) 192.168.15.2,
> 500 10.10.10.10, 500

Kannst Du den ID type in der sonicwall setzten, glaube mich erinnern zu
koennen das man das machen konnte. Checke das Du die gleichen IKE
protokoll versionen aktiviert hast (IKE vs. IKEv2), da hat man bei
Sonicwall unterschiedl. Auffassungen das umzusetzten :).

> Leider ist das Log des Clients nicht wirklich aussagekräftig - und die
> "Trace" Applikation tut nicht das, was ich von ihr erwarte ;-)

no worries, das ist ein Markenzeichen von Sonicwall, zunaechst muss Du
heraus finden wer 'auflegt', vermutlich die Sonicwall da Deine ID
unbekannt ist. Je nach config koennen das aber auch doe Clients, z.Bsp.
wenn Du x509 Certificates einsetzt.

cheers

[Dirk Wagner]

Burkhard Ott <news...@derith.de> wrote:

> Kannst Du den ID type in der sonicwall setzten, glaube mich erinnern zu
> koennen das man das machen konnte.

Habe ich in der VPN-Konfiguration nirgens gefunden.
Ist vielleicht vom Model abhängig.
Der VPN-Client bietet diese Möglichkeit - und dort habe ich "Domain
Name" aktiv.

> Checke das Du die gleichen IKE
> protokoll versionen aktiviert hast (IKE vs. IKEv2), da hat man bei
> Sonicwall unterschiedl. Auffassungen das umzusetzten :).

Da finde ich leider auch keine Infos zu.
Weder in der SonicWall, noch bei den Clients...

> no worries, das ist ein Markenzeichen von Sonicwall, zunaechst muss Du
> heraus finden wer 'auflegt', vermutlich die Sonicwall da Deine ID
> unbekannt ist. Je nach config koennen das aber auch doe Clients, z.Bsp.
> wenn Du x509 Certificates einsetzt.

OK - hier das lokale Log eines erfolgreichen Verbindungsaufbaus (durch
den SonicWall VPN Client):

18:18:39.265
18:18:39.281 VPN - Initiating IKE Phase 1 (IP ADDR=192.168.15.2)
18:18:39.296 VPN - SENDING>>>> ISAKMP OAK AG (SA, KE, NON, ID, VID, VID,
VID, VID)
18:18:39.640 VPN - RECEIVED<<< ISAKMP OAK AG (SA, KE, VID, NAT-D, NAT-D,
NON, ID, VID, VID, VID, HASH)
18:18:39.640 VPN - Peer is NAT-T capable
18:18:39.640 VPN - SENDING>>>> ISAKMP OAK AG *(HASH, NAT-D, NAT-D,
NOTIFY:STATUS_INITIAL_CONTACT)
18:18:39.640 VPN - Established IKE SA
18:18:39.640 MY COOKIE 8b c3 d9 65 9e dc bf 2
18:18:39.640 HIS COOKIE bd fe 20 9c 6f 7d 85 5b
18:18:39.656 VPN - Initiating IKE Phase 2 with Client IDs (message id:
DED14E01)
18:18:39.656 Initiator = IP ADDR=10.10.10.10, prot = 0 port = 0
18:18:39.656 Responder = IP SUBNET/MASK=192.168.168.0/255.255.255.0,
prot = 0 port = 0
18:18:39.656 VPN - SENDING>>>> ISAKMP OAK QM *(HASH, SA, NON, KE, ID,
ID)
18:18:39.984 VPN - RECEIVED<<< ISAKMP OAK QM *(HASH, SA, NON, KE, ID,
ID)
18:18:39.984 VPN - SENDING>>>> ISAKMP OAK QM *(HASH)
18:18:39.984 VPN - Loading IPSec SA (Message ID = DED14E01 OUTBOUND SPI
= C4CD0A6F INBOUND SPI = 29F9E6DF)
18:18:39.984

und hier das eines nicht erfolgreichen Verbindungsaufbau durch den Shrew
Client:

12/03/07 18:09:06 >= : message 00000000
12/03/07 18:09:06 -> : send IKE packet 10.10.10.10:500 ->
192.168.15.2:500 ( 493 bytes )
12/03/07 18:09:06 DB : phase1 resend event scheduled ( ref count = 2 )
12/03/07 18:09:06 <- : recv IKE packet 192.168.15.2:500 ->
10.10.10.10:500 ( 100 bytes )
12/03/07 18:09:06 DB : phase1 found
12/03/07 18:09:06 ii : processing informational packet ( 100 bytes )
12/03/07 18:09:06 =< : cookies eae841fe068afe81:3d4fc79904dfc259
12/03/07 18:09:06 =< : message 00000000
12/03/07 18:09:06 << : notification payload
12/03/07 18:09:06 ii : received peer INVALID-ID-INFORMATION notification
12/03/07 18:09:06 ii : - 192.168.15.2:500 -> 10.10.10.10:500
12/03/07 18:09:06 ii : - isakmp spi = eae841fe068afe81:3d4fc79904dfc259
12/03/07 18:09:06 ii : - data size 44
12/03/07 18:09:11 -> : resend 1 phase1 packet(s) 10.10.10.10:500 ->
192.168.15.2:500
12/03/07 18:09:21 <- : recv IKE packet 192.168.15.2:500 ->
10.10.10.10:500 ( 100 bytes )
12/03/07 18:09:21 DB : phase1 found
12/03/07 18:09:21 ii : processing informational packet ( 100 bytes )
12/03/07 18:09:21 =< : cookies eae841fe068afe81:9f8199188fb6f007
12/03/07 18:09:21 =< : message 00000000
12/03/07 18:09:21 << : notification payload
12/03/07 18:09:21 ii : received peer INVALID-ID-INFORMATION notification
12/03/07 18:09:21 ii : - 192.168.15.2:500 -> 10.10.10.10:500
12/03/07 18:09:21 ii : - isakmp spi = eae841fe068afe81:9f8199188fb6f007
12/03/07 18:09:21 ii : - data size 44
12/03/07 18:09:26 ii : resend limit exceeded for phase1 exchange
12/03/07 18:09:26 ii : phase1 removal before expire time
12/03/07 18:09:26 DB : phase1 deleted ( obj count = 0 )
12/03/07 18:09:26 DB : policy not found
12/03/07 18:09:26 DB : policy not found
12/03/07 18:09:26 DB : policy not found
12/03/07 18:09:26 DB : policy not found
12/03/07 18:09:26 DB : tunnel stats event canceled ( ref count = 1 )
12/03/07 18:09:26 DB : removing tunnel config references
12/03/07 18:09:26 DB : removing tunnel phase2 references
12/03/07 18:09:26 DB : removing tunnel phase1 references
12/03/07 18:09:26 DB : tunnel deleted ( obj count = 0 )
12/03/07 18:09:26 DB : removing all peer tunnel refrences
12/03/07 18:09:26 DB : peer deleted ( obj count = 0 )
12/03/07 18:09:26 ii : ipc client process thread exit ...


Ciao

dirk

[Burkhard Ott]

On Wed, 07 Mar 2012 18:41:29 +0100, Dirk Wagner wrote:

> Burkhard Ott <news...@derith.de> wrote:
>
>> Kannst Du den ID type in der sonicwall setzten, glaube mich erinnern zu
>> koennen das man das machen konnte.
>
> Habe ich in der VPN-Konfiguration nirgens gefunden. Ist vielleicht vom
> Model abhängig.
> Der VPN-Client bietet diese Möglichkeit - und dort habe ich "Domain
> Name" aktiv.

Default is glaube ich IP, wenn Du fqdn nimmst stelle sicher das auf
beiden Seiten der gleiche Eintrag ist.

>> Checke das Du die gleichen IKE
>> protokoll versionen aktiviert hast (IKE vs. IKEv2), da hat man bei
>> Sonicwall unterschiedl. Auffassungen das umzusetzten :).
>
> Da finde ich leider auch keine Infos zu. Weder in der SonicWall, noch
> bei den Clients...

Dann wirds IKEv1 sein, IKEv2 is relativ.

> OK - hier das lokale Log eines erfolgreichen Verbindungsaufbaus (durch
> den SonicWall VPN Client):
>
> 18:18:39.265
> 18:18:39.281 VPN - Initiating IKE Phase 1 (IP ADDR=192.168.15.2)

HA, siehste hier ist die ID die IP adresse. Setze in Deinem Client als ID
adress oder IP address oder falls moeglich lasse es frei, der default ist
IP addresse.

> INVALID-ID-INFORMATION notification 12/03/07 18:09:06 ii : -

> 12/03/07 18:09:21 =< : message 00000000 12/03/07 18:09:21 << :
> notification payload 12/03/07 18:09:21 ii : received peer
> INVALID-ID-INFORMATION notification 12/03/07 18:09:21 ii : -

siehe oben es ist der ID parameter, dieser muss auf beiden Seiten gleich
sein.

cheers

[Dirk Wagner]

Burkhard Ott <news...@derith.de> wrote:

> Default is glaube ich IP, wenn Du fqdn nimmst stelle sicher das auf
> beiden Seiten der gleiche Eintrag ist.

Zwischenzeitlich habe ich noch den (kommerziellen) NCP Secure Entry
Client (30 Tage Testversion) ausprobiert.
Dort bekomme ich bei Verwendung von "Freier String für Gruppen
Identifizierung" - was wohl dem "Key Identifier" im Shrew Client
entspricht - die gleiche Fehlermeldung wie beim Shrew:

INVALID-ID-INFORMATION

Das scheint also die falsche Methode zu sein...

Beim SonicWall Client gibt es "Domain Name" und dort habe ich als Inhalt
die Seriennummer der Sonicwall eingetragen.
Damit funktioniert der Verbindungsaufbau.
Wenn ich im Shrew Client FQDN wähle und die Seriennumer eintrage,
bekomme ich

phase1 sa rejected invalid auth data.

Beim NCP (FQDN) bekomme ich

phase1 ready
und etwas später

No Proposal Chosen

Was die Technote von Sonicwall mit "Phase 2 settings are probably
incorrect on either side" übersetzt...

Allerdings stimmen die Parameter
Agressive Mode
DH Group 2
3DES
SHA1
und 28800 Sekunden LifeTime...

in allen 3 Clients und in der SonicWall überein....

> Dann wirds IKEv1 sein, IKEv2 is relativ.

Der Shrew Client unterscheidet zwischen Main, Agressive und v2.
Also wirst Du recht habe ;-)
Aggressive habe ich auch im SonicWall Client eingestellt

>
> > OK - hier das lokale Log eines erfolgreichen Verbindungsaufbaus (durch
> > den SonicWall VPN Client):
> >
> > 18:18:39.265
> > 18:18:39.281 VPN - Initiating IKE Phase 1 (IP ADDR=192.168.15.2)
>
> HA, siehste hier ist die ID die IP adresse. Setze in Deinem Client als ID
> adress oder IP address oder falls moeglich lasse es frei, der default ist
> IP addresse.

Wenn ich im SonicWall Client die IP Adresse als ID setze, scheitert
Phase 1...
Im Log steht dann immer noch

Initiating IKE Phase 1 (IP ADDR=192.168.15.2)

Wobei 192.168.15.2 die WAN Adresse der Sonicwall ist.
Als IP Adresse ist automatisch die lokale Adresse des Clients
eingetragen.

Ciao

dirk

[Burkhard Ott]

On Wed, 07 Mar 2012 19:50:34 +0100, Dirk Wagner wrote:

> Burkhard Ott <news...@derith.de> wrote:
>
>> Default is glaube ich IP, wenn Du fqdn nimmst stelle sicher das auf
>> beiden Seiten der gleiche Eintrag ist.
>
> Zwischenzeitlich habe ich noch den (kommerziellen) NCP Secure Entry
> Client (30 Tage Testversion) ausprobiert. Dort bekomme ich bei
> Verwendung von "Freier String für Gruppen Identifizierung" - was wohl
> dem "Key Identifier" im Shrew Client entspricht - die gleiche
> Fehlermeldung wie beim Shrew:
>
> INVALID-ID-INFORMATION
>
> Das scheint also die falsche Methode zu sein...

Bei NDp weiss ich das es funktioniert, wir hatten damals allerdings x509
als Authentifizierung.

> Beim SonicWall Client gibt es "Domain Name" und dort habe ich als Inhalt
> die Seriennummer der Sonicwall eingetragen. Damit funktioniert der
> Verbindungsaufbau. Wenn ich im Shrew Client FQDN wähle und die
> Seriennumer eintrage, bekomme ich
>
> phase1 sa rejected invalid auth data.

Die S/N ist kein fqdn, wenn da ein client meckert hat er Recht.
Was passiert wenn Du bei der Sonicwall z.bsp. abc.domain.tld nimmst und
das auch im client verwendest?

> Beim NCP (FQDN) bekomme ich
>
> phase1 ready
> und etwas später
>
> No Proposal Chosen
>
> Was die Technote von Sonicwall mit "Phase 2 settings are probably
> incorrect on either side" übersetzt...

PFS am laufen?

> Allerdings stimmen die Parameter
> Agressive Mode
> DH Group 2
> 3DES
> SHA1
> und 28800 Sekunden LifeTime...

Wenn eine Seite PFS eingestellt hat und die andere nicht waere das ein
Grund warum es fehl schlaegt.

> in allen 3 Clients und in der SonicWall überein....
>
>> Dann wirds IKEv1 sein, IKEv2 is relativ.
>
> Der Shrew Client unterscheidet zwischen Main, Agressive und v2. Also
> wirst Du recht habe ;-)

aggressice sollte ok sein.

> Aggressive habe ich auch im SonicWall Client eingestellt

>> > OK - hier das lokale Log eines erfolgreichen Verbindungsaufbaus
>> > (durch den SonicWall VPN Client):
>> >
>> > 18:18:39.265
>> > 18:18:39.281 VPN - Initiating IKE Phase 1 (IP ADDR=192.168.15.2)
>>
>> HA, siehste hier ist die ID die IP adresse. Setze in Deinem Client als
>> ID adress oder IP address oder falls moeglich lasse es frei, der
>> default ist IP addresse.
>
> Wenn ich im SonicWall Client die IP Adresse als ID setze, scheitert
> Phase 1...
> Im Log steht dann immer noch
> Initiating IKE Phase 1 (IP ADDR=192.168.15.2)

Dann wertet der sonicwall client den Paramter nicht aus, hier wurde als
ID die IP des clients gesendet, dort kann auch ein fqdn oder ein x509
identifier sein. Muss halt nur auf beiden Seiten gleich sein. Wir hatten
nie wirklich den Sonicwall client benutzt, wir hatten die boxen zum
testen da und nach 4 woechigen ausgiebigen test das Product sonicwall,
als in Frage kommende appliance gestrichen. Dafuer gabe es mehrere
Gruende, einer war u.a. die IPSec Implementierung auf der box.

> Wobei 192.168.15.2 die WAN Adresse der Sonicwall ist. Als IP Adresse ist
> automatisch die lokale Adresse des Clients eingetragen.

Hast Du in der sonicwall diese adresse auch stehen?

[Dirk Wagner]

Burkhard Ott <news...@derith.de> wrote:

> > phase1 sa rejected invalid auth data.
>
> Die S/N ist kein fqdn, wenn da ein client meckert hat er Recht.

Nun - meckert der Client oder die Sonicwall? Ich meine letztere...

> Was passiert wenn Du bei der Sonicwall z.bsp. abc.domain.tld nimmst und
> das auch im client verwendest?

Im SonicWall Client funktioniert das.
Bei den anderen beiden nicht...

> PFS am laufen?

Auf der Sonicwall: Ja...

> Wenn eine Seite PFS eingestellt hat und die andere nicht waere das ein
> Grund warum es fehl schlaegt.

OK.

Wenn ich das in der SonicWall ausschalte, kann ich mit dem SonicWall
Client nicht mehr verbinden - der hat keine Einstellung um das
abzuschalten.

Bei den beiden anderen macht es keinen Unterschied, ob PFS auf der
Sonicwall ein- oder ausgeschaltet ist...

> > Wenn ich im SonicWall Client die IP Adresse als ID setze, scheitert
> > Phase 1...
> > Im Log steht dann immer noch
> > Initiating IKE Phase 1 (IP ADDR=192.168.15.2)
>
> Dann wertet der sonicwall client den Paramter nicht aus, hier wurde als
> ID die IP des clients gesendet, dort kann auch ein fqdn oder ein x509
> identifier sein. Muss halt nur auf beiden Seiten gleich sein. Wir hatten
> nie wirklich den Sonicwall client benutzt, wir hatten die boxen zum
> testen da und nach 4 woechigen ausgiebigen test das Product sonicwall,
> als in Frage kommende appliance gestrichen. Dafuer gabe es mehrere
> Gruende, einer war u.a. die IPSec Implementierung auf der box.

;-)

Ich habe das Teil "geerbt"...

>
> > Wobei 192.168.15.2 die WAN Adresse der Sonicwall ist. Als IP Adresse ist
> > automatisch die lokale Adresse des Clients eingetragen.
>
> Hast Du in der sonicwall diese adresse auch stehen?

In der Sonicwall kann man keine IP Adresse als ID eintragen.

ABER:
Ich weiß nicht wieso - die Einstellungen auf der Sonicwall sind immer
noch die gleichen wie vorhin.

Jetzt wird der Tunnel auch mit dem Shrew Client aufgebaut...

Gut - DIE Konfiguration habe ich gleich mal gesichert ;-)

Nun müsste ich nur noch einen Weg finden, damit der Shrew automatisch
eine Windows-VPN Verbindung aufbaut. DANN wäre ich absolut glücklich.

Aber zur Not geht es auch so.

Merci

dirk

[Burkhard Ott]

On Wed, 07 Mar 2012 20:59:20 +0100, Dirk Wagner wrote:
>> Dann wertet der sonicwall client den Paramter nicht aus, hier wurde als
>> ID die IP des clients gesendet, dort kann auch ein fqdn oder ein x509
>> identifier sein. Muss halt nur auf beiden Seiten gleich sein. Wir
>> hatten nie wirklich den Sonicwall client benutzt, wir hatten die boxen
>> zum testen da und nach 4 woechigen ausgiebigen test das Product
>> sonicwall, als in Frage kommende appliance gestrichen. Dafuer gabe es
>> mehrere Gruende, einer war u.a. die IPSec Implementierung auf der box.
>
> ;-)
>
> Ich habe das Teil "geerbt"...

Haha, sieh zu das Du sie los bekommst der Mist macht nur Probleme.
Noch ein unschoenes Feature ist das Du auf den Teilen die deep inspection
nicht abschalten kannst, ja auch wenn Du das in der Konfig machst. Wir
haben das damals gemessen und die Dinger waren fuer 30-40%
Performanceverlust verantwortlich (1GB Leitung). Jage mal ordentlich
Traffic drauf und mach das gleiche mit ner Linuxbox, da stellen Sich Dir
die Haare auf. Wir hatten deren 'System Engineers' fuer 2 Tage bei uns um
eventuelle Erklaerungen fuer die von uns gesammelten Punkte zu bekommen,
leider waren die nicht in der Lage zwischen Layer 4 und 5 zu
unterscheiden und alle Fragen wurden mit 'Das ist wirklich eigenartig'
beantwortet.
Der Support ist noch besser, der hat immer nur 2 Standardantworten,
Sonicwall unterstuetzt dies nicht oder ein solches Scenario ist nicht
vorgesehen. (Ging um OSPF connectivity, es dauerte 2 Tage denen zu
erklaeren das OSPF nichts mit http zu tuen hat).
Naja, ich beneide Dich nicht drumm das Teil administrieren zu muessen, Du
bekommst im gleichen Preissegment besseres.

>
>> > Wobei 192.168.15.2 die WAN Adresse der Sonicwall ist. Als IP Adresse
>> > ist automatisch die lokale Adresse des Clients eingetragen.
>>
>> Hast Du in der sonicwall diese adresse auch stehen?
>
> In der Sonicwall kann man keine IP Adresse als ID eintragen.
>
> ABER:
> Ich weiß nicht wieso - die Einstellungen auf der Sonicwall sind immer
> noch die gleichen wie vorhin.

It's not a bug it's a feature :).

> Jetzt wird der Tunnel auch mit dem Shrew Client aufgebaut...
>
> Gut - DIE Konfiguration habe ich gleich mal gesichert ;-)

Congrats.

> Nun müsste ich nur noch einen Weg finden, damit der Shrew automatisch
> eine Windows-VPN Verbindung aufbaut. DANN wäre ich absolut glücklich.

Ob Shrewsoft heartbeat oder keepalive unterstuetzt weiss ich nicht, ich
denke aber da es ein Client ist wo man induviduell einen Tunnel aufbaut,
also nur mit zu tuen des Users, wirst Du da schlechte Karten haben.

cheers

[mathias.he...@gmail.com]

Hallo,

hat jemand noch eine ShrewSoft Konfig die für den Verbindungsaufbau zu einer Sonicwall geeignet ist ?

Dann brauche ich das Rad nicht neu zu erfinden.

Vielen Dank im Voraus.