9
LANCOM VPN Router 1781EF+ mit ShrewSoft und Advanced VPN Client
Hallo,
wir haben seit einiger Zeit einen LANCOM VPN Router 1781EF+ und nutzen hierbei den integrierten IPsec VPN Dienst.
Für bestimmte Mitarbeiter beim Kunden wird die Advanced VPN Client Software eingesetzt. Dieser funktioniert einwandfrei unter Windows.
Nun haben wir allerdings zwei Probleme:
1) Der LANCOM Advanced VPN Client funktioniert nicht richtig unter Mac OS X Maverick 10.9. Die VPN Verbindung wird zwar erstellt, ich kann die Server auf der Gegenstelle auch anpingen und bekomme auch eine Antwort aber DNS funktioniert nicht. Der Mac Rechner ist zwar in einem Firmennetzwerk mit Windows DNS Server, aber nicht als Domänenmitglied. Er bekommt also per DHCP die DNS Server von der Firma zugeteilt. Was muss ich hierbei machen, damit die DNS Lookups auch über VPN geleitet werden und von dort aufgelöst werden?
2) Ich würde auch gerne per ShrewShoft die VPN Verbindung aufbauen. Ich habe eine benutzerdefinierte VPN Verbindung nach Anleitung von ShrewSoft (https://www.shrew.net/support/Howto_Lancom) erstellt sowie den Client auch so konfiguriert, aber die Verbindung bricht nach dem Aufbau wieder ab.
- Das erste Problem war das Phase 1 fehlgeschlagen ist, da kein Hash Algorithmus auf meiner Client Seite gefunden wurde. Also Remote war SHA und Lokal MD5. Ich habe dann in ShrewSoft unter Phase1 Hash Algorithm auf sha1 umgestellt. Dann läuft Phase 1 ohne Probleme und Tunnel wird auch aufgebaut, aber anschließend kommt session terminated by gateway. (Mich wundert es aber, weil ShrewSoft standardmäßig auf auto gestellt ist und er hier doch sha1 nehmen könnte?!)
- Das zweite Problem ist nun die Phase 2. Hier heißt es wohl das kein Proposal Übereinstimmung gefunden wurde. Das wundert mich sehr, ich habe nämlich sogar die Einstellung in ShrewSoft mal so angepasst, das es exakt mit den Einstellungen übereinstimmt - und dennoch das selbe. Hier ist der Trace aus dem LANCOM Router wenn ich die Standardeinstellung im ShrewSoft verwende.
Wie gesagt, stört mich diese Stelle:
Woran liegt das? Ich verstehe zwar was gemeint ist, aber ich kann nicht begreifen, warum er kein kompatibelen Proposal findet. Wie gesagt habe ich auch die Einstellungen manuell konfiguriert, so dass es mit den LANCOM Proposal Einstellung übereinstimmt, aber das hat auch nichts gebracht.
Ich habe die IP Adressen und die Identitäten aus Sicherheit getauscht.
Viele Grüße,
Burak
wir haben seit einiger Zeit einen LANCOM VPN Router 1781EF+ und nutzen hierbei den integrierten IPsec VPN Dienst.
Für bestimmte Mitarbeiter beim Kunden wird die Advanced VPN Client Software eingesetzt. Dieser funktioniert einwandfrei unter Windows.
Nun haben wir allerdings zwei Probleme:
1) Der LANCOM Advanced VPN Client funktioniert nicht richtig unter Mac OS X Maverick 10.9. Die VPN Verbindung wird zwar erstellt, ich kann die Server auf der Gegenstelle auch anpingen und bekomme auch eine Antwort aber DNS funktioniert nicht. Der Mac Rechner ist zwar in einem Firmennetzwerk mit Windows DNS Server, aber nicht als Domänenmitglied. Er bekommt also per DHCP die DNS Server von der Firma zugeteilt. Was muss ich hierbei machen, damit die DNS Lookups auch über VPN geleitet werden und von dort aufgelöst werden?
2) Ich würde auch gerne per ShrewShoft die VPN Verbindung aufbauen. Ich habe eine benutzerdefinierte VPN Verbindung nach Anleitung von ShrewSoft (https://www.shrew.net/support/Howto_Lancom) erstellt sowie den Client auch so konfiguriert, aber die Verbindung bricht nach dem Aufbau wieder ab.
- Das erste Problem war das Phase 1 fehlgeschlagen ist, da kein Hash Algorithmus auf meiner Client Seite gefunden wurde. Also Remote war SHA und Lokal MD5. Ich habe dann in ShrewSoft unter Phase1 Hash Algorithm auf sha1 umgestellt. Dann läuft Phase 1 ohne Probleme und Tunnel wird auch aufgebaut, aber anschließend kommt session terminated by gateway. (Mich wundert es aber, weil ShrewSoft standardmäßig auf auto gestellt ist und er hier doch sha1 nehmen könnte?!)
- Das zweite Problem ist nun die Phase 2. Hier heißt es wohl das kein Proposal Übereinstimmung gefunden wurde. Das wundert mich sehr, ich habe nämlich sogar die Einstellung in ShrewSoft mal so angepasst, das es exakt mit den Einstellungen übereinstimmt - und dennoch das selbe. Hier ist der Trace aus dem LANCOM Router wenn ich die Standardeinstellung im ShrewSoft verwende.
[VPN-Status] 2014/03/04 12:48:27,716 Devicetime: 2014/03/04 12:48:28,439
IKE info: The remote peer def-aggr-peer supports NAT-T in draft mode
IKE info: The remote peer def-aggr-peer supports NAT-T in draft mode
IKE info: The remote peer def-aggr-peer supports NAT-T in RFC mode
IKE info: The remote server 84.169.165.135:500 (UDP) peer def-aggr-peer id <no_id> negotiated rfc-3706-dead-peer-detection
[VPN-Status] 2014/03/04 12:48:27,716 Devicetime: 2014/03/04 12:48:28,439
IKE info: Phase-1 remote proposal 1 for peer def-aggr-peer matched with local proposal 1
[VPN-Status] 2014/03/04 12:48:27,716 Devicetime: 2014/03/04 12:48:28,584
IKE info: Phase-1 [responder] for peer CLIENT_BURAK between initiator id burak@meinemail.de, responder id burak@meinemail.de done
IKE info: initiator cookie: 0xa6f9b62eafe0272e, responder cookie: 0x427892694fadf315
IKE info: NAT-T enabled in mode rfc, we are behind a nat, the remote side is behind a nat
IKE info: SA ISAKMP for peer CLIENT_BURAK encryption aes-cbc authentication SHA1
IKE info: life time ( 86400 sec/ 0 kb)
[VPN-Status] 2014/03/04 12:48:27,716 Devicetime: 2014/03/04 12:48:28,584
IKE info: Phase-1 SA Rekeying Timeout (Soft-Event) for peer CLIENT_BURAK set to 77760 seconds (Responder)
[VPN-Status] 2014/03/04 12:48:27,716 Devicetime: 2014/03/04 12:48:28,584
IKE info: Phase-1 SA Timeout (Hard-Event) for peer CLIENT_BURAK set to 86400 seconds (Responder)
[VPN-Status] 2014/03/04 12:48:27,716 Devicetime: 2014/03/04 12:48:28,586
IKE info: NOTIFY received of type INITIAL_CONTACT for peer CLIENT_BURAK
[VPN-Status] 2014/03/04 12:48:27,716 Devicetime: 2014/03/04 12:48:28,586
IKE info: Phase-1 [responder] got INITIAL-CONTACT from peer CLIENT_BURAK (84.169.165.135)
[VPN-Status] 2014/03/04 12:48:27,716 Devicetime: 2014/03/04 12:48:28,586
IKE info: Phase-1 SA removed: peer CLIENT_BURAK rule CLIENT_BURAK removed
[VPN-Status] 2014/03/04 12:48:27,716 Devicetime: 2014/03/04 12:48:28,589
IKE info: IKE-CFG: Received REQUEST message with id 0 from peer CLIENT_BURAK
IKE info: IKE-CFG: Attribute INTERNAL_IP4_ADDRESS len 0 value (none) received
IKE info: IKE-CFG: Attribute INTERNAL_ADDRESS_EXPIRY len 0 value (none) received
IKE info: IKE-CFG: Attribute INTERNAL_IP4_NETMASK len 0 value (none) received
IKE info: IKE-CFG: Attribute INTERNAL_IP4_DNS len 0 value (none) received
IKE info: IKE-CFG: Attribute INTERNAL_IP4_NBNS len 0 value (none) received
IKE info: IKE-CFG: Attribute INTERNAL_IP4_SUBNET len 0 value (none) received
[VPN-Status] 2014/03/04 12:48:27,716 Devicetime: 2014/03/04 12:48:28,589
VPN: set local server addresses for CLIENT_BURAK (0.0.0.0)
DNS: 192.168.3.1, 192.168.3.254
NBNS: 0.0.0.0, 0.0.0.0
[VPN-Status] 2014/03/04 12:48:27,716 Devicetime: 2014/03/04 12:48:28,589
IKE info: IKE-CFG: Creating REPLY message with id 0 for peer CLIENT_BURAK
IKE info: IKE-CFG: Attribute INTERNAL_IP4_SUBNET len 8 value 0.0.0.0/0.0.0.0 added
IKE info: IKE-CFG: Attribute INTERNAL_IP4_NBNS len 4 value 192.168.3.254 added
IKE info: IKE-CFG: Attribute INTERNAL_IP4_DNS len 4 value 192.168.3.1 added
IKE info: IKE-CFG: Attribute INTERNAL_IP4_NETMASK len 0 skipped
IKE info: IKE-CFG: Attribute INTERNAL_ADDRESS_EXPIRY len 4 value 1200 added
IKE info: IKE-CFG: Attribute INTERNAL_IP4_ADDRESS len 4 value 192.168.3.81 added
IKE info: IKE-CFG: Sending message
[VPN-Status] 2014/03/04 12:48:31,054 Devicetime: 2014/03/04 12:48:31,901
IKE info: Phase-2 failed for peer CLIENT_BURAK: no rule matches the phase-2 ids 192.168.3.81 <-> 0.0.0.0/0.0.0.0
IKE log: 124831.901555 Default message_negotiate_sa: no compatible proposal found
IKE log: 124831.901587 Default dropped message from 84.169.165.135 port 4500 due to notification type NO_PROPOSAL_CHOSEN
[VPN-Status] 2014/03/04 12:48:31,054 Devicetime: 2014/03/04 12:48:31,902
policy manager error indication: CLIENT_BURAK (84.169.165.135), cause: 12801
[VPN-Status] 2014/03/04 12:48:31,054 Devicetime: 2014/03/04 12:48:31,902
VPN: WAN state changed to WanCalled for CLIENT_BURAK (0.0.0.0), called by: 008ffad0
[VPN-Status] 2014/03/04 12:48:31,054 Devicetime: 2014/03/04 12:48:31,902
VPN: Error: IPSEC-R-No-rule-matched-IDs (0x3201) for CLIENT_BURAK (84.169.165.135)
[VPN-Status] 2014/03/04 12:48:31,054 Devicetime: 2014/03/04 12:48:31,902
vpn-maps[15], remote: CLIENT_BURAK, idle, static-name
[VPN-Status] 2014/03/04 12:48:31,054 Devicetime: 2014/03/04 12:48:31,902
selecting next remote gateway using strategy eFirst for CLIENT_BURAK
=> no remote gateway selected
[VPN-Status] 2014/03/04 12:48:31,054 Devicetime: 2014/03/04 12:48:31,902
selecting first remote gateway using strategy eFirst for CLIENT_BURAK
=> no remote gateway selected
[VPN-Status] 2014/03/04 12:48:31,054 Devicetime: 2014/03/04 12:48:31,902
VPN: installing ruleset for CLIENT_BURAK (0.0.0.0)
[VPN-Status] 2014/03/04 12:48:31,054 Devicetime: 2014/03/04 12:48:31,902
VPN: WAN state changed to WanDisconnect for CLIENT_BURAK (0.0.0.0), called by: 008ffad0
[VPN-Status] 2014/03/04 12:48:31,054 Devicetime: 2014/03/04 12:48:31,903
VPN: WAN state changed to WanIdle for CLIENT_BURAK (0.0.0.0), called by: 008ffad0
[VPN-Status] 2014/03/04 12:48:31,054 Devicetime: 2014/03/04 12:48:31,913
IKE info: Delete Notification sent for Phase-1 SA to peer CLIENT_BURAK, cookies [0xa6f9b62eafe0272e 0x427892694fadf315]
[VPN-Status] 2014/03/04 12:48:31,054 Devicetime: 2014/03/04 12:48:31,913
IKE info: Phase-1 SA removed: peer CLIENT_BURAK rule CLIENT_BURAK removed
[VPN-Status] 2014/03/04 12:48:31,054 Devicetime: 2014/03/04 12:48:31,913
VPN: rulesets installed
[VPN-Status] 2014/03/04 12:48:31,054 Devicetime: 2014/03/04 12:48:31,924
VPN: CLIENT_BURAK (0.0.0.0) disconnected
[ICMP] 2014/03/04 12:48:37,559 Devicetime: 2014/03/04 12:48:38,232
ICMP Tx (WAN, T-ONLINE): Dest-IP: 217.83.85.176: Destination unreachable (Port unreachable)
original packet:
DstIP: 192.168.11.57, SrcIP: 217.83.85.176, Len: 633, DSCP/TOS: 0x00
Prot.: UDP (17), DstPort: 500, SrcPort: 10952
[VPN-Status] 2014/03/04 12:48:59,571 Devicetime: 2014/03/04 12:49:00,233
IKE log: 124900.233893 Default message_recv: invalid cookie(s) 1c47de6b2fade5ff 76c5e0253c448c3a
[VPN-Status] 2014/03/04 12:48:59,571 Devicetime: 2014/03/04 12:49:00,233
IKE log: 124900.233946 Default dropped message from 217.83.85.176 port 57690 due to notification type INVALID_COOKIE
[ICMP] 2014/03/04 12:48:59,571 Devicetime: 2014/03/04 12:49:00,234
ICMP Tx (WAN, T-ONLINE): Dest-IP: 217.83.85.176: Destination unreachable (Port unreachable)
original packet:
DstIP: 217.83.85.176, SrcIP: 217.83.85.176, Len: 124, DSCP/TOS: 0x00
Prot.: UDP (17), DstPort: 4500, SrcPort: 57690
[ICMP] 2014/03/04 12:48:59,571 Devicetime: 2014/03/04 12:49:00,263
ICMP Tx (WAN, T-ONLINE): Dest-IP: 217.83.85.176: Destination unreachable (Port unreachable)
original packet:
DstIP: 192.168.11.57, SrcIP: 217.83.85.176, Len: 633, DSCP/TOS: 0x00
Prot.: UDP (17), DstPort: 500, SrcPort: 10952Wie gesagt, stört mich diese Stelle:
[VPN-Status] 2014/03/04 12:48:31,054 Devicetime: 2014/03/04 12:48:31,901
IKE info: Phase-2 failed for peer CLIENT_BURAK: no rule matches the phase-2 ids 192.168.3.81 <-> 0.0.0.0/0.0.0.0
IKE log: 124831.901555 Default message_negotiate_sa: no compatible proposal found
IKE log: 124831.901587 Default dropped message from 84.169.165.135 port 4500 due to notification type NO_PROPOSAL_CHOSENWoran liegt das? Ich verstehe zwar was gemeint ist, aber ich kann nicht begreifen, warum er kein kompatibelen Proposal findet. Wie gesagt habe ich auch die Einstellungen manuell konfiguriert, so dass es mit den LANCOM Proposal Einstellung übereinstimmt, aber das hat auch nichts gebracht.
Ich habe die IP Adressen und die Identitäten aus Sicherheit getauscht.
Viele Grüße,
Burak
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 231608
Url: https://administrator.de/contentid/231608
Printed on: April 19, 2024 at 16:04 o'clock
9 Comments
Latest comment
Was muss ich hierbei machen, damit die DNS Lookups auch über VPN geleitet werden und von dort aufgelöst werden?
Der Mac muss den DNS Server der Firma als DNS im Adapter eingetragen haben. (Systemeinstellungen)Im Mac Terminal sind nslookup und dig hier deine besten Freunde um den DNS Zugriff zu testen.
Was das zweite Thema anbetrifft gibt es einen proposal Mismatch...das ist sicher. Ist nur die Frage WO. Gibst du mal "no rule matches the phase-2 ids" bei Dr. Google ein gibt es zig Postings dazu bei Lancom.
Interessant ist ein Lancom Dokument aus deren Knowledgebase.
https://www2.lancom.de/kb.nsf/1276/BCC99871E4AB7304C1257442003E2F9A?Open ...
Passt da die Erklärung auf dein Verhalten ?
Hallo aqui,
Naja, ich hab ja einen Ethernet Adapter und dieser bekommt per DHCP die Einstellung. Ich kenne mich bei Mac nicht so gut aus, aber meines Wissens löscht er dann die automatisch konfigurierten Einträge. Die VPN Verbindung soll aber nicht durchgehend aktiv sein. Bekomme ich dann nicht Probleme mit den internen Hostnamen wenn der externe DNS Server nicht erreichbar ist?
Im Terminal habe ich nslookup ja verwendet, bekomme aber natürlich dann von dem internen DNS Server eine Antwort das der Hostname nicht gefunden wurde (was ja an sich logisch ist). dig kenne ich nicht, kann ich dann aber auch mal testen.
Naja, ich hab ja einen Ethernet Adapter und dieser bekommt per DHCP die Einstellung. Ich kenne mich bei Mac nicht so gut aus, aber meines Wissens löscht er dann die automatisch konfigurierten Einträge. Die VPN Verbindung soll aber nicht durchgehend aktiv sein. Bekomme ich dann nicht Probleme mit den internen Hostnamen wenn der externe DNS Server nicht erreichbar ist?
Im Terminal habe ich nslookup ja verwendet, bekomme aber natürlich dann von dem internen DNS Server eine Antwort das der Hostname nicht gefunden wurde (was ja an sich logisch ist). dig kenne ich nicht, kann ich dann aber auch mal testen.
Nein nicht unbedingt...In den "weiteren Optionen" kannst du unter DNS einen statischen Server setzen oder hinzufügen oder die Reihenfolge ändern.
http://macs.about.com/od/networking/qt/configure-your-macs-dns.htm
http://macs.about.com/od/networking/qt/configure-your-macs-dns.htm
Moin,
wenn der Lancom-VPN-Client unter Windows funktioniert, sollte das Problem bei den Mac's im OS zu suchen sein. LCOS und release der VPN-Client sind aktuell und für das OS-release lizensiert? Wenn Du die Lancom-clients über den Assi konfigurierts, verhält sich der client wie ein NIC und nutzt nach dem Verbindungsaufbau den DNS-Server des Lancom-Netzes, nach Verbindungsabbau ist der wieder inaktiv und es wird der DNS-Server des anderen Netzes benutzt.
Was sagt der Lancom-Support zu dem MAc-Problem?
LG, Thomas
wenn der Lancom-VPN-Client unter Windows funktioniert, sollte das Problem bei den Mac's im OS zu suchen sein. LCOS und release der VPN-Client sind aktuell und für das OS-release lizensiert? Wenn Du die Lancom-clients über den Assi konfigurierts, verhält sich der client wie ein NIC und nutzt nach dem Verbindungsaufbau den DNS-Server des Lancom-Netzes, nach Verbindungsabbau ist der wieder inaktiv und es wird der DNS-Server des anderen Netzes benutzt.
Was sagt der Lancom-Support zu dem MAc-Problem?
LG, Thomas
Der Client für Mac OS X ist noch nicht aktiviert bzw. lizenziert. Ich wollte es erstmal testen (es gibt ja eine 30-Tage Testversion) und wenn alles klappt, dann Lizenz bestellen und aktivieren.
Ich habe den Client per den Assistent konfiguriert bzw. das VPN Profil am Router über den Setup-Assisent. Am Client dann nur noch importiert. Nach dem Aufbau der VPN Verbindung nutzt er aber anscheinend immer noch den selben DNS Server wie vorher, da ich ja von dem internen Server eine Antwort bekomme. Es wird auch kein "virtueller Netzwerkadapter" erstellt - ist das richtig? Unter Windows wird ja ein NIC erstellt, aber unter Mac nicht?
Ich habe den LANCOM Support angerufen, aber nach 10 Minuten Warteschlange haben die aufgelegt. Ich probiere es demnächst nochmal.
EDIT: Ich probiere die Tage aus was @aqui gepostet hat. Auf der verlinkten Seite steht, dass wenn der erste DNS Server die Adresse nicht findet, die nächsten ausprobiert werden. Das ist ja genau das was ich möchte. Wahrscheinlich hing es wirklich daran, dass er keinen DNS Server von der remote-Seite hatte.
Ich habe den Client per den Assistent konfiguriert bzw. das VPN Profil am Router über den Setup-Assisent. Am Client dann nur noch importiert. Nach dem Aufbau der VPN Verbindung nutzt er aber anscheinend immer noch den selben DNS Server wie vorher, da ich ja von dem internen Server eine Antwort bekomme. Es wird auch kein "virtueller Netzwerkadapter" erstellt - ist das richtig? Unter Windows wird ja ein NIC erstellt, aber unter Mac nicht?
Ich habe den LANCOM Support angerufen, aber nach 10 Minuten Warteschlange haben die aufgelegt. Ich probiere es demnächst nochmal.
EDIT: Ich probiere die Tage aus was @aqui gepostet hat. Auf der verlinkten Seite steht, dass wenn der erste DNS Server die Adresse nicht findet, die nächsten ausprobiert werden. Das ist ja genau das was ich möchte. Wahrscheinlich hing es wirklich daran, dass er keinen DNS Server von der remote-Seite hatte.
Also ich habe mal "no rule matches the phase-2 ids" gegooglet, finde zwar ein paar Postings, aber nichts was mir weiter hilft.
In der Knowledgebase steht auch nichts bzgl. no compatible proposal found.
Sonst noch eine Idee =/?
In der Knowledgebase steht auch nichts bzgl. no compatible proposal found.
Sonst noch eine Idee =/?
Hast du mal die Autokonfig abgeschaltet im Shrew Client sofern der Lancom kein Autoconfig supportet ?
Es gibt eine gute ct Doku die detailliert auf die Shrew Settings bei unterschiedlichen VPN Servern eingeht:
http://www.heise.de/artikel-archiv/ct/2013/05/122_Verschluesseltes-Haen ...
Es gibt eine gute ct Doku die detailliert auf die Shrew Settings bei unterschiedlichen VPN Servern eingeht:
http://www.heise.de/artikel-archiv/ct/2013/05/122_Verschluesseltes-Haen ...
Wegen den Mac:
Das Problem habe ich gelöst! In dem LANCOM VPN Profil musste unter IP Einstellung der DNS Bereich umgeändert werden. Dort stand drin "domain.local" und ich habe daraus "*.domain.local" gemacht. In der Hilfe standen auch Beispiele. Anschließend funktionierte es direkt! Alle Anfragen wie mit *.domain.local matchen, werden dann durch den Tunnel geleitet.
Das eintragen des DNS Servers und der Such-Domäne in den TCP/IP Einstellungen bei den Netzwerkoptionen hat nichts gebracht. Warum auch immer
.
Wegen ShrewSoft schaue ich nochmal die Tage.
Das Problem habe ich gelöst! In dem LANCOM VPN Profil musste unter IP Einstellung der DNS Bereich umgeändert werden. Dort stand drin "domain.local" und ich habe daraus "*.domain.local" gemacht. In der Hilfe standen auch Beispiele. Anschließend funktionierte es direkt! Alle Anfragen wie mit *.domain.local matchen, werden dann durch den Tunnel geleitet.
Das eintragen des DNS Servers und der Such-Domäne in den TCP/IP Einstellungen bei den Netzwerkoptionen hat nichts gebracht. Warum auch immer
.Wegen ShrewSoft schaue ich nochmal die Tage.
Hallo,
ShrewSoft funktioniert jetzt auch. Frag mich NICHT woran es gelegen hat - ich hatte vor 5 Minuten ein Anhaltspunkt, aber ohne das funktioniert es nun auch.
Ich habe alle Einstellungen manuell gesetzt, d.h. für
Phase 1
Exchange Type: aggressive
DH Exchange: group 2 (ist standardmäßig gesetzt)
Ciper Algorithm: aes
Cipher Key Length: 256 bits
Hash Algorithm: sha1
Phase 2:
Transform Algorithm: esp-aes
Transform Key Length: 256 bits
HMAC Algorithm: sha1
PFS Exchange: group 2
Compress Algorithm: disabled
Ich habe zuviel ausprobiert, also bin ich ehrlich gesagt nicht genau sicher ob ich so eine Einstellung schon mal getestet hatte. Was aber auch damit zu tun hatte war
"Obtain Topology Automatically or Tunnel All"
Diese Einstellung musste ich ausschalten und manuell das Netzwerk eintragen. Erst dann ging es. Nachdem ich das Profil am LANCOM Router neu erstellt hatte und dort auch angegeben habe "Zugriff auf alle Netze" (ich nehme an, dass es daran lag) konnte ich diese Einstellung wieder aktivieren.
EDIT: Es liegt wohl wirklich irgendwie an der Firewall. Wenn ich in der Firewall-VPN Regel nur ein bestimmtes Netz als Quell-Objekt angebe (was auch das Hauptnetz ist), dann kommt "no compatible proposal found". Wenn ich aber als Quell-Objekt BELIEBIG angebe ODER am Client sage, dass nur diese bestimmte Netze erreichbar sein sollen, dann funktioniert es einwandfrei. Warum meckert IPsec an solchen Sachen? Ich meine inwiefern hat das mit der Aushandlung zutun?!
Wenigstens weis ich jetzt mit was man sich rumschlagen muss bei IPsec. Da gewinnt OpenVPN bei der Konfiguration eher
.
Danke trotzdem!
Andere Frage noch kurz: Sollte man eine IPsec VPN Verbindung mit PSK überhaupt durchführen? Oder doch auf Zertifikate setzen? Ich kenne mich bisher nur mit OpenVPN aus und hier werden ja SSL Zertifikate genutzt. Ich kann leider nicht beurteilen wie sicher die Verbindung mit PSK ist.
Gruß,
Burak
ShrewSoft funktioniert jetzt auch. Frag mich NICHT woran es gelegen hat - ich hatte vor 5 Minuten ein Anhaltspunkt, aber ohne das funktioniert es nun auch.
Ich habe alle Einstellungen manuell gesetzt, d.h. für
Phase 1
Exchange Type: aggressive
DH Exchange: group 2 (ist standardmäßig gesetzt)
Ciper Algorithm: aes
Cipher Key Length: 256 bits
Hash Algorithm: sha1
Phase 2:
Transform Algorithm: esp-aes
Transform Key Length: 256 bits
HMAC Algorithm: sha1
PFS Exchange: group 2
Compress Algorithm: disabled
Ich habe zuviel ausprobiert, also bin ich ehrlich gesagt nicht genau sicher ob ich so eine Einstellung schon mal getestet hatte. Was aber auch damit zu tun hatte war
"Obtain Topology Automatically or Tunnel All"
Diese Einstellung musste ich ausschalten und manuell das Netzwerk eintragen. Erst dann ging es. Nachdem ich das Profil am LANCOM Router neu erstellt hatte und dort auch angegeben habe "Zugriff auf alle Netze" (ich nehme an, dass es daran lag) konnte ich diese Einstellung wieder aktivieren.
EDIT: Es liegt wohl wirklich irgendwie an der Firewall. Wenn ich in der Firewall-VPN Regel nur ein bestimmtes Netz als Quell-Objekt angebe (was auch das Hauptnetz ist), dann kommt "no compatible proposal found". Wenn ich aber als Quell-Objekt BELIEBIG angebe ODER am Client sage, dass nur diese bestimmte Netze erreichbar sein sollen, dann funktioniert es einwandfrei. Warum meckert IPsec an solchen Sachen? Ich meine inwiefern hat das mit der Aushandlung zutun?!
Wenigstens weis ich jetzt mit was man sich rumschlagen muss bei IPsec. Da gewinnt OpenVPN bei der Konfiguration eher
.Danke trotzdem!
Andere Frage noch kurz: Sollte man eine IPsec VPN Verbindung mit PSK überhaupt durchführen? Oder doch auf Zertifikate setzen? Ich kenne mich bisher nur mit OpenVPN aus und hier werden ja SSL Zertifikate genutzt. Ich kann leider nicht beurteilen wie sicher die Verbindung mit PSK ist.
Gruß,
Burak
