gelöst: VPN Load Balancer

Bernie137 · Beitrag von **Bernie137** » 07 Mai 2014, 14:03

Hallo LANCOMer,

ich möchte im ersten Schritt einen VPN-Tunnel mit Extranet Adressen einrichten, um danach einen PPTP-Tunnel hindurchzulegen und es später mit weiteren IPSec+PPTP Tunneln zu einem Load-Balancing aufzubauen. Sobald ich den funktionierenden IPSec Tunnel auf Extranet Adressen umstelle, kommt der Tunnel nicht mehr zu Stande und ich hoffe, es hat noch jemand einen Tipp für mich. Ich habe schon aufmerksam im Forum hier gelesen, aber bisher hat nichts geholfen. Irgendwas mache ich doch noch falsch, aber ich sehe den Wald vor lauter Bäumen nicht mehr. Muss ich in der Firewall noch was freischalten?

Zentrale:
- Lancom 1781EF, LCOS 8.84
- Netz 10.10.0.0/16
- feste öffentliche IP
- Aufbau der Netzbeziehungen unter VPN -> Allgemein auf "immer alle gemeinsam"

Code: Alles auswählen

Peer              SH-Time       Extranet-Address  Remote-Gw                                                        Rtg-tag  Layer             dynamic     IKE-Exchange     Rule-creation  DPD-Inact-Timeout  IKE-CFG  XAUTH   SSL-Encaps.   OCSP-Check
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
FILIALE           9999          0.0.0.0           xxxxxxxxxx.no-ip.biz                                             0        FILIALE        No          Main-Mode        auto           60                 Off      Off     No            No

IP-Address       IP-Netmask       Rtg-tag  Peer-or-IP        Distance  Masquerade  Active   Comment
------------------------------------------------------------------------------------------------------------------------------------------------------------
10.1.1.0         255.255.255.0    0        FILIALE           0         No          Yes
224.0.0.0        224.0.0.0        0        0.0.0.0           0         No          Yes      block multicasts: 224-255.x.y.z
255.255.255.255  0.0.0.0          0        INTERNET          0         on          Yes

Filiale
- Lancom 1821n, LCOS 8.82
- Netz 10.1.1.0/24
- dynamische IP, mit no-ip.biz aufgelöst
- Aufbau der Netzbeziehungen unter VPN -> Allgemein auf "immer alle gemeinsam"

Code: Alles auswählen

Peer              SH-Time       Extranet-Address  Remote-Gw                                                        Rtg-tag  Layer             dynamic     IKE-Exchange     Rule-creation  DPD-Inact-Timeout  IKE-CFG  XAUTH   SSL-Encaps.   OCSP-Check
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
VPN-ZENTRALE      9999            0.0.0.0         x31.xxx.xxx.xx2                                                   0        VPN-ZENTRALE      No          Main-Mode        auto           60                 Off      Off     No            No


IP-Address       IP-Netmask       Rtg-tag  Peer-or-IP        Distance  Masquerade  Active   Comment
------------------------------------------------------------------------------------------------------------------------------------------------------------
10.10.0.0        255.255.0.0      0        VPN-ZENTRALE      0         No          Yes
224.0.0.0        224.0.0.0        0        0.0.0.0           0         No          Yes
255.255.255.255  0.0.0.0          0        T-CLSURF          0         on          Yes

Zwischen beiden Standorten kann zunächst der IPSec VPN-Tunnel aufgebaut werden und alles funtkioniert reibungslos. Ich verwende Zertifikate für den VPN Tunnel, sowie eine DENY-ALL Strategie in beiden Firewalls.

Nun stelle ich es folgendermaßen um:

Code: Alles auswählen

Peer              SH-Time       Extranet-Address  Remote-Gw                                                        Rtg-tag  Layer             dynamic     IKE-Exchange     Rule-creation  DPD-Inact-Timeout  IKE-CFG  XAUTH   SSL-Encaps.   OCSP-Check
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
FILIALE          9999          192.168.22.1      xxxxxxxxxx.no-ip.biz                                             0        FILIALE        No          Main-Mode        auto           60                 Off      Off     No            No

IP-Address       IP-Netmask       Rtg-tag  Peer-or-IP        Distance  Masquerade  Active   Comment
------------------------------------------------------------------------------------------------------------------------------------------------------------
192.168.76.1     255.255.255.255  0        FILIALE           0         Yes         Yes
224.0.0.0        224.0.0.0        0        0.0.0.0           0         No          Yes      block multicasts: 224-255.x.y.z
255.255.255.255  0.0.0.0          0        INTERNET          0         on          Yes


Peer              SH-Time       Extranet-Address  Remote-Gw                                                        Rtg-tag  Layer             dynamic     IKE-Exchange     Rule-creation  DPD-Inact-Timeout  IKE-CFG  XAUTH   SSL-Encaps.   OCSP-Check
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
VPN-ZENTRALE      9999            192.168.76.1      x31.xxx.xxx.xx2                                                   0        VPN-ZENTRALE      No          Main-Mode        auto           60                 Off      Off     No            No


IP-Address       IP-Netmask       Rtg-tag  Peer-or-IP        Distance  Masquerade  Active   Comment
------------------------------------------------------------------------------------------------------------------------------------------------------------
192.168.22.1     255.255.255.255  0        VPN-ZENTRALE      0         Yes         Yes
224.0.0.0        224.0.0.0        0        0.0.0.0           0         No          Yes
255.255.255.255  0.0.0.0          0        T-CLSURF          0         on          Yes

Es kommt nun nicht mehr der IPSec Tunnel zustande, bzw in der Filiale wird angezeigt verbunden und es geht ein Ping von der CLI an 192.168.22.1. In der Zentrale steht "Zeitüberschreitung während IKE- oder IPSec-Verhandlung (Initiator) [0x1106]" ein Ping von der CLI an 192.168.76.1 funktioniert auch nicht.

Die VPN Rules sehen wie folgt aus:

Code: Alles auswählen

In der Zentrale:

  Connection #1                 192.168.22.1/255.255.255.255:0 <-> 192.168.76.1/255.255.255.255:0 any

    Name:                       FILIALE
    Unique Id:                  ipsec-0-FILIALE-pr0-l0-r0
    Flags:                      main-mode
    Local  Network:             IPV4_ADDR(any:0, 192.168.22.1/255.255.255.255)
    Local  Gateway:             IPV4_ADDR(any:0, x31.xxx.xxx.xx2)
    Remote Gateway:             IPV4_ADDR(any:0, 87.xxx.xxx.xx4)
    Remote Network:             IPV4_ADDR(any:0, 192.168.76.1/255.255.255.255)

In der Filiale:

  Connection #1                 192.168.76.1/255.255.255.255:0 <-> 192.168.22.1/255.255.255.255:0 any

    Name:                       VPN-ZENTRALE
    Unique Id:                  ipsec-0-VPN-ZENTRALE-pr0-l0-r0
    Flags:                      main-mode
    Local  Network:             IPV4_ADDR(any:0, 192.168.76.1/255.255.255.255)
    Local  Gateway:             IPV4_ADDR(any:0, 87.xxx.xxx.xx4)
    Remote Gateway:             IPV4_ADDR(any:0, x31.xxx.xxx.xx2)
    Remote Network:             IPV4_ADDR(any:0, 192.168.22.1/255.255.255.255)

Anbei noch der Trace von der Zentrale:

Code: Alles auswählen

[VPN-Status] 2014/05/07 13:37:34,910  Devicetime: 2014/05/07 13:37:33,610
selecting first remote gateway using strategy eFirst for FILIALE
     => CurrIdx=0, IpStr=>heikobernd.no-ip.biz<, IpAddr=87.170.36.114, IpTtl=60s

[VPN-Status] 2014/05/07 13:37:34,910  Devicetime: 2014/05/07 13:37:33,610
VPN: installing ruleset for FILIALE (87.xxx.xxx.xx4)

[VPN-Status] 2014/05/07 13:37:34,910  Devicetime: 2014/05/07 13:37:33,610
VPN: WAN state changed to WanDisconnect for FILIALE (87.xxx.xxx.xx4), called by: 0091af88

[VPN-Status] 2014/05/07 13:37:34,910  Devicetime: 2014/05/07 13:37:33,611
VPN: WAN state changed to WanIdle for FILIALE (87.xxx.xxx.xx4), called by: 0091af88

[VPN-Status] 2014/05/07 13:37:34,910  Devicetime: 2014/05/07 13:37:33,611
VPN: FILIALE (87.xxx.xxx.xx4)  disconnected

[VPN-Status] 2014/05/07 13:37:36,018  Devicetime: 2014/05/07 13:37:34,610
VPN: WAN state changed to WanCall for FILIALE (87.xxx.xxx.xx4), called by: 0091af88

[VPN-Status] 2014/05/07 13:37:36,018  Devicetime: 2014/05/07 13:37:34,611
VPN: connecting to FILIALE (87.xxx.xxx.xx4)

[VPN-Status] 2014/05/07 13:37:36,018  Devicetime: 2014/05/07 13:37:34,611
vpn-maps[24], remote: FILIALE, nego, dns-name, static-name, connected-by-name

[VPN-Status] 2014/05/07 13:37:36,018  Devicetime: 2014/05/07 13:37:34,611
vpn-maps[24], remote: FILIALE, nego, dns-name, static-name, connected-by-name

[VPN-Status] 2014/05/07 13:37:36,018  Devicetime: 2014/05/07 13:37:34,629
vpn-maps[24], remote: FILIALE, nego, dns-name, static-name, connected-by-name

[VPN-Status] 2014/05/07 13:37:36,018  Devicetime: 2014/05/07 13:37:34,629
VPN: installing ruleset for FILIALE (87.xxx.xxx.xx4)

[VPN-Status] 2014/05/07 13:37:36,018  Devicetime: 2014/05/07 13:37:34,630
IKE info: Phase-1 negotiation started for peer FILIALE rule isakmp-peer-FILIALE using MAIN mode

[VPN-Status] 2014/05/07 13:37:36,018  Devicetime: 2014/05/07 13:37:34,642
VPN: ruleset installed for FILIALE (87.xxx.xxx.xx4)

[VPN-Status] 2014/05/07 13:37:36,018  Devicetime: 2014/05/07 13:37:34,643
VPN: start IKE negotiation for FILIALE (87.xxx.xxx.xx4)

[VPN-Status] 2014/05/07 13:37:36,018  Devicetime: 2014/05/07 13:37:34,643
VPN: WAN state changed to WanProtocol for FILIALE (87.xxx.xxx.xx4), called by: 0091af88

[VPN-Status] 2014/05/07 13:37:36,018  Devicetime: 2014/05/07 13:37:34,708
IKE info: The remote server 87.xxx.xxx.xx4:500 (UDP) peer FILIALE id <no_id> is Enigmatec IPSEC version 1.5.1
IKE info: The remote peer FILIALE supports NAT-T in draft mode
IKE info: The remote peer FILIALE supports NAT-T in draft mode
IKE info: The remote peer FILIALE supports NAT-T in RFC mode
IKE info: The remote server 87.xxx.xxx.xx4:500 (UDP) peer FILIALE id <no_id> negotiated rfc-3706-dead-peer-detection

[VPN-Status] 2014/05/07 13:37:36,018  Devicetime: 2014/05/07 13:37:34,710
IKE info: Phase-1 remote proposal 1 for peer FILIALE matched with local proposal 1

[VPN-Status] 2014/05/07 13:37:36,236  Devicetime: 2014/05/07 13:37:34,725
IKE info: The remote peer FILIALE supports NAT-T in draft mode
IKE info: The remote peer FILIALE supports NAT-T in draft mode
IKE info: The remote peer FILIALE supports NAT-T in RFC mode
IKE info: The remote server 87.xxx.xxx.xx4:500 (UDP) peer FILIALE id <no_id> is Enigmatec IPSEC version 1.5.1
IKE info: The remote server 87.xxx.xxx.xx4:500 (UDP) peer FILIALE id <no_id> negotiated rfc-3706-dead-peer-detection

[VPN-Status] 2014/05/07 13:37:36,236  Devicetime: 2014/05/07 13:37:34,726
IKE info: Phase-1 remote proposal 1 for peer FILIALE matched with local proposal 1

[VPN-Status] 2014/05/07 13:37:36,751  Devicetime: 2014/05/07 13:37:35,235
IKE info: Phase-1 [responder] got INITIAL-CONTACT from peer FILIALE (87.xxx.xxx.xx4)

[VPN-Status] 2014/05/07 13:37:36,969  Devicetime: 2014/05/07 13:37:35,619
IKE info: Phase-1 [responder] for peer FILIALE between initiator id OU=DBJW,CN=FILIALE,O=DBJW, responder id OU=DBJW,CN=VPN-Zentrale,O=DBJW done
IKE info: initiator cookie: 0x95c52222277335a6, responder cookie: 0xc0fffe0d9d8debc2
IKE info: SA ISAKMP for peer FILIALE encryption aes-cbc authentication SHA1
IKE info: life time ( 108000 sec/ 0 kb)

[VPN-Status] 2014/05/07 13:37:36,969  Devicetime: 2014/05/07 13:37:35,621
IKE info: Phase-1 SA Rekeying Timeout (Soft-Event) for peer FILIALE set to 97200 seconds (Responder)

[VPN-Status] 2014/05/07 13:37:36,969  Devicetime: 2014/05/07 13:37:35,623
IKE info: Phase-1 SA Timeout (Hard-Event) for peer FILIALE set to 108000 seconds (Responder)

[VPN-Status] 2014/05/07 13:37:37,469  Devicetime: 2014/05/07 13:37:35,997
IKE info: Phase-1 [inititiator] got INITIAL-CONTACT from peer FILIALE (87.xxx.xxx.xx4)

[VPN-Status] 2014/05/07 13:37:37,469  Devicetime: 2014/05/07 13:37:35,998
IKE info: Phase-1 SA removed: peer FILIALE rule FILIALE removed

[VPN-Status] 2014/05/07 13:37:37,469  Devicetime: 2014/05/07 13:37:36,001
IKE info: Phase-1 [initiator] for peer FILIALE between initiator id OU=DBJW,CN=VPN-Zentrale,O=DBJW, responder id OU=DBJW,CN=FILIALE,O=DBJW done
IKE info: initiator cookie: 0x984e23f3566f5e5a, responder cookie: 0x4a1e1263f8012880
IKE info: SA ISAKMP for peer FILIALE encryption aes-cbc authentication SHA1
IKE info: life time ( 108000 sec/ 0 kb)

[VPN-Status] 2014/05/07 13:37:37,469  Devicetime: 2014/05/07 13:37:36,003
IKE info: Phase-1 SA Rekeying Timeout (Soft-Event) for peer FILIALE set to 86400 seconds (Initiator)

[VPN-Status] 2014/05/07 13:37:37,469  Devicetime: 2014/05/07 13:37:36,004
IKE info: Phase-1 SA Timeout (Hard-Event) for peer FILIALE set to 108000 seconds (Initiator)

[VPN-Status] 2014/05/07 13:37:37,469  Devicetime: 2014/05/07 13:37:36,156
IKE info: Phase-2 SA Rekeying Timeout (Soft-Event) for peer FILIALE set to 23040 seconds (Initiator)

[VPN-Status] 2014/05/07 13:37:37,469  Devicetime: 2014/05/07 13:37:36,157
IKE info: Phase-2 SA Timeout (Hard-Event) for peer FILIALE set to 28800 seconds (Initiator)

[VPN-Status] 2014/05/07 13:37:37,469  Devicetime: 2014/05/07 13:37:36,158
IKE info: Phase-2 [inititiator] done with 2 SAS for peer FILIALE rule ipsec-0-FILIALE-pr0-l0-r0
IKE info: rule:' ipsec 192.168.22.1/255.255.255.255 <-> 192.168.76.1/255.255.255.255 '
IKE info: SA ESP [0x476bfe0c]  alg AES keylength 256 +hmac HMAC_SHA outgoing
IKE info: SA ESP [0x1c133a11]  alg AES keylength 256 +hmac HMAC_SHA incoming
IKE info: life soft( 23040 sec/1600000 kb) hard (28800 sec/2000000 kb)
IKE info: tunnel between src: x31.xxx.xxx.xx2 dst: 87.xxx.xxx.xx4  


[VPN-Status] 2014/05/07 13:38:06,016  Devicetime: 2014/05/07 13:38:04,652
VPN: connection for FILIALE (87.xxx.xxx.xx4) timed out: no response

[VPN-Status] 2014/05/07 13:38:06,016  Devicetime: 2014/05/07 13:38:04,652
VPN: Error: IFC-I-Connection-timeout-IKE-IPSEC (0x1106) for FILIALE (87.xxx.xxx.xx4)

[VPN-Status] 2014/05/07 13:38:06,016  Devicetime: 2014/05/07 13:38:04,652
VPN: disconnecting FILIALE (87.xxx.xxx.xx4)

[VPN-Status] 2014/05/07 13:38:06,016  Devicetime: 2014/05/07 13:38:04,652
VPN: Error: IFC-I-Connection-timeout-IKE-IPSEC (0x1106) for FILIALE (87.xxx.xxx.xx4)

[VPN-Status] 2014/05/07 13:38:06,016  Devicetime: 2014/05/07 13:38:04,667
IKE info: Delete Notification sent for Phase-2 SA ipsec-0-FILIALE-pr0-l0-r0 to peer FILIALE, spi [0x1c133a11]

[VPN-Status] 2014/05/07 13:38:06,016  Devicetime: 2014/05/07 13:38:04,668
IKE info: Phase-2 SA removed: peer FILIALE rule ipsec-0-FILIALE-pr0-l0-r0 removed
IKE info: containing Protocol IPSEC_ESP, with spis [476bfe0c  ] [1c133a11  ]

[VPN-Status] 2014/05/07 13:38:06,016  Devicetime: 2014/05/07 13:38:04,678
IKE info: Delete Notification sent for Phase-1 SA to peer FILIALE, cookies [0x984e23f3566f5e5a 0x4a1e1263f8012880]

[VPN-Status] 2014/05/07 13:38:06,016  Devicetime: 2014/05/07 13:38:04,678
IKE info: Phase-1 SA removed: peer FILIALE rule FILIALE removed

[VPN-Status] 2014/05/07 13:38:06,016  Devicetime: 2014/05/07 13:38:04,702
VPN: FILIALE (87.xxx.xxx.xx4)  disconnected

[VPN-Status] 2014/05/07 13:38:06,016  Devicetime: 2014/05/07 13:38:04,702
vpn-maps[24], remote: FILIALE, idle, dns-name, static-name

[VPN-Status] 2014/05/07 13:38:06,016  Devicetime: 2014/05/07 13:38:04,710
selecting next remote gateway using strategy eFirst for FILIALE
     => no remote gateway selected

vg Bernie

MariusP · Beitrag von **MariusP** » 07 Mai 2014, 14:20

Hi,
Was steht denn im Status-Trace der Filiale?
Gruß

Bernie137 · Beitrag von **Bernie137** » 07 Mai 2014, 14:47

Hallo MariusP,

die Frage ist natürlich berechtigt. Den Trace hatte ich ganz unterschlagen, weil aus meiner Sicht nichts auffälliges zu sehen sei. Aber ich kann mich ja täuschen...

Code: Alles auswählen

[VPN-Status] 2014/05/07 14:37:39,914  Devicetime: 2014/05/07 14:37:39,857
vpn-maps[21], remote: VPN-ZENTRALE, idle, static-name

[VPN-Status] 2014/05/07 14:37:39,914  Devicetime: 2014/05/07 14:37:39,864
selecting first remote gateway using strategy eFirst for VPN-ZENTRALE
     => CurrIdx=0, IpStr=>31.209.117.122<, IpAddr=x31.xxx.xxx.xx2, IpTtl=0s

[VPN-Status] 2014/05/07 14:37:39,914  Devicetime: 2014/05/07 14:37:39,864
VPN: installing ruleset for VPN-ZENTRALE (x31.xxx.xxx.xx2)

[VPN-Status] 2014/05/07 14:37:39,914  Devicetime: 2014/05/07 14:37:39,864
VPN: WAN state changed to WanDisconnect for VPN-ZENTRALE (x31.xxx.xxx.xx2), called by: 003aa5f1

[VPN-Status] 2014/05/07 14:37:39,914  Devicetime: 2014/05/07 14:37:39,871
VPN: WAN state changed to WanIdle for VPN-ZENTRALE (x31.xxx.xxx.xx2), called by: 003aa5f1

[VPN-Status] 2014/05/07 14:37:41,023  Devicetime: 2014/05/07 14:37:40,865
VPN: WAN state changed to WanCall for VPN-ZENTRALE (x31.xxx.xxx.xx2), called by: 003aa5f1

[VPN-Status] 2014/05/07 14:37:41,023  Devicetime: 2014/05/07 14:37:40,865
VPN: connecting to VPN-ZENTRALE (x31.xxx.xxx.xx2)

[VPN-Status] 2014/05/07 14:37:41,023  Devicetime: 2014/05/07 14:37:40,865
vpn-maps[21], remote: VPN-ZENTRALE, nego, static-name, connected-by-name

[VPN-Status] 2014/05/07 14:37:41,023  Devicetime: 2014/05/07 14:37:40,865
vpn-maps[21], remote: VPN-ZENTRALE, nego, static-name, connected-by-name

[VPN-Status] 2014/05/07 14:37:41,023  Devicetime: 2014/05/07 14:37:40,873
vpn-maps[21], remote: VPN-ZENTRALE, nego, static-name, connected-by-name

[VPN-Status] 2014/05/07 14:37:41,023  Devicetime: 2014/05/07 14:37:40,873
VPN: start IKE negotiation for VPN-ZENTRALE (x31.xxx.xxx.xx2)

[VPN-Status] 2014/05/07 14:37:41,023  Devicetime: 2014/05/07 14:37:40,873
VPN: WAN state changed to WanProtocol for VPN-ZENTRALE (x31.xxx.xxx.xx2), called by: 003aa5f1

[VPN-Status] 2014/05/07 14:37:41,023  Devicetime: 2014/05/07 14:37:40,882
IKE info: Phase-1 negotiation started for peer VPN-ZENTRALE rule isakmp-peer-VPN-ZENTRALE using MAIN mode

[VPN-Status] 2014/05/07 14:37:41,023  Devicetime: 2014/05/07 14:37:40,893
IKE info: The remote server x31.xxx.xxx.xx2:500 (UDP) peer VPN-ZENTRALE id <no_id> is Enigmatec IPSEC version 1.5.1
IKE info: The remote peer VPN-ZENTRALE supports NAT-T in draft mode
IKE info: The remote peer VPN-ZENTRALE supports NAT-T in draft mode
IKE info: The remote peer VPN-ZENTRALE supports NAT-T in RFC mode
IKE info: The remote server x31.xxx.xxx.xx2:500 (UDP) peer VPN-ZENTRALE id <no_id> negotiated rfc-3706-dead-peer-detection

[VPN-Status] 2014/05/07 14:37:41,023  Devicetime: 2014/05/07 14:37:40,894
IKE info: Phase-1 remote proposal 1 for peer VPN-ZENTRALE matched with local proposal 1

[VPN-Status] 2014/05/07 14:37:41,023  Devicetime: 2014/05/07 14:37:40,991
IKE info: The remote peer VPN-ZENTRALE supports NAT-T in draft mode
IKE info: The remote peer VPN-ZENTRALE supports NAT-T in draft mode
IKE info: The remote peer VPN-ZENTRALE supports NAT-T in RFC mode
IKE info: The remote server x31.xxx.xxx.xx2:500 (UDP) peer VPN-ZENTRALE id <no_id> is Enigmatec IPSEC version 1.5.1
IKE info: The remote server x31.xxx.xxx.xx2:500 (UDP) peer VPN-ZENTRALE id <no_id> negotiated rfc-3706-dead-peer-detection

[VPN-Status] 2014/05/07 14:37:41,023  Devicetime: 2014/05/07 14:37:40,992
IKE info: Phase-1 remote proposal 1 for peer VPN-ZENTRALE matched with local proposal 1

[VPN-Status] 2014/05/07 14:37:41,773  Devicetime: 2014/05/07 14:37:41,442
IKE info: Phase-1 [responder] got INITIAL-CONTACT from peer VPN-ZENTRALE (x31.xxx.xxx.xx2)

[VPN-Status] 2014/05/07 14:37:41,773  Devicetime: 2014/05/07 14:37:41,671
IKE info: Phase-1 [responder] for peer VPN-ZENTRALE between initiator id OU=DBJW,CN=VPN-Zentrale,O=DBJW, responder id OU=DBJW,CN=FILIALE,O=DBJW done
IKE info: initiator cookie: 0x28d7a1e906931392, responder cookie: 0xdc91a618dda95964
IKE info: SA ISAKMP for peer VPN-ZENTRALE encryption aes-cbc authentication SHA1
IKE info: life time ( 108000 sec/ 0 kb)

[VPN-Status] 2014/05/07 14:37:41,773  Devicetime: 2014/05/07 14:37:41,672
IKE info: Phase-1 SA Rekeying Timeout (Soft-Event) for peer VPN-ZENTRALE set to 97200 seconds (Responder)

[VPN-Status] 2014/05/07 14:37:41,773  Devicetime: 2014/05/07 14:37:41,672
IKE info: Phase-1 SA Timeout (Hard-Event) for peer VPN-ZENTRALE set to 108000 seconds (Responder)

[VPN-Status] 2014/05/07 14:37:42,039  Devicetime: 2014/05/07 14:37:41,825
IKE info: Phase-1 [inititiator] got INITIAL-CONTACT from peer VPN-ZENTRALE (x31.xxx.xxx.xx2)

[VPN-Status] 2014/05/07 14:37:42,039  Devicetime: 2014/05/07 14:37:41,826
IKE info: Phase-1 SA removed: peer VPN-ZENTRALE rule VPN-ZENTRALE removed

[VPN-Status] 2014/05/07 14:37:42,039  Devicetime: 2014/05/07 14:37:41,828
IKE info: Phase-1 [initiator] for peer VPN-ZENTRALE between initiator id OU=DBJW,CN=FILIALE,O=DBJW, responder id OU=DBJW,CN=VPN-Zentrale,O=DBJW done
IKE info: initiator cookie: 0x010d187f78886453, responder cookie: 0x9f960d8283600b0e
IKE info: SA ISAKMP for peer VPN-ZENTRALE encryption aes-cbc authentication SHA1
IKE info: life time ( 108000 sec/ 0 kb)

[VPN-Status] 2014/05/07 14:37:42,039  Devicetime: 2014/05/07 14:37:41,829
IKE info: Phase-1 SA Rekeying Timeout (Soft-Event) for peer VPN-ZENTRALE set to 86400 seconds (Initiator)

[VPN-Status] 2014/05/07 14:37:42,039  Devicetime: 2014/05/07 14:37:41,829
IKE info: Phase-1 SA Timeout (Hard-Event) for peer VPN-ZENTRALE set to 108000 seconds (Initiator)

[VPN-Status] 2014/05/07 14:37:42,039  Devicetime: 2014/05/07 14:37:42,001
IKE info: Phase-2 SA Rekeying Timeout (Soft-Event) for peer VPN-ZENTRALE set to 23040 seconds (Initiator)

[VPN-Status] 2014/05/07 14:37:42,039  Devicetime: 2014/05/07 14:37:42,002
IKE info: Phase-2 SA Timeout (Hard-Event) for peer VPN-ZENTRALE set to 28800 seconds (Initiator)

[VPN-Status] 2014/05/07 14:37:42,039  Devicetime: 2014/05/07 14:37:42,002
IKE info: Phase-2 [inititiator] done with 2 SAS for peer VPN-ZENTRALE rule ipsec-0-VPN-ZENTRALE-pr0-l0-r0
IKE info: rule:' ipsec 192.168.76.1/255.255.255.255 <-> 192.168.22.1/255.255.255.255 '
IKE info: SA ESP [0x59f9a83d]  alg AES keylength 256 +hmac HMAC_SHA outgoing
IKE info: SA ESP [0x0689c1cd]  alg AES keylength 256 +hmac HMAC_SHA incoming
IKE info: life soft( 23040 sec/1600000 kb) hard (28800 sec/2000000 kb)
IKE info: tunnel between src: 87.xxx.xxx.xx4 dst: x31.xxx.xxx.xx2  

[VPN-Status] 2014/05/07 14:37:43,258  Devicetime: 2014/05/07 14:37:43,004
VPN: VPN-ZENTRALE connected

[VPN-Status] 2014/05/07 14:37:43,258  Devicetime: 2014/05/07 14:37:43,004
VPN: WAN state changed to WanConnect for VPN-ZENTRALE (x31.xxx.xxx.xx2), called by: 003aa5f1

[VPN-Status] 2014/05/07 14:37:43,258  Devicetime: 2014/05/07 14:37:43,004
vpn-maps[21], remote: VPN-ZENTRALE, connected, static-name, connected-by-name


[VPN-Status] 2014/05/07 14:38:10,994  Devicetime: 2014/05/07 14:38:10,922
IKE info: Delete Notification received for Phase-2 SA ipsec-0-VPN-ZENTRALE-pr0-l0-r0 peer VPN-ZENTRALE spi [0x59f9a83d]

[VPN-Status] 2014/05/07 14:38:10,994  Devicetime: 2014/05/07 14:38:10,923
IKE info: Phase-2 SA removed: peer VPN-ZENTRALE rule ipsec-0-VPN-ZENTRALE-pr0-l0-r0 removed
IKE info: containing Protocol IPSEC_ESP, with spis [59f9a83d  ] [0689c1cd  ]

[VPN-Status] 2014/05/07 14:38:11,010  Devicetime: 2014/05/07 14:38:10,933
IKE info: Delete Notification received for Phase-1 SA isakmp-peer-VPN-ZENTRALE peer VPN-ZENTRALE cookies [0x010d187f78886453 0x9f960d8283600b0e]

[VPN-Status] 2014/05/07 14:38:11,010  Devicetime: 2014/05/07 14:38:10,933
IKE info: Phase-1 SA removed: peer VPN-ZENTRALE rule VPN-ZENTRALE removed

[VPN-Status] 2014/05/07 14:38:11,010  Devicetime: 2014/05/07 14:37:43,017
VPN: VPN-ZENTRALE (x31.xxx.xxx.xx2)  disconnected

vg Bernie

Bernie137 · Beitrag von **Bernie137** » 09 Mai 2014, 17:59

Hallo,

nach mehreren probieren und testen funktioniert es nun. Nochmal zur Erinnerung:
- Der Tunnel ohne Extranet Adressen funktionierte ohne Probleme
- Mit Extranet Adressen war der Tunnel "scheinbar" einseitig aufgebaut von der Außenstelle zur Zentrale und auch nur in diese Richtung ging ein Ping

Was habe ich gemacht:
- VPN Verbindung in der Außenstelle gelöscht und neu angelegt -> kein Erfolg
- VPN Verbindung in der Zentrale gelöscht und neu angelegt -> Tunnel steht

Jetzt habe ich nur noch ein kleineres Problem:
Wie geht man genau vor, um mehrere IPSec Tunnel zwischen zwei Standorten einzurichten?
Kann ich einfach die bestehende VPN-Verbindung aus VPN -> Allgemein -> VPN-Verbindungsliste kopieren und einen neuen Namen VPN2 geben mit anderer Extranet und anderer Gateway Adresse als VPN1 so dass die ganzen IPSec-Verbindungsparameter komplett identisch sind? Die erste Verbindung habe ich jeweils mit dem Assistenten angelegt. Kann ich so eine Verbindung einfach umbenennen?

Wofür ist der Eintrag bei Kommunikation -> Gegenstellen ISDN -> "Name der VPN-Verbindung" gut?

vg Bernie

Bernie137 · Beitrag von **Bernie137** » 13 Mai 2014, 11:31

Hallo allerseits, hallo backslash,

inzwischen ist mein Testaufbau so weit gediehen, dass ich zwei IPSec VPN-Tunnel mit Extranet Adressen stehen habe. Sehr geholfen haben mir diese beiden Threats, woran ich mich auch gehalten habe, backslash scheint hier der Profi zu sein:
http://www.lancom-forum.de/fragen-zum-t ... dbalancing
http://www.lancom-forum.de/fragen-zum-t ... dbalancing

Nun gibt es ein Problem mit den 2 (oder 4???) PPTP Tunneln. Ich habe hier einerseits noch ein Verständnisproblem und wahrscheinlich deshalb auch ein technisches Problem. Denn diese Tunnel bauen sich mal auf, mal nicht, mal "gefühlt" über kreuz und mal nur einseitig - jedenfalls nicht zufriedenstellend stabil. Mein Verständnisproblem ist, sind das jetzt vier PPTP Tunnel oder zwei? Liegt das Problem darin, dass es auf beiden Seiten gleich heißt "PPTP-1" usw...

Und doch lesen sich alle Anleitungen dazu recht einfach, wie auch diese hier: https://www2.lancom.de/kb.nsf/1275/9F8D ... enDocument

Konfig Filiale, 2 öffentliche IPs

Code: Alles auswählen

VPN-Verbindungen:

Peer              SH-Time       Extranet-Address  Remote-Gw                                                        Rtg-tag ...
---------------------------------------------------------------------------------------------------------------------------------
VPN-1             9999          192.168.76.1      oeffentliche IP von Zentrale   (INTERNET)                        0       
VPN-2             9999          192.168.76.2      oeffentliche IP von Zentrale   (INTERNET-2)                      2       
       

PPTP-Verbindungen:

Peer              IP-Address                                                       Rtg-tag  Port          SH-Time     
----------------------------------------------------------------------------------------------------------------------
PPTP-1            192.168.22.1                                                     0        1723          9999           
PPTP-2            192.168.22.2                                                     0        1723          9999 


PPP-Verbindungen:

Peer              Authent.request             Authent-response            Key       Time  Try   Conf  Fail  Term  Username         Rights
-----------------------------------------------------------------------------------------------------------------------------------------
DEFAULT           CHAP,PAP                    CHAP,PAP                              3     5     10    5     2                      none
PPTP-1            CHAP,PAP                    CHAP,PAP                    *         0     5     10    5     2     PPTP-1           IP
PPTP-2            CHAP,PAP                    CHAP,PAP                    *         0     5     10    5     2     PPTP-2           IP        
       

Load-Balancer:

Peer               Bundle-Peer-1      Bundle-Peer-2      Bundle-Peer-3      Bundle-Peer-4
---------------------------------------------------------------------------------------------
LOADBAL            PPTP-1             PPTP-2


Routing-Tabelle

IP-Address       IP-Netmask       Rtg-tag  Peer-or-IP        Distance  Masquerade  Active   Comment
--------------------------------------------------------------------------------------------------------------------
192.168.22.1     255.255.255.255  0        VPN-1             0         On          Yes
192.168.22.2     255.255.255.255  0        VPN-2             0         On          Yes

10.10.0.0        255.255.0.0      22       PPTP-2            0         No          Yes
10.10.0.0        255.255.0.0      21       PPTP-1            0         No          Yes

10.10.0.0        255.255.0.0      0        LOADBAL           0         No          Yes

255.255.255.255  0.0.0.0          2        INTERNET2         0         On          Yes
255.255.255.255  0.0.0.0          0        INTERNET          0         On          Yes

Konfig Zentrale, eine öffentliche IP

Code: Alles auswählen

VPN-Verbindungen:

Peer              SH-Time       Extranet-Address  Remote-Gw                                                        Rtg-tag ...
---------------------------------------------------------------------------------------------------------------------------------
VPN-1             0             192.168.22.1      oeffentliche IP1 von Filiale   (INTERNET)                        0       
VPN-2             0             192.168.22.2      oeffentliche IP2 von Filiale   (INTERNET)                        0       
       

PPTP-Verbindungen:

Peer              IP-Address                                                       Rtg-tag  Port          SH-Time     
----------------------------------------------------------------------------------------------------------------------
PPTP-1            192.168.76.1                                                     0        1723          9999           
PPTP-2            192.168.76.2                                                     0        1723          9999 


PPP-Verbindungen:

Peer              Authent.request             Authent-response            Key       Time  Try   Conf  Fail  Term  Username         Rights
-----------------------------------------------------------------------------------------------------------------------------------------
DEFAULT           CHAP,PAP                    CHAP,PAP                              3     5     10    5     2                      none
PPTP-1            CHAP,PAP                    CHAP,PAP                    *         0     5     10    5     2     PPTP-1           IP
PPTP-2            CHAP,PAP                    CHAP,PAP                    *         0     5     10    5     2     PPTP-2           IP        
       

Load-Balancer:

Peer               Bundle-Peer-1      Bundle-Peer-2      Bundle-Peer-3      Bundle-Peer-4
---------------------------------------------------------------------------------------------
LOADBAL            PPTP-1             PPTP-2


Routing-Tabelle

IP-Address       IP-Netmask       Rtg-tag  Peer-or-IP        Distance  Masquerade  Active   Comment
--------------------------------------------------------------------------------------------------------------------
192.168.76.1     255.255.255.255  0        VPN-1             0         On          Yes
192.168.76.2     255.255.255.255  0        VPN-2             0         On          Yes

10.1.1.0         255.255.255.0    22       PPTP-2            0         No          Yes
10.1.1.0         255.255.255.0    21       PPTP-1            0         No          Yes

10.1.1.0         255.255.255.0    0        LOADBAL           0         No          Yes

255.255.255.255  0.0.0.0          0        INTERNET          0         On          Yes

Den PPP Trace habe ich auch schon mal auf beiden Seiten angeworfen, aber die Deutung fällt mir schwer. Mal ein Auszug von der Zentrale:

Code: Alles auswählen

[PPP] 2014/05/13 11:22:27,773  Devicetime: 2014/05/13 11:22:25,640
Change phase to ESTABLISH for PPTP-2
Lower-Layer-Up event for LCP
Initializing LCP restart timer to 3000 milliseconds
Waiting up to 3000ms for connection
Starting LCP restart timer with 3000 milliseconds

[PPP] 2014/05/13 11:22:28,194  Devicetime: 2014/05/13 11:22:25,913

Received LCP frame from peer PPTP-2 (channel 0)
Stop waiting for connection
Stopping LCP restart timer
Initializing LCP restart timer to 3000 milliseconds
Generating LCP configure-request for peer PPTP-2
Inserting local MRU 1320
Inserting local authentication protocol CHAP with MD5 encryption
Inserting local magic number 8812fb9b
Sending LCP configure-request with ID 00 and length 19 to peer PPTP-2 (channel 0)
Starting LCP restart timer with 3000 milliseconds
Evaluate configure-request with ID 00 and size 19
Peer MRU 1352 accepted
Peer requests authentication protocol CHAP with MD5 encryption, accepted
Peer magic number 5062cb93 accepted
Positive Configure-Request-Received event for LCP
Sending LCP configure-ack with ID 00 and length 19 to peer PPTP-2 (channel 0)

[PPP] 2014/05/13 11:22:28,194  Devicetime: 2014/05/13 11:22:26,014

Received LCP frame from peer PPTP-2 (channel 0)
Evaluate configure-ack with ID 00 and size 19
Configure-Ack-Received event for LCP
Initializing LCP restart timer to 3000 milliseconds
This-Layer-Up action for LCP
Change phase to AUTHENTICATE for PPTP-2

Sending CHAP-Challenge to peer PPTP-2 (channel 0)
Challenge = 66 88 b8 fc 8c 17 99 51 ca 30 4a c3 00 99 20 cb
Stopping LCP restart timer

[PPP] 2014/05/13 11:22:28,194  Devicetime: 2014/05/13 11:22:26,091

Received CHAP frame from peer PPTP-2 (channel 0)
Got CHAP-Response from peer PPTP-2, length = 16
multiple connection rejected for peer PPTP-2 (channel 0)
Administrative-Close event for LCP
This-Layer-Down action for LCP
Lower-Layer-Down event for IPV6CP
Lower-Layer-Down event for BACP
Lower-Layer-Down event for CCP
Lower-Layer-Down event for IPCP
Lower-Layer-Down event for IPXCP
Initializing LCP restart timer to 3000 milliseconds
Change phase to TERMINATE for PPTP-2
Sending LCP terminate-request with ID 02 and length 4 to peer PPTP-2 (channel 0)
Starting LCP restart timer with 3000 milliseconds

[PPP] 2014/05/13 11:22:28,413  Devicetime: 2014/05/13 11:22:26,165

Received LCP frame from peer PPTP-2 (channel 0)
Terminate-Request-Received event for LCP
Sending LCP terminate-ack with ID 02 and length 4 to peer PPTP-2 (channel 0)
Stopping LCP restart timer
This-Layer-Finish action for LCP
Disconnecting because LCP was finished

[PPP] 2014/05/13 11:22:28,413  Devicetime: 2014/05/13 11:22:26,166
Change phase to DEAD for PPTP-2
Stopping LCP restart timer
Stopping IPCP restart timer
Stopping CCP restart timer
Stopping BACP restart timer
Stopping IPV6CP restart timer

[PPP] 2014/05/13 11:22:28,413  Devicetime: 2014/05/13 11:22:26,167
PPTP call control: DisconnectNotify sent for call id 1618 to 192.168.76.2
PPTP call control: disconnected PPTP-2 (call id 1618)

[PPP] 2014/05/13 11:22:28,413  Devicetime: 2014/05/13 11:22:26,182
PPTP call control: call destroyed for PPTP-2

[PPP] 2014/05/13 11:22:29,630  Devicetime: 2014/05/13 11:22:27,308
PPTP call control: received OutgoingCallRequest from 192.168.76.2 for call id 15075
PPTP call control: set remote window to 32 for PPTP-2
PPTP call control: OutgoingCallReply sent for call id 15613 to 192.168.76.2
PPTP call control: SetLinkInfo sent for call id 15613 to 192.168.76.2 with SendACCM=0x00000000 and ReceiveACCM=0x00000000
PPTP call control: connect indication for PPP sent

[PPP] 2014/05/13 11:22:29,630  Devicetime: 2014/05/13 11:22:27,310
Change phase to ESTABLISH for PPTP-2
Lower-Layer-Up event for LCP
Initializing LCP restart timer to 3000 milliseconds
Waiting up to 3000ms for connection
Starting LCP restart timer with 3000 milliseconds

[PPP] 2014/05/13 11:22:29,848  Devicetime: 2014/05/13 11:22:27,584

Received LCP frame from peer PPTP-2 (channel 0)
Stop waiting for connection
Stopping LCP restart timer
Initializing LCP restart timer to 3000 milliseconds
Generating LCP configure-request for peer PPTP-2
Inserting local MRU 1320
Inserting local authentication protocol CHAP with MD5 encryption
Inserting local magic number 4624669d
Sending LCP configure-request with ID 00 and length 19 to peer PPTP-2 (channel 0)
Starting LCP restart timer with 3000 milliseconds
Evaluate configure-request with ID 00 and size 19
Peer MRU 1352 accepted
Peer requests authentication protocol CHAP with MD5 encryption, accepted
Peer magic number 7e2b8695 accepted
Positive Configure-Request-Received event for LCP
Sending LCP configure-ack with ID 00 and length 19 to peer PPTP-2 (channel 0)

[PPP] 2014/05/13 11:22:29,848  Devicetime: 2014/05/13 11:22:27,684

Received LCP frame from peer PPTP-2 (channel 0)
Evaluate configure-ack with ID 00 and size 19
Configure-Ack-Received event for LCP
Initializing LCP restart timer to 3000 milliseconds
This-Layer-Up action for LCP
Change phase to AUTHENTICATE for PPTP-2

Sending CHAP-Challenge to peer PPTP-2 (channel 0)
Challenge = 71 9a 6c 38 00 5d 67 16 83 ce e6 74 6e 7a 6e ff
Stopping LCP restart timer

[PPP] 2014/05/13 11:22:29,958  Devicetime: 2014/05/13 11:22:27,761

Received CHAP frame from peer PPTP-2 (channel 0)
Got CHAP-Response from peer PPTP-2, length = 16
multiple connection rejected for peer PPTP-2 (channel 0)
Administrative-Close event for LCP
This-Layer-Down action for LCP
Lower-Layer-Down event for IPV6CP
Lower-Layer-Down event for BACP
Lower-Layer-Down event for CCP
Lower-Layer-Down event for IPCP
Lower-Layer-Down event for IPXCP
Initializing LCP restart timer to 3000 milliseconds
Change phase to TERMINATE for PPTP-2
Sending LCP terminate-request with ID 02 and length 4 to peer PPTP-2 (channel 0)
Starting LCP restart timer with 3000 milliseconds

[PPP] 2014/05/13 11:22:29,958  Devicetime: 2014/05/13 11:22:27,841

Received LCP frame from peer PPTP-2 (channel 0)
Terminate-Request-Received event for LCP
Sending LCP terminate-ack with ID 02 and length 4 to peer PPTP-2 (channel 0)
Stopping LCP restart timer
This-Layer-Finish action for LCP
Disconnecting because LCP was finished

[PPP] 2014/05/13 11:22:29,958  Devicetime: 2014/05/13 11:22:27,843
Change phase to DEAD for PPTP-2
Stopping LCP restart timer
Stopping IPCP restart timer
Stopping CCP restart timer
Stopping BACP restart timer
Stopping IPV6CP restart timer

[PPP] 2014/05/13 11:22:29,958  Devicetime: 2014/05/13 11:22:27,844
PPTP call control: DisconnectNotify sent for call id 15613 to 192.168.76.2
PPTP call control: disconnected PPTP-2 (call id 15613)

[PPP] 2014/05/13 11:22:29,958  Devicetime: 2014/05/13 11:22:27,858
PPTP call control: call destroyed for PPTP-2

[PPP] 2014/05/13 11:22:31,284  Devicetime: 2014/05/13 11:22:28,962
PPTP call control: received OutgoingCallRequest from 192.168.76.2 for call id 17649
PPTP call control: set remote window to 32 for PPTP-2
PPTP call control: OutgoingCallReply sent for call id 11410 to 192.168.76.2
PPTP call control: SetLinkInfo sent for call id 11410 to 192.168.76.2 with SendACCM=0x00000000 and ReceiveACCM=0x00000000
PPTP call control: connect indication for PPP sent

[PPP] 2014/05/13 11:22:31,284  Devicetime: 2014/05/13 11:22:28,963
Change phase to ESTABLISH for PPTP-2
Lower-Layer-Up event for LCP
Initializing LCP restart timer to 3000 milliseconds
Waiting up to 3000ms for connection
Starting LCP restart timer with 3000 milliseconds

[PPP] 2014/05/13 11:22:31,487  Devicetime: 2014/05/13 11:22:29,234

Received LCP frame from peer PPTP-2 (channel 0)
Stop waiting for connection
Stopping LCP restart timer
Initializing LCP restart timer to 3000 milliseconds
Generating LCP configure-request for peer PPTP-2
Inserting local MRU 1320
Inserting local authentication protocol CHAP with MD5 encryption
Inserting local magic number 567024bf
Sending LCP configure-request with ID 00 and length 19 to peer PPTP-2 (channel 0)
Starting LCP restart timer with 3000 milliseconds
Evaluate configure-request with ID 00 and size 19
Peer MRU 1352 accepted
Peer requests authentication protocol CHAP with MD5 encryption, accepted
Peer magic number 6dfe3bf7 accepted
Positive Configure-Request-Received event for LCP
Sending LCP configure-ack with ID 00 and length 19 to peer PPTP-2 (channel 0)

[PPP] 2014/05/13 11:22:31,487  Devicetime: 2014/05/13 11:22:29,334

Received LCP frame from peer PPTP-2 (channel 0)
Evaluate configure-ack with ID 00 and size 19
Configure-Ack-Received event for LCP
Initializing LCP restart timer to 3000 milliseconds
This-Layer-Up action for LCP
Change phase to AUTHENTICATE for PPTP-2

Sending CHAP-Challenge to peer PPTP-2 (channel 0)
Challenge = f6 ff 92 11 05 81 2b 1e a3 7c 28 d4 37 57 31 d5
Stopping LCP restart timer

[PPP] 2014/05/13 11:22:31,596  Devicetime: 2014/05/13 11:22:29,410

Received CHAP frame from peer PPTP-2 (channel 0)
Got CHAP-Response from peer PPTP-2, length = 16
multiple connection rejected for peer PPTP-2 (channel 0)
Administrative-Close event for LCP
This-Layer-Down action for LCP
Lower-Layer-Down event for IPV6CP
Lower-Layer-Down event for BACP
Lower-Layer-Down event for CCP
Lower-Layer-Down event for IPCP
Lower-Layer-Down event for IPXCP
Initializing LCP restart timer to 3000 milliseconds
Change phase to TERMINATE for PPTP-2
Sending LCP terminate-request with ID 02 and length 4 to peer PPTP-2 (channel 0)
Starting LCP restart timer with 3000 milliseconds

[PPP] 2014/05/13 11:22:31,596  Devicetime: 2014/05/13 11:22:29,485

Received LCP frame from peer PPTP-2 (channel 0)
Terminate-Request-Received event for LCP
Sending LCP terminate-ack with ID 02 and length 4 to peer PPTP-2 (channel 0)
Stopping LCP restart timer
This-Layer-Finish action for LCP
Disconnecting because LCP was finished

[PPP] 2014/05/13 11:22:31,596  Devicetime: 2014/05/13 11:22:29,486
Change phase to DEAD for PPTP-2
Stopping LCP restart timer
Stopping IPCP restart timer
Stopping CCP restart timer
Stopping BACP restart timer
Stopping IPV6CP restart timer

[PPP] 2014/05/13 11:22:31,596  Devicetime: 2014/05/13 11:22:29,487
PPTP call control: DisconnectNotify sent for call id 11410 to 192.168.76.2
PPTP call control: disconnected PPTP-2 (call id 11410)

[PPP] 2014/05/13 11:22:31,596  Devicetime: 2014/05/13 11:22:29,502
PPTP call control: call destroyed for PPTP-2

[PPP] 2014/05/13 11:22:32,938  Devicetime: 2014/05/13 11:22:30,625
PPTP call control: received OutgoingCallRequest from 192.168.76.2 for call id 30761
PPTP call control: set remote window to 32 for PPTP-2
PPTP call control: OutgoingCallReply sent for call id 1171 to 192.168.76.2
PPTP call control: SetLinkInfo sent for call id 1171 to 192.168.76.2 with SendACCM=0x00000000 and ReceiveACCM=0x00000000
PPTP call control: connect indication for PPP sent

[PPP] 2014/05/13 11:22:32,938  Devicetime: 2014/05/13 11:22:30,626
Change phase to ESTABLISH for PPTP-2
Lower-Layer-Up event for LCP
Initializing LCP restart timer to 3000 milliseconds
Waiting up to 3000ms for connection
Starting LCP restart timer with 3000 milliseconds

[PPP] 2014/05/13 11:22:33,141  Devicetime: 2014/05/13 11:22:30,895

Received LCP frame from peer PPTP-2 (channel 0)
Stop waiting for connection
Stopping LCP restart timer
Initializing LCP restart timer to 3000 milliseconds
Generating LCP configure-request for peer PPTP-2
Inserting local MRU 1320
Inserting local authentication protocol CHAP with MD5 encryption
Inserting local magic number b5527ea5
Sending LCP configure-request with ID 00 and length 19 to peer PPTP-2 (channel 0)
Starting LCP restart timer with 3000 milliseconds
Evaluate configure-request with ID 00 and size 19
Peer MRU 1352 accepted
Peer requests authentication protocol CHAP with MD5 encryption, accepted
Peer magic number 8ed26610 accepted
Positive Configure-Request-Received event for LCP
Sending LCP configure-ack with ID 00 and length 19 to peer PPTP-2 (channel 0)

[PPP] 2014/05/13 11:22:33,141  Devicetime: 2014/05/13 11:22:30,996

Received LCP frame from peer PPTP-2 (channel 0)
Evaluate configure-ack with ID 00 and size 19
Configure-Ack-Received event for LCP
Initializing LCP restart timer to 3000 milliseconds
This-Layer-Up action for LCP
Change phase to AUTHENTICATE for PPTP-2

Sending CHAP-Challenge to peer PPTP-2 (channel 0)
Challenge = 7a 3b 82 fb eb b2 c3 03 2d 21 04 88 99 04 d4 81
Stopping LCP restart timer

[PPP] 2014/05/13 11:22:33,282  Devicetime: 2014/05/13 11:22:31,073

Received CHAP frame from peer PPTP-2 (channel 0)
Got CHAP-Response from peer PPTP-2, length = 16
multiple connection rejected for peer PPTP-2 (channel 0)
Administrative-Close event for LCP
This-Layer-Down action for LCP
Lower-Layer-Down event for IPV6CP
Lower-Layer-Down event for BACP
Lower-Layer-Down event for CCP
Lower-Layer-Down event for IPCP
Lower-Layer-Down event for IPXCP
Initializing LCP restart timer to 3000 milliseconds
Change phase to TERMINATE for PPTP-2
Sending LCP terminate-request with ID 02 and length 4 to peer PPTP-2 (channel 0)
Starting LCP restart timer with 3000 milliseconds

[PPP] 2014/05/13 11:22:33,282  Devicetime: 2014/05/13 11:22:31,156

Received LCP frame from peer PPTP-2 (channel 0)
Terminate-Request-Received event for LCP
Sending LCP terminate-ack with ID 02 and length 4 to peer PPTP-2 (channel 0)
Stopping LCP restart timer
This-Layer-Finish action for LCP
Disconnecting because LCP was finished

[PPP] 2014/05/13 11:22:33,282  Devicetime: 2014/05/13 11:22:31,158
Change phase to DEAD for PPTP-2
Stopping LCP restart timer
Stopping IPCP restart timer
Stopping CCP restart timer
Stopping BACP restart timer
Stopping IPV6CP restart timer

[PPP] 2014/05/13 11:22:33,282  Devicetime: 2014/05/13 11:22:31,159

Received LCP frame from peer PPTP-2 (channel 0)
out of sync -> silently discarding frame

[PPP] 2014/05/13 11:22:33,282  Devicetime: 2014/05/13 11:22:31,159
PPTP call control: DisconnectNotify sent for call id 1171 to 192.168.76.2
PPTP call control: disconnected PPTP-2 (call id 1171)

[PPP] 2014/05/13 11:22:33,282  Devicetime: 2014/05/13 11:22:31,174
PPTP call control: call destroyed for PPTP-2

vg Bernie

Bernie137 · Beitrag von **Bernie137** » 06 Jun 2014, 14:17

Hallo,

ich hatte mich inzwischen an den Support gewandt, weil ich in der Sache nicht weiter gekommen war. Zur Erinnerung, in meinem Testaufbau zwischen 1781EF und 1821n hatte ich mit Routing-Tags bei den Extranet-Routen und PPTP-Gegenstellen gearbeitet und das lief, zwischen den beiden 1781EF nie.

Der Support hatte mir empfohlen:
1. in der PPP-Liste bei "Default", alle Authentifizierungen und das IPv4-Routing einzuschalten -> ohne Erfolg
2. die PPTP-Verbindungen überkreuz zu benennen, d.h. PPTP1-Zentrale mit User PPTP1-Filiale und auf der Gegenseite PPTP1-Filiale mit User PPTP1-Zentrale -> kein Erfolg
3. in den PPTP-Gegenstellen der Zentrale die Extranet-Adresse gegen 0.0.0.0 zu ersetzen, die Routing-Tags wieder zu entfernen und zusätzlich:

Code: Alles auswählen

- Löschen Sie in beiden Routing-Tabellen die Routen auf die PPTP Tunnel.
Der PPTP Load Balancer fängt die Route bereits ab.
Damit sind die einzelnen PPTP Gegenstellen überflüssig.

Gibt es hier ein neues Verhalten? Ich hatte hier gelesen http://www.lancom-forum.de/fragen-zum-t ... dbalancing und diesen Rat befolgt:

backslash hat geschrieben:du mußt die beiden Routen zu den explizin PPTP-Verbindungfen drin lassen, weil der Lo9adbalancer sonst anfängt die zweite PPTP-Verbindung zu maskieren - wenn du glück hast treffen dabei zwei unmaskieret und zwei naskierte PPTP-Verbindungen aufeinander, so daß wenigstens jede zweite TCP-Session durchkommt - wenn du pech hast trifft immer eine unmaskierete auf eine maskierte und es funktioniert gar nichts mehr...

Jedenfalls läuft es -mit und ohne diese Routen. Ich prüfe noch, ob die Routing-Tags das Problem verursachten, oder in den PPTP-Gegenstellen der Zentrale die Extranet-Adressen der Außenstelle. Vermutlich war letzeres das Problem, weil immer beide Seiten "angerufen" haben.

vg Bernie

Bernie137 · Beitrag von **Bernie137** » 25 Jul 2014, 07:36

Guten Morgen,

auch wenn es schon ein paar Tage her ist, möchte ich ein paar Erkenntnisse nachreichen:

Problem war ja, dass die beiden PPTP Verbindungen nie korrekt zu Stande kamen. Einzig und allein hatte geholfen, auf einer der beiden Seiten in der Tabelle Kommunikation -> Gegenstellen -> PPTP-Liste die IP Adressen für die Gegenstelle auf 0.0.0.0 zu setzen. Somit kann immer nur eine definierte Seite anrufen und die Seite mit 0.0.0.0 hält die Klappe und funkt nicht dazwischen.

Weiterhin heißt es vom Support, dass diese Anleitung https://www2.lancom.de/kb.nsf/1275/9F8D ... enDocument nicht mehr auf der Höhe der Zeit ist. Dort wird beim Schritt 20 im letzten Bild gezeigt, dass pro PPTP-Gegenstelle ein Routing Eintrag mit einem TAG zu setzen ist. Seit LCOS 7.80 soll es wohl so sein, dass der Load Balancer dies anders verdaut und diese Einträge nciht mehr notwendig sind, gar stören könnten. Es wurde nur ein Routing Eintrag empfohlen, eben der der auf den Load Balancer zeigt ohne Tag.

Als Best Practice wurde die Konfiguration der PPTP-Gegenstellen mit Routing Tags benannt:
- in der Tabelle Kommunikation -> Gegenstellen -> PPTP-Liste pro PPTP Eintrag ein eigenes Routing Tag verwenden
- in IP-Router -> IPv4-Routing-Tabelle dann für jede Extranet Route das entsprechende PPTP Tag zu Grunde legen

Der Load Balancer läuft seitdem sehr gut, mit zwei Macken die der Support mir bisher nicht beantworten konnte:
1. Beim zurückschreiben von banalen Konfig Änderungen mit LANconfig (z.B. admin-Kennwort ändern, oder Aktions-Tabelle anpassen) werden ein oder beide PPTP Verbindungen aufgetrennt.
2. Manchmal macht "intruder detection - Paket verworfen" Stress. Im Router der Zentrale werden die Datenpaket von der Filiale einfach verworfen. Besonders nach dem Rückschreiben von Konfigs (wie 1.) oder wenn ein Bündel mal providerseitig haspelte kommt es aus dem Tritt. Siehe http://www.lancom-forum.de/post73329.html#p73329

vg Bernie

blackeagle2002de · Beitrag von **blackeagle2002de** » 25 Jul 2014, 10:01

Moin Moin,

meine Erfahrungen mit dem Lancom Support waren bei diesem Thema eher gemischt, zumindest bei den Mitarbeitern, die mich in dieser Sache betreut hatten. Da ich letztes Jahr ähnliche Probleme hatte wie Du beim Aufbau des VPN Loadbalancers, habe ich durch Trial and Error genau die von Dir aufgezeigte Lösung gefunden. Entweder wird auf einer Seite bei den PPTP Gegenstellen als Adresse 0.0.0.0 eingetragen, oder auf beiden Seiten bekommen die PPTP-Gegenstellen das jeweilige Routing-Tag der Extranet-VPN Adresse zugeordnet. Beide Varianten funktionieren bei mir.

Bislang konnte ich darüber hinaus aber auf die zusätzlichen Routen zur Demaskierung (die nach Deiner Aussage ja jetzt überflüssig sein sollen) in folgendem Scenario nicht verzichten:

Zentrale ist mit Außenstelle A über ein normales VPN verbunden, mit Außenstelle B über Loadbalancer PPTP Extranet-VPN. Wenn nun jemand von der Außenstelle A über die Zentrale nach B kommen will funktioniert das bei uns nur zuverlässig, wenn für alle Routen zusätzliche Demaskierungsrouten eingetragen werden. D. h. ich muss bei Außenstelle B einmal die Demaskierungsrouten zur Zentrale eintragen, aber zusätzlich auch für die Route zu Außenstelle A. Dies soll zwar falsch sein, ist aber der einzige Weg, wie es bei uns funktioniert.

Ich habe mich aufgrund der Problematik, die in diesem Thread diskutiert wurde (http://www.lancom-forum.de/aktuelle-lan ... 13254.html), ebenfalls mit dem Lancom Support in Verbindung gesetzt. Die Lösung, die Du jetzt als Best Practice bezeichnest wurde vom Lancom Support bei mir noch vor zwei Monaten als falsch bezeichnet, die höchstwahrscheinlich für das beschriebene Fehlverhalten in o. g. Thread verantwortlich sei. Ich habe daraufhin dem Support erklärt, dass es mit den Einstellungen aus der Anleitung bei mir nicht funktioniert und ich deshalb die gewünschten Änderungen nicht vornehmen kann...Naja vielleicht hat meine Anfrage dann wenigstens dazu geführt, dass der Support sich mal wieder genauer mit der Thematik beschäftigt hat. Leider scheint es immer noch keine Lösung zu geben, wenn man in diesem Scenario mehr als zwei mit einem Routing Tag eingerichtete WAN-Verbindungen nutzen will. Auch dieser Fehler hatte stundenlange Trial and Error Sucherei zur Folge gehabt, bei dem ich vom Support die Antwort bekommen habe, dass es an den hier als Best Practice bezeichneten Einstellungen liegen würde.

Grüße
blackeagle2002de

Bernie137 · Beitrag von **Bernie137** » 06 Aug 2014, 15:19

Hallo blackeagle2002de,

vielen Dank für Deine Antwort. Ich habe mir bewusst Zeit gelassen, da ich inzwischen weitere Erkenntnisse gewonnen haben.

Weiterhin heißt es vom Support, dass diese Anleitung https://www2.lancom.de/kb.nsf/1275/9F8D ... enDocument nicht mehr auf der Höhe der Zeit ist. Dort wird beim Schritt 20 im letzten Bild gezeigt, dass pro PPTP-Gegenstelle ein Routing Eintrag mit einem TAG zu setzen ist. Seit LCOS 7.80 soll es wohl so sein, dass der Load Balancer dies anders verdaut und diese Einträge nciht mehr notwendig sind, gar stören könnten. Es wurde nur ein Routing Eintrag empfohlen, eben der der auf den Load Balancer zeigt ohne Tag.

Im Forum hier ist ja bislang auch empfohlen, diese Routen zu setzen. Wahrscheinlich ist es ein Sonderfall, wenn man 2 PPTP Verbindungen hat, dass es ohne diese Routen geht.

Ich habe den Load-Balancer um einen 3. Anschluss und damit einer Dritten PPTP Verbindung erweitert. Man regelrecht darauf warten, bis sofort die Firewall mit Intruder Detection anspringt. Einzig und allein Abhilfe schafft nur das Setzen dieser einzelnen PPTP Routen. Seitdem sind beide Problem nicht mehr aufgetreten:

Der Load Balancer läuft seitdem sehr gut, mit zwei Macken die der Support mir bisher nicht beantworten konnte:
1. Beim zurückschreiben von banalen Konfig Änderungen mit LANconfig (z.B. admin-Kennwort ändern, oder Aktions-Tabelle anpassen) werden ein oder beide PPTP Verbindungen aufgetrennt.
2. Manchmal macht "intruder detection - Paket verworfen" Stress. Im Router der Zentrale werden die Datenpaket von der Filiale einfach verworfen. Besonders nach dem Rückschreiben von Konfigs (wie 1.) oder wenn ein Bündel mal providerseitig haspelte kommt es aus dem Tritt.

meine Erfahrungen mit dem Lancom Support waren bei diesem Thema eher gemischt, zumindest bei den Mitarbeitern, die mich in dieser Sache betreut hatten.

Die Ansicht muss ich inzwischen teilen. Ich hatte am 14.07. dem Support mit Traces geantwortet. Am 04.08. bekomme ich von einem anderen Kollegen eine Mail, dass der ursprüngliche Bearbeiter nicht da ist und wie wir weiter klären könnten. Nun hab ich gestern Morgen mit meinen Erkenntnissen und Traces geantwortet und wieder schweigen im Walde. Das Support Ticket läuft seit dem 02.06.

Dabei habe ich den LOAD-Balancer inzwischen mit 3 PPTP Verbindungen am Laufen ohne Intruder Detection, aber eine neue Problematik festgestellt und da hätte ich gerne mal eine Rückmeldung von den Leuten, die auch einen VPN Load-Balancer einsetzen.

Ich schau mir in der Zentrale und in der Filiale über WEBconfig die Tabelle Status -> IP-Router -> LOAD-Balancer -> Verbindungen an und stelle immer fest, auf der einen (anrufenden) PPTP-Seite sind es drei Verbindungen, auf der anderen (angerufenen) PPTP-Seite sind es zwei Verbindungen. Die Anrufrichtung der zugrundeliegenden IPSec VPN sind egal. Im LANmonitor werden auf beiden Seiten 3 PPTP-Verbindungen angezeigt? Das ist doch so nicht in Ordnung?

Ein Trace Load-Balancer verrät mir auch auf der Seite mit dem fehlenden Tunnel, dass wirklich nur zwei Verbindungen da sind. Das Problem wandert auf die entgegengesetzte Seite, wenn ich die PPTP Verbindungen mit Ziel 0.0.0.0 vs 192.168.xxx.xxx in beiden Routern vertausche. Nun verstehe ich auch, wieso es zu den Firewall Ereignissen Intruder Detection kam, es fehlt einfach ein PPTP Tunnel im Load-Balancer auf einer (der angerufenen) Seite.

Ist das ein Problem, weil es drei PPTP-Verbindungen sind? Ist diese Anzahl unüblich? Wie ist das bei Euch?

Vielen Dank für Infos.

vg Bernie

blackeagle2002de · Beitrag von **blackeagle2002de** » 16 Aug 2014, 16:11

Hallo Bernie,

mir ist das Verhalten noch nicht aufgefallen, aber es tritt bei uns auch auf. Sind vier PPTP Verbindungen eingerichtet werden nur drei genutzt bzw. bei drei eingerichteten nur zwei! Also gleiches Verhalten wie bei Dir. Werde mir das noch mal genauer anschauen.

Viele Grüße
Blackeagle

Bernie137 · Beitrag von **Bernie137** » 18 Aug 2014, 15:31

Hallo Blackeagle,

danke für die Rückmeldung. Da ich eben in letzter Zeit mit dieser Sache etwas Probleme hatte, konnte ich nicht einschätzen, ob es nur bei mir so ist. Ich muss sagen, satbil läuft es jetzt mit den einzelnen PPTP-Routen. Daher kann man die eigentlichen Probleme von oben als gelöst jetzt ansehen. Nur bin ich beim Troubleshooting über die Tabelle Status -> IP-Router -> LOAD-Balancer -> Verbindungen gestolpert und wundere mich.

Schau Dir doch bitte mal den Trace +Load-Balancer an. Ich sehe dort auffällig, dass auf der Seite mit der "Fehlenden" PPTP-Verbindung diese auch nie in dem besagten Trace auftaucht. Ich deute das so, dass die zur Verfügung stehenden Bündel damit nicht optimal ausgeschöpft werden. Bzw. man sich überlegen sollte, wie herum "angerufen" wird. Ich entdecke auch keinen Unterschied zwischen LCOS 884 und 9.

Ist das nun ein BUG oder Feature?

vg Bernie

blackeagle2002de · Beitrag von **blackeagle2002de** » 19 Aug 2014, 14:48

Hallo Bernie,

gleiches Bild einem Trace auch bei uns, die "fehlende" PPTP Verbindung tauch im Trace nicht auf. Da sonst keine Daten über unsere Leitungen fließen, kann man es auch im LANMonitor erkennen. Der Anschluss über die die "fehlende" PPTP Verbindung läuft zeigt im LANMonitor so gut wie keinen Datenfluss.

Grüße
blackeagle2002de

Bernie137 · Beitrag von **Bernie137** » 19 Aug 2014, 16:02

Hallo Blackeagle2002de,

danke Dir für die Rückmeldung. Meldest Du das jetzt als Bug?

Ich habe letzten Montag vom Support diese Antwort erhalten:
"wir empfehlen, dass die Einwahl der PPTP-Verbindung, sowie der IPsec-VPN-Verbindung, von einer Router-Seite durchgeführt wird.
Sie können alle aktiven Gegenstellenverbindungen mit dem Befehl "ls /st/wan/mtu" einsehen und den korrekten Zustand der PPTP-Verbindung einsehen."

Habe darauf geantwortet, dass dort zwar auf beiden Seiten alle PPTPs drin sind, aber unter "ls /st/ip-r/load/con" trotzdem immer auf der Gegenseite der abgehenden PPTPs eine PPTP fehlt, egal wie herum angewählt ist.

vg Bernie

blackeagle2002de · Beitrag von **blackeagle2002de** » 22 Aug 2014, 14:14

Hi Bernie,

ich gehe jetzt erst einmal in Urlaub und werde mich danach wieder mit der Sache beschäftigen. Nach der bisherigen Erfahrung denke ich aber, dass es schwierig wird das Problem mit dem Support zu lösen. Mein Eindruck ist, dass dies auch für Lancom noch eine Sonderlösung darstellt, die nicht allzu häufig Anwendung findet.

Viele Grüße
blackeagle2002de

Bernie137 · Beitrag von **Bernie137** » 15 Dez 2014, 20:48

Hallo Miteinander,

für allen Interessierten: Ich habe vor 2 Wochen eine Rückmeldung vom Lancom Support erhalten. Es wurde das Problem der PPTP Tunnel in einem VPN Loadbalancer Szenario in einem bevorstehenden Release behoben. Ich hatte dann darum gebeten, mir eine E-Mail Benachitigung zu schicken, wenn das Release veröffentlicht ist.

Heute habe ich die Mail erhalten, dass nun mit 9.04RU2 oder 9.00RU6 das Problem gefixt wurde. Getestet habe ich es allerdings noch nicht.

vg Bernie

LANCOM-Forum.de

gelöst: VPN Load Balancer

gelöst: VPN Load Balancer

Re: VPN Tunnel auf Extranet umstellen, Tunnel geht nicht meh

Re: VPN Tunnel auf Extranet umstellen, Tunnel geht nicht meh

Re: VPN Tunnel auf Extranet umstellen, Tunnel geht nicht meh

Re: VPN Tunnel auf Extranet umstellen, Tunnel geht nicht meh

Re: VPN Tunnel auf Extranet umstellen, Tunnel geht nicht meh

Re: VPN Tunnel auf Extranet umstellen, Tunnel geht nicht meh

Re: gelöst: VPN Load Balancer

Re: gelöst: VPN Load Balancer

Re: wieder offen: VPN Load Balancer

Re: wieder offen: VPN Load Balancer

Re: gelöst: VPN Load Balancer

Re: gelöst: VPN Load Balancer

Re: gelöst: VPN Load Balancer

Re: gelöst: VPN Load Balancer