VPN-Einwahl eines 1711 über IKE-CFG Client auf einer 7111

[suhlig]

Hi Forum,

normalerweise werde ich durch die Suche schlau, aber hierzu konnte ich leider nichts finden und das Referencehandbuch schweigt auch

Problem:

Ich nutze zur Zeit einen NCP-Client um mich vom Standort A auf einen 7111 in ein anders LAN (Standort B) zu verbinden. Im Standort A ist ein virtueller PC aufgesetzt, über welchen ich, nachdem der Tunnel aufgebaut wurde, per RDP arbeiten kann.

Auf den 7111 habe ich keinen Zugriff! Da müsste ich verschiedene Leute bitten und das kann dauern

Jetzt wollte ich an meinem Standort A einen 1711 installieren und einfach die Konfiguration des NCP-Clients übernehmen um auch von anderen PCs auf dem virtuellen PC zu arbeiten.

Ich habe dazu:

- entsprechende IKE und IPSec Proposal Listen erstellt
- unter Verbindungsliste: IKE-CFG => Client und Regel => Automatisch eingestellt
- ein IP-Routing inkl. Maskierung angelegt
- testweise eine Firewall-Regel installiert, wobei ich nicht weiß, wie diese aussehen muss :


Fehlerausgabe:

[VPN-Status] 2009/12/13 22:06:29,650
VPN: connecting to VPN.STANDORT-B (xx.xx.xx.xx)

[VPN-Status] 2009/12/13 22:06:29,650
VPN: start IKE negotiation for VPN.STANDORT-B (xx.xx.xx.xx)

[VPN-Status] 2009/12/13 22:06:29,690
IKE info: Phase-1 negotiation started for peer VPN.STANDORT-B rule isakmp-peer-VPN.STANDORT-B using AGGRESSIVE mode


[VPN-Status] 2009/12/13 22:06:29,870
IKE info: The remote server xx.xx.xx.xx:500 peer VPN.STANDORT-B id <no_id> is Enigmatec IPSEC version 1.5.1
IKE info: The remote server xx.xx.xx.xx:500 peer VPN.STANDORT-B id <no_id> supports draft-ietf-ipsec-isakmp-xauth
IKE info: The remote server xx.xx.xx.xx:500 peer VPN.STANDORT-B id <no_id> negotiated rfc-3706-dead-peer-detection


[VPN-Status] 2009/12/13 22:06:29,870
IKE info: Phase-1 remote proposal 1 for peer VPN.STANDORT-B matched with local proposal 1


[VPN-Status] 2009/12/13 22:06:30,060
IKE info: Phase-1 [inititiator] for peer VPN.STANDORT-B between initiator id fqdn@vpn, responder id fqdn@vpn done
IKE info: SA ISAKMP for peer VPN.STANDORT-B encryption aes-cbc authentication sha1
IKE info: life time ( 28800 sec/ 0 kb)


[VPN-Status] 2009/12/13 22:06:30,060
IKE info: Phase-1 SA Rekeying Timeout (Soft-Event) for peer VPN.STANDORT-B set to 23040 seconds (Initiator)


[VPN-Status] 2009/12/13 22:06:30,060
IKE info: Phase-1 SA Timeout (Hard-Event) for peer VPN.STANDORT-B set to 28800 seconds (Initiator)


[VPN-Status] 2009/12/13 22:06:30,060
IKE info: IKE-CFG: Creating REQUEST message for peer VPN.STANDORT-B
IKE info: IKE-CFG: Id 45726 added
IKE info: IKE-CFG: Attribute INTERNAL_IP4_ADDRESS len 0 added
IKE info: IKE-CFG: Attribute INTERNAL_IP4_DNS len 0 added
IKE info: IKE-CFG: Attribute INTERNAL_IP4_NBNS len 0 added
IKE info: IKE-CFG: Attribute INTERNAL_IP6_ADDRESS len 0 added
IKE info: IKE-CFG: Attribute INTERNAL_IP6_DNS len 0 added
IKE info: IKE-CFG: Attribute INTERNAL_IP6_NBNS len 0 added


[VPN-Status] 2009/12/13 22:06:30,140
IKE info: NOTIFY received of type ISAKMP_NOTIFY_DPD_R_U_THERE for peer VPN.STANDORT-B Seq-Nr 0xc70b52c, expected 0xc70b52c


[VPN-Status] 2009/12/13 22:06:30,140
IKE info: ISAKMP_NOTIFY_DPD_R_U_THERE_ACK sent for Phase-1 SA to peer VPN.STANDORT-B, sequence nr 0xc70b52c


[VPN-Status] 2009/12/13 22:06:30,150
IKE info: IKE-CFG: Received REPLY message with id 45726 from peer VPN.STANDORT-B
IKE info: IKE-CFG: Attribute INTERNAL_IP4_DNS len 4 value xx.xx.xx.xx received
IKE info: IKE-CFG: Attribute INTERNAL_IP4_ADDRESS len 4 value xx.xx.xx.xx received


[VPN-Status] 2009/12/13 22:06:30,230
IKE info: NOTIFY received of type NO_PROPOSAL_CHOSEN for peer VPN.STANDORT-B


[VPN-Status] 2009/12/13 22:06:30,230
VPN: Error: IPSEC-I-No-proposal-matched (0x3102) for VPN.STANDORT-B (xx.xx.xx.xx)

[VPN-Status] 2009/12/13 22:06:30,250
IKE info: Delete Notification received for Phase-1 SA isakmp-peer-VPN.STANDORT-B peer VPN.STANDORT-B cookies [b5ac3e58140a76d2 2d533f5281338aaf]


[VPN-Status] 2009/12/13 22:06:30,250
IKE info: Phase-1 SA removed: peer VPN.STANDORT-B rule VPN.STANDORT-B removed


[VPN-Status] 2009/12/13 22:06:30,250
VPN: VPN.STANDORT-B (xx.xx.xx.xx) disconnected

[VPN-Status] 2009/12/13 22:06:30,250
VPN: Disconnect info: remote-disconnected (0x4301) for VPN.STANDORT-B (xx.xx.xx.xx)


Wer hat eine Idee? Ich tippe auf die Firewall-Regel, abr wie muss diese aussehen? Wie sehen die Netzbeziehungen im IKE-CFG Client Modus überhaupt aus??

[MadMurdock]

Hallo,
wieviele Netzwerke willst du erreichen? 1 oder mehrere? Was für Verschlüsselungsdaten etc hast du gesagt bekommen?

Gruß

[suhlig]

Hi MadMurdock,

wenn ich die Einwahl per NCP anstarte, bekomme ich eine IP aus einem C-Netz zugewiesen: 192.168.2.x/24, der virtuelle PC steht in einem A-Netz: 10.2.2.x/8 (ist gesubnettet).

=> Für beide Netze hatte ich testweise Routen eingetragen (mit Masq.), ohne Erfolg.
=> Mir ist ist wie gesagt, nicht klar, welche Netzbeziehungen hier gelten.

Die Verschlüsselungsdaten habe ich quasi per "reengineering" aus dem NCP erhalten. Es handelt sich um die Standard Einstellungen, da musste ich also nicht viel schrauben.

Die NCP-Konfig sieht wie folgt aus:

[PROFILE1]
Name=VIRTUELLER_PC
ConnMedia=8
ConnMode=0
PriVoIP=1
Gateway=xx.xx.xx.xx
ExchMode=4
PFS=2
UseComp=1
IkeIdType=3
IkeIdStr=fqdn@vpn
Secret=wowverysecure
UseXAUTH=0
IpAddrAssign=0

Danke!

[backslash]

Hi suhlig,

wichtig ist hier zunächst, welches Netz denn auf der anderen Seite ist. Für dieses Netz mußt du eine Route erstellen und an die VPN-Verbindung binden. Desweiteren muß du an der Route die Maskierung einschalten, da das LANCOM sonst eine Verbindung zwischen seinem Intranet und dem entfernten Netz fordert. Dies wird aber von der Gegenseite abgelehnt, denn sie läßt ja nur eine Verbindung zwischen der zugewiesenen IP-Adresse und ihrem Intranet zu.

Gruß
Backslash

[suhlig]

Hallo Forum,

habe es trotz eurer Tipps nicht hinbekommen. Ich wecke jetzt die Sys-Admins auf der anderen Seite, so dass wir eine echte LAN-to-LAN Kopplung aufziehen können.

Danke!