Tunnel steht, aber kein Datentranfer

squize · Beitrag von **squize** » 06 Mär 2006, 13:04

Hallo Leute, mein Problem besteht leider immernoch, ich habe jetzt mal einen neuen Post aufgemacht, da die alte Überschrift wohl nicht wirklich passt:

Infos:

Standort 1: Karlsruhe
Lancom 1711 VPN Version 6.02
Intranet: 192.168.0.0/255.255.255.0
Wan: KabelBW mit DHCP und dyndns.org

Standort 2: Danzig
Lancom 1711 VPN Version 6.02
Intranet: 192.168.1.0/255.255.255.0
Wan: DSL mit fester IP >83.18.157.130

Aufbau des VPN auf beiden Seiten mit dem Setupassistenten:
1. Beide Seiten fest oder auflösbare IP
2. Agressive Mode
3. PSK

Schicke ich ein Ping baut sich der Tunnel auf, es gehen auch Pakete über die Leitung nur kommen sie nicht an.
Ich habe mal einen Ausschnitt aus einen Aufbau mitgeschnitten ( trace + vpn-status):

root@PDTEC-KARLSRUHE:/
>
[VPN-Status] 1900/01/01 02:42:56,470
VPN: connecting to PDTEC-DANZIG (83.18.157.130)

[VPN-Status] 1900/01/01 02:42:56,470
VPN: start dynamic VPN negotiation for PDTEC-DANZIG (83.18.157.130) via ICMP/UDP

[VPN-Status] 1900/01/01 02:42:56,470
VPN: create dynamic VPN V2 authentication packet for PDTEC-DANZIG (83.18.157.130
)
DNS: 192.168.0.1, 0.0.0.0
NBNS: 192.168.0.1, 0.0.0.0
polling address: 192.168.0.1

[VPN-Status] 1900/01/01 02:42:56,470
VPN: installing ruleset for PDTEC-DANZIG (83.18.157.130)

[VPN-Status] 1900/01/01 02:42:56,500
VPN: ruleset installed for PDTEC-DANZIG (83.18.157.130)

[VPN-Status] 1900/01/01 02:42:56,500
VPN: start IKE negotiation for PDTEC-DANZIG (83.18.157.130)

[VPN-Status] 1900/01/01 02:42:56,510
VPN: rulesets installed

[VPN-Status] 1900/01/01 02:42:56,520
IKE info: Phase-1 negotiation started for peer PDTEC-DANZIG rule isakmp-peer-PDT
EC-DANZIG using AGGRESSIVE mode

[VPN-Status] 1900/01/01 02:42:56,770
VPN: received dynamic VPN V2 authentication packet from PDTEC-DANZIG (83.18.157.
130)
DNS: 192.168.1.1, 0.0.0.0
NBNS: 192.168.1.1, 0.0.0.0
polling address: 192.168.1.1

[VPN-Status] 1900/01/01 02:42:56,960
IKE info: The remote server 83.18.157.130:500 peer PDTEC-DANZIG id <no_id> is En
igmatec IPSEC version 1.5.1
IKE info: The remote server 83.18.157.130:500 peer PDTEC-DANZIG id <no_id> negotiated rfc-3706-dead-peer-detection

[VPN-Status] 1900/01/01 02:42:56,960
IKE info: Phase-1 remote proposal 1 for peer PDTEC-DANZIG matched with local pro
posal 1

[VPN-Status] 1900/01/01 02:42:57,120
IKE info: Phase-1 [inititiator] for peer PDTEC-DANZIG between initiator id 82.2
12.61.88, responder id 83.18.157.130 done
IKE info: SA ISAKMP for peer PDTEC-DANZIG encryption aes-cbc authentication md5
IKE info: life time ( 108000 sec/ 0 kb)

[VPN-Status] 1900/01/01 02:42:57,550
IKE info: Phase-2 [inititiator] done with 2 SAS for peer PDTEC-DANZIG rule ipsec
-0-PDTEC-DANZIG-pr0-l0-r0
IKE info: rule:' ipsec 192.168.0.0/255.255.255.0 <-> 192.168.1.0/255.255.255.0 '
IKE info: SA ESP [0x2ed96efa] alg AES keylength 128 +hmac HMAC_MD5 outgoing
IKE info: SA ESP [0x397adde0] alg AES keylength 128 +hmac HMAC_MD5 incoming
IKE info: life soft( 1800 sec/180000 kb) hard (2000 sec/200000 kb)
IKE info: tunnel between src: 82.212.61.88 dst: 83.18.157.130

[VPN-Status] 1900/01/01 02:42:58,570
VPN: PDTEC-DANZIG (83.18.157.130) connected, set poll timer to 30 sec

[VPN-Status] 1900/01/01 02:43:28,570
VPN: poll timeout for PDTEC-DANZIG (83.18.157.130)
send poll frame to 192.168.1.1

[VPN-Status] 1900/01/01 02:43:56,670
IKE info: NOTIFY received of type ISAKMP_NOTIFY_DPD_R_U_THERE for peer PDTEC-DAN
ZIG Seq-Nr 0x37c2b701, expected 0x37c2b701

[VPN-Status] 1900/01/01 02:43:56,670
IKE info: ISAKMP_NOTIFY_DPD_R_U_THERE_ACK sent for Phase-1 SA to peer PDTEC-DANZ
IG, sequence nr 0x37c2b701

[VPN-Status] 1900/01/01 02:43:58,570
VPN: poll timeout for PDTEC-DANZIG (83.18.157.130)
remote site did not answer during interval
setting poll time to 1 sec.
(5 retries left)
send poll frame to 192.168.1.1

[VPN-Status] 1900/01/01 02:43:59,570
VPN: poll timeout for PDTEC-DANZIG (83.18.157.130)
remote site did not answer during interval
(4 retries left)
send poll frame to 192.168.1.1

[VPN-Status] 1900/01/01 02:44:00,570
VPN: poll timeout for PDTEC-DANZIG (83.18.157.130)
remote site did not answer during interval
(3 retries left)
send poll frame to 192.168.1.1

[VPN-Status] 1900/01/01 02:44:01,570
VPN: poll timeout for PDTEC-DANZIG (83.18.157.130)
remote site did not answer during interval
(2 retries left)
send poll frame to 192.168.1.1

[VPN-Status] 1900/01/01 02:44:02,570
VPN: poll timeout for PDTEC-DANZIG (83.18.157.130)
remote site did not answer during interval
(1 retries left)
send poll frame to 192.168.1.1

[VPN-Status] 1900/01/01 02:44:03,570
VPN: poll timeout for PDTEC-DANZIG (83.18.157.130)
remote site did not answer during interval
no retries left, disconnect channel

[VPN-Status] 1900/01/01 02:44:03,580
VPN: Error: IFC-X-Line-polling-failed (0x1307) for PDTEC-DANZIG (83.18.157.130)

[VPN-Status] 1900/01/01 02:44:03,580
VPN: disconnecting PDTEC-DANZIG (83.18.157.130)

[VPN-Status] 1900/01/01 02:44:03,590
IKE info: Delete Notificaton sent for Phase-2 SA ipsec-0-PDTEC-DANZIG-pr0-l0-r0
to peer PDTEC-DANZIG, spi [0x397adde0]

[VPN-Status] 1900/01/01 02:44:03,590
IKE info: Phase-2 SA removed: peer PDTEC-DANZIG rule ipsec-0-PDTEC-DANZIG-pr0-l0
-r0 removed
IKE info: containing Protocol IPSEC_ESP, with spis [2ed96efa ] [397adde0 ]

[VPN-Status] 1900/01/01 02:44:03,600
IKE info: Delete Notificaton sent for Phase-1 SA to peer PDTEC-DANZIG

[VPN-Status] 1900/01/01 02:44:03,600
IKE info: Phase-1 SA removed: peer PDTEC-DANZIG rule PDTEC-DANZIG removed

[VPN-Status] 1900/01/01 02:44:03,620
IKE info: Phase-1 negotiation started for peer PDTEC-DANZIG rule isakmp-peer-PDT
EC-DANZIG using AGGRESSIVE mode

[VPN-Status] 1900/01/01 02:44:03,650
VPN: selecting next remote gateway using strategy eFirst for PDTEC-DANZIG
=> no remote gateway selected

[VPN-Status] 1900/01/01 02:44:03,650
VPN: selecting first remote gateway using strategy eFirst for PDTEC-DANZIG
=> CurrIdx=0, IpStr=>83.18.157.130<, IpAddr=83.18.157.130, IpTtl=0s

[VPN-Status] 1900/01/01 02:44:03,650
VPN: installing ruleset for PDTEC-DANZIG (83.18.157.130)

[VPN-Status] 1900/01/01 02:44:03,650
VPN: PDTEC-DANZIG (83.18.157.130) disconnected

[VPN-Status] 1900/01/01 02:44:03,670
VPN: rulesets installed

[VPN-Status] 1900/01/01 02:44:03,720
IKE log: 024403 Default message_recv: invalid cookie(s) 8034e3bc1a997984 7d445ac
7ce9a6690

[VPN-Status] 1900/01/01 02:44:03,720
IKE log: 024403 Default dropped message from 83.18.157.130 port 500 due to notif
ication type INVALID_COOKIE

[VPN-Status] 1900/01/01 02:44:03,720
IKE info: dropped message from peer unknown 83.18.157.130 port 500 due to notifi
cation type INVALID_COOKIE

[VPN-Status] 1900/01/01 02:44:03,720
IKE log: 024403 Default message_recv: invalid cookie(s) 8034e3bc1a997984 7d445ac
7ce9a6690

[VPN-Status] 1900/01/01 02:44:03,730
IKE log: 024403 Default dropped message from 83.18.157.130 port 500 due to notif
ication type INVALID_COOKIE

[VPN-Status] 1900/01/01 02:44:03,730
IKE info: dropped message from peer unknown 83.18.157.130 port 500 due to notifi
cation type INVALID_COOKIE

[VPN-Status] 1900/01/01 02:44:04,060
IKE info: The remote server 83.18.157.130:500 peer PDTEC-DANZIG id <no_id> is Enigmatec IPSEC version 1.5.1
IKE info: The remote server 83.18.157.130:500 peer PDTEC-DANZIG id <no_id> negotiated rfc-3706-dead-peer-detection

[VPN-Status] 1900/01/01 02:44:04,060
IKE info: Phase-1 remote proposal 1 for peer PDTEC-DANZIG matched with local pro
posal 1

[VPN-Status] 1900/01/01 02:44:04,220
IKE info: Phase-1 [inititiator] for peer PDTEC-DANZIG between initiator id 82.2
12.61.88, responder id 83.18.157.130 done
IKE info: SA ISAKMP for peer PDTEC-DANZIG encryption aes-cbc authentication md5
IKE info: life time ( 108000 sec/ 0 kb)

[VPN-Status] 1900/01/01 02:44:04,650
IKE info: Phase-2 [inititiator] done with 2 SAS for peer PDTEC-DANZIG rule ipsec
-0-PDTEC-DANZIG-pr0-l0-r0
IKE info: rule:' ipsec 192.168.0.0/255.255.255.0 <-> 192.168.1.0/255.255.255.0 '
IKE info: SA ESP [0x3523f4df] alg AES keylength 128 +hmac HMAC_MD5 outgoing
IKE info: SA ESP [0x3eb1a829] alg AES keylength 128 +hmac HMAC_MD5 incoming
IKE info: life soft( 1800 sec/180000 kb) hard (2000 sec/200000 kb)
IKE info: tunnel between src: 82.212.61.88 dst: 83.18.157.130

[VPN-Status] 1900/01/01 02:44:04,650
VPN: wait for IKE negotiation from PDTEC-DANZIG (83.18.157.130)

[VPN-Status] 1900/01/01 02:44:05,680
VPN: PDTEC-DANZIG (83.18.157.130) connected, set poll timer to 30 sec

Anbei ein Traffic Mitschnitt ( trace + vpn-packet):

[VPN-Packet] 1900/01/01 04:03:29,560
encrypted: 82.212.61.88->83.18.157.130 168 ESP SPI[01c67d61]

[VPN-Packet] 1900/01/01 04:03:29,660
for send: 192.168.0.1->192.168.1.1 96 UDP port 137->137

[VPN-Packet] 1900/01/01 04:03:29,660
encap: 192.168.0.1->192.168.1.1 96 UDP port 137->137

[VPN-Packet] 1900/01/01 04:03:29,660
encrypted: 82.212.61.88->83.18.157.130 168 ESP SPI[01c67d61]

[VPN-Packet] 1900/01/01 04:03:29,760
for send: 192.168.0.1->192.168.1.1 96 UDP port 137->137

[VPN-Packet] 1900/01/01 04:03:29,760
encap: 192.168.0.1->192.168.1.1 96 UDP port 137->137

Hat jemand eine Idee, warum auf beiden Seiten die Pakete einfach im Nirvana verschwinden?
Firewall trace zeigt keine Blockierten Packete.
Ich bin am verzweifeln, da ich keinerlei Ansatzpunkt finde, woran es scheitert.

Gruss
Marc

squize · Beitrag von **squize** » 07 Mär 2006, 16:04

So und wieder ein bissen weiter getestet und mein einziges Resumee ist eigentlich, dass ich immer mehr bedauere die Kisten gekauft zu haben

.

Folgendermassen sieht es jetzt aus. Der Tunnel wird ohne Probleme aufgebaut.
Dann habe ich folgendes getestet

1. von Router Karlsruhe ( Lan192.168.0.1/Wan: pdtec.dynalias.com) in der Console ein ping auf Router Danzig (Lan192.168.1.1/Wan: 83.18.157.130) mit einen "trace + vpn-packet.

root@PDTEC-KARLSRUHE:/
> ping 192.168.1.1
---192.168.1.1 ping statistic---
56 Bytes Data, 20 Packets transmitted, 0 Packets received, 100% loss

*********************************************************

root@PDTEC-DANZIG:/
> trace # vpn-packet
VPN-Packet ON

root@PDTEC-DANZIG:/
>

Das gleiche in die andere Richtung

root@PDTEC-DANZIG:/
> ping 192.168.0.1
---192.168.0.1 ping statistic---
56 Bytes Data, 4 Packets transmitted, 0 Packets received, 100% loss

root@PDTEC-DANZIG:/
>

***********************************************************

root@PDTEC-KARLSRUHE:/
> trace # vpn-packet
VPN-Packet ON

root@PDTEC-KARLSRUHE:/
>
[VPN-Packet] 2006/03/07 15:18:22,550
received: 83.18.157.130->82.212.61.88 152 ESP SPI[6a2b9ab8]

[VPN-Packet] 2006/03/07 15:18:22,550
decrypted: 83.18.157.130->82.212.61.88 128 IP-ENCAP

[VPN-Packet] 2006/03/07 15:18:22,550
decap: 192.168.1.1->192.168.0.1 84 ICMP ECHOREQUEST

[VPN-Packet] 2006/03/07 15:18:22,550
for send: 192.168.0.1->192.168.1.1 84 ICMP ECHOREPLY

[VPN-Packet] 2006/03/07 15:18:22,550
encap: 192.168.0.1->192.168.1.1 84 ICMP ECHOREPLY

[VPN-Packet] 2006/03/07 15:18:22,550
encrypted: 82.212.61.88->83.18.157.130 152 ESP SPI[2a6f57c9]

[VPN-Packet] 2006/03/07 15:18:23,540
received: 83.18.157.130->82.212.61.88 152 ESP SPI[6a2b9ab8]

[VPN-Packet] 2006/03/07 15:18:23,540
decrypted: 83.18.157.130->82.212.61.88 128 IP-ENCAP

[VPN-Packet] 2006/03/07 15:18:23,540
decap: 192.168.1.1->192.168.0.1 84 ICMP ECHOREQUEST

[VPN-Packet] 2006/03/07 15:18:23,540
for send: 192.168.0.1->192.168.1.1 84 ICMP ECHOREPLY

[VPN-Packet] 2006/03/07 15:18:23,540
encap: 192.168.0.1->192.168.1.1 84 ICMP ECHOREPLY

[VPN-Packet] 2006/03/07 15:18:23,540
encrypted: 82.212.61.88->83.18.157.130 152 ESP SPI[2a6f57c9]

[VPN-Packet] 2006/03/07 15:18:24,540
received: 83.18.157.130->82.212.61.88 152 ESP SPI[6a2b9ab8]

[VPN-Packet] 2006/03/07 15:18:24,540
decrypted: 83.18.157.130->82.212.61.88 128 IP-ENCAP

[VPN-Packet] 2006/03/07 15:18:24,540
decap: 192.168.1.1->192.168.0.1 84 ICMP ECHOREQUEST

[VPN-Packet] 2006/03/07 15:18:24,540
for send: 192.168.0.1->192.168.1.1 84 ICMP ECHOREPLY

[VPN-Packet] 2006/03/07 15:18:24,540
encap: 192.168.0.1->192.168.1.1 84 ICMP ECHOREPLY

[VPN-Packet] 2006/03/07 15:18:24,540
encrypted: 82.212.61.88->83.18.157.130 152 ESP SPI[2a6f57c9]

[VPN-Packet] 2006/03/07 15:18:25,540
received: 83.18.157.130->82.212.61.88 152 ESP SPI[6a2b9ab8]

[VPN-Packet] 2006/03/07 15:18:25,540
decrypted: 83.18.157.130->82.212.61.88 128 IP-ENCAP

[VPN-Packet] 2006/03/07 15:18:25,540
decap: 192.168.1.1->192.168.0.1 84 ICMP ECHOREQUEST

[VPN-Packet] 2006/03/07 15:18:25,540
for send: 192.168.0.1->192.168.1.1 84 ICMP ECHOREPLY

[VPN-Packet] 2006/03/07 15:18:25,540
encap: 192.168.0.1->192.168.1.1 84 ICMP ECHOREPLY

[VPN-Packet] 2006/03/07 15:18:25,540
encrypted: 82.212.61.88->83.18.157.130 152 ESP SPI[2a6f57c9]

[VPN-Packet] 2006/03/07 15:18:26,540
received: 83.18.157.130->82.212.61.88 152 ESP SPI[6a2b9ab8]

[VPN-Packet] 2006/03/07 15:18:26,540
decrypted: 83.18.157.130->82.212.61.88 128 IP-ENCAP

[VPN-Packet] 2006/03/07 15:18:26,540
decap: 192.168.1.1->192.168.0.1 84 ICMP ECHOREQUEST

[VPN-Packet] 2006/03/07 15:18:26,540
for send: 192.168.0.1->192.168.1.1 84 ICMP ECHOREPLY

[VPN-Packet] 2006/03/07 15:18:26,540
encap: 192.168.0.1->192.168.1.1 84 ICMP ECHOREPLY

[VPN-Packet] 2006/03/07 15:18:26,540
encrypted: 82.212.61.88->83.18.157.130 152 ESP SPI[2a6f57c9]

[VPN-Packet] 2006/03/07 15:18:27,540
received: 83.18.157.130->82.212.61.88 152 ESP SPI[6a2b9ab8]

[VPN-Packet] 2006/03/07 15:18:27,540
decrypted: 83.18.157.130->82.212.61.88 128 IP-ENCAP

[VPN-Packet] 2006/03/07 15:18:27,540
decap: 192.168.1.1->192.168.0.1 84 ICMP ECHOREQUEST

[VPN-Packet] 2006/03/07 15:18:27,540
for send: 192.168.0.1->192.168.1.1 84 ICMP ECHOREPLY

[VPN-Packet] 2006/03/07 15:18:27,540
encap: 192.168.0.1->192.168.1.1 84 ICMP ECHOREPLY

[VPN-Packet] 2006/03/07 15:18:27,540
encrypted: 82.212.61.88->83.18.157.130 152 ESP SPI[2a6f57c9]

Resultat, der Router in Danzig erhällt keine Packete vom Router in Karlsruhe. Jetzt stellt sich natürlich die Frage warum. Hier mal dieRoutingeinträge auf den Kisten:

Danzig:
Bild

Karlsruhe:
Bild

Die einzige Idee, die ichhabe liegt an der Konfiguration der DSLschnittstelle in Danzig.

Bild

Kann es sein, dass die Netzwerkmaske Probleme bereitet?

Ertaunlicherweise kommen Pakete aus dem Danziger netz raus

[VPN-Packet] 2006/03/07 15:54:10,440
for send: 192.168.1.84->192.168.0.20 106 UDP port 1030->161

[VPN-Packet] 2006/03/07 15:54:10,440
encap: 192.168.1.84->192.168.0.20 106 UDP port 1030->161

[VPN-Packet] 2006/03/07 15:54:10,440
encrypted: 83.18.157.130->82.212.61.88 168 ESP SPI[7cc5f6df]

[VPN-Packet] 2006/03/07 15:54:16,440
for send: 192.168.1.84->192.168.0.20 106 UDP port 1030->161

[VPN-Packet] 2006/03/07 15:54:16,440
encap: 192.168.1.84->192.168.0.20 106 UDP port 1030->161

[VPN-Packet] 2006/03/07 15:54:16,440
encrypted: 83.18.157.130->82.212.61.88 168 ESP SPI[7cc5f6df]

***************************************************************
[VPN-Packet] 2006/03/07 15:54:10,950
encap: 192.168.0.20->192.168.1.84 109 UDP port 161->1030

[VPN-Packet] 2006/03/07 15:54:10,950
encrypted: 82.212.61.88->83.18.157.130 168 ESP SPI[4ecc96f0]

[VPN-Packet] 2006/03/07 15:54:16,960
received: 83.18.157.130->82.212.61.88 168 ESP SPI[7cc5f6df]

[VPN-Packet] 2006/03/07 15:54:16,960
decrypted: 83.18.157.130->82.212.61.88 150 IP-ENCAP

[VPN-Packet] 2006/03/07 15:54:16,960
decap: 192.168.1.84->192.168.0.20 106 UDP port 1030->161

[VPN-Packet] 2006/03/07 15:54:16,960
for send: 192.168.0.20->192.168.1.84 109 UDP port 161->1030

[VPN-Packet] 2006/03/07 15:54:16,960
encap: 192.168.0.20->192.168.1.84 109 UDP port 161->1030

Hat denn wirklich keiner auch nur einen kleinen Tipp für mich. Es wird wahrscheinlich an mir liegen, aber ich habe keine ahnung warum, zumal alle anderen mit Unix aufgesetzten VPNs, sei es über OpenVPN oder mit IPSEC/Racoon ohne Probleme laufen oder mit zu Beginn zumindest einen brauchbaren Log geboten haben, warum es nicht ging.

Gruss

Marc

eddia · Beitrag von **eddia** » 07 Mär 2006, 18:46

Hallo Marc,

Hat denn wirklich keiner auch nur einen kleinen Tipp für mich.

hmm - eigentlich nicht. Aber ich erinnere mich noch an ein Problem aus früheren Zeiten, wo der Lancom irgendwie nicht mit gleichen Netzen aber unterschiedlichen Netzmasken klar kam. Das sollte eigentlich nicht mehr bestehen - aber deaktiviere doch mal sicherheitshalber die Sperrrouten in beiden Lancoms.

Gruß

Mario

squize · Beitrag von **squize** » 09 Mär 2006, 14:44

So es läuft jetzt wieder

, auch wenn ich jetzt noch nicht genau weiss warum. Damit aber Leute, die ähnliche Probleme haben, einen Anhaltspunkt finden noch ein paar Infos:

Der VPN-Packet Trace hat ja gezeigt, dass auf einer Seite die Pings der anderen Seite ankommen und die Antworten geschickt werden. Auf der anderen Seite sah man nur Pakete rausgehen, rein kam gar nichts.

Gestern hat der Provider auf einer Seite irgendetwas umgestellt ( hat sich darin geäussert, dass wir die falschen DNS-Server zugewiesen bekommen haben und das DNS tot war ).
Nachdem ich unseren ISP darauf hingewiesen habe, hat er dies korrigiert und als Nebeneffekt geht das VPN wieder.
Ich habe ein bissen weiter geforscht und mir wurde schlieslich mitgeteilt, das bei einem Ausfall vor 4 Wochen ein komplettes Blade abgeraucht ist und sie anscheinend die letzten 4 Wochen das neue wieder aufgebaut haben. Anscheinend wissen sie nicht wie die korrekte Konfiguration aussehen muss und es kam dadurch zu meinen Problemen.
Ist natürlich sehr ärgerlich, wenn das netz eigentlich geht, aber bestimmte Sachen eben nicht ( ESP in eine Richtung aber nicht in die andere ). Als ich dem Mitarbeiter von Protokoll 51 ( ESP ) erzählt habe, wusste er noch nicht einmal, das es so etwas gibt

.

Naja Hauptsache es läuft.

Zum Schluss vielleicht noch meine gesammelten Erfahrungen mit dem Lancom-Support. Bis zum Schluss habe ich mich sehr gut unterstützt gefühlt und muss sagen so motiviert habe ich noch keinen Support erlebt.
Leider wurde dieser sehr positive Eindruck am Schluss ein bissen getrübt. Da der Support auch keine Erklärung hatte, wollten sie sich das Szenario mal Live anschauen und haben mich um einen zugang auf die router gebeten ( da ist mir mal die Fresse abgestürzt, was für ein Service!! ).
Nachdem ich dann die Daten geändert und der Mitarbeiterin habe zukommen lassen, war plötzlich Funkstille. Niemand mehr erreichbar, keine Telefonnummer, keine Mail.
Ich kann nicht in Ruhe schlafen, wenn mein Netz für Unbekannte komplett offen ist und war deswegen dann doch ein bissen verärgert ( zumal der Support anstatts des SSH-Zuganges einen offenen Telnet haben wollte).

Zumindest eine Mail hätte ich erwartet, dass die Untersuchung auf den nächsten Tag verschoben werden soll, weil der Feierabend naht.
Insgesamt kann ich den Support aber nur positiv hervorheben und mein Ärger am Ende kam ja auch nur Zustande, weil ich im Prinzip vorher einfach baff war, wie gut Service sein kann.
Ich wollte jetzt auch mal was positives zum Thema Support sagen, da dieser ja sonst nur erwähnt wird, wenn er nicht funktioniert.

Gruss

Marc

tunichtgut · Beitrag von **tunichtgut** » 09 Mär 2006, 15:24

squize hat geschrieben:So es läuft jetzt wieder ,

....Ich kann nicht in Ruhe schlafen, wenn mein Netz für Unbekannte komplett offen ist und war deswegen dann doch ein bissen verärgert ( zumal der Support anstatts des SSH-Zuganges einen offenen Telnet haben wollte).

Zumindest eine Mail hätte ich erwartet, dass die Untersuchung auf den nächsten Tag verschoben werden soll, weil der Feierabend naht.
Insgesamt kann ich den Support aber nur positiv hervorheben und mein Ärger am Ende kam ja auch nur Zustande, weil ich im Prinzip vorher einfach baff war, wie gut Service sein kann.
Ich wollte jetzt auch mal was positives zum Thema Support sagen, da dieser ja sonst nur erwähnt wird, wenn er nicht funktioniert.
Marc

Das der Support sich das selbst auf dem(n) Router(n) ansieht und teilweise den Leuten auch Ihre Router fernkonfiguriert ist daily business weil am schnellsten und effektivsten...

Hättest den Router ruhig wieder dichtmachen können, die melden sich schon wenn sie draufwollen. Das es dann nicht so geklappt hat liegt meist an einem gewissen temporären Übernangebot an Arbeit. Termine sind immer so ne Sache, bei Hotlinetätigkeiten, schliesslich können die nicht einen pflegeintensiveren Kunden am Telefon abwimmeln, weil sie eigendlich jetzt einen Termin für einen Fernzugriff haben. Es würde mich aber wundern wenn sie nicht auf deinen fall zurückkämen, wenn da noch was offen ist.

squize · Beitrag von **squize** » 09 Mär 2006, 15:32

Klar im Nachhinein habe ich vollstes Verständniss dafür und die Kisten waren auch 5 Minuten nachdem ich die Infos geschickt habe und niemanden erreichen konnte wieder dicht

.

Ich wollte damit auch nur aufzeigen, dass dies vermeidbar gewesen wäre. Eine einfache Anweisung, die nötigen Infos bereitzuhalten und das man sich melden wird, wenn es losgeht, hätte genügt. So haben sie sich dazu hinreisen lassen, mir etwas in Aussicht zu stellen, was sie nicht erfüllen konnten und haben es dann auch nicht geschafft mir mitzuteilen, dass es nicht klappt.

Da ich selbst ein ausgesprochener Chaot bin, weiss ich wovon ich rede

. Ich habe mittlerwile zumindest gelernt keine Versprechungen zu machen, die ich nicht wirklich einhalten kann.

Gruss

Marc

COMCARGRU · Beitrag von **COMCARGRU** » 09 Mär 2006, 16:59

Häm ja, an dieser Stelle hat Lancom ein echtes Problem. Der Support will gerne auch mal die Konfiguration haben. Aber eine definierte Prozedur, daß diese verschlüsselt an Lancom übermittelt werden kann gibt es nicht.

Normal wäre doch das Lancom PGP besitzt, den öffentlichen Schlüssel bereit stellt. Und eingehende verschlüsselte Configs dann entschlüssen kann.

Ich finde es immer etwas merkwürdig wenn Hersteller von Sicherheitsprodukten bei ihren Prozeduren dann alles andere als sicher arbeiten...

Gruß
COMCARGRU

Empi · Beitrag von **Empi** » 09 Mär 2006, 18:18

Ich weiß zwar nicht ob es von Bedeutung ist, aber ich hatte damals das Problem, daß der DHCP von Kabel-BW eine private Adresse 172.16.xxx.xxx besitzt und das dafür eine Sperroute eingetragen war. Deshalb ist die Verbindung immer nach 30 Minuten unterbrochen worden.
In dem Karlsruher Router scheint die Sperroute für den Bereich noch eingetragen zu sein.

Gruß Empi

squize · Beitrag von **squize** » 10 Mär 2006, 21:59

Es läuft wieder und das

. Leider ist es nicht soweit gekommen, dass ich jetzt wirklich weiss woran es lag, die Wahrscheinlicheit, das KabelBW das PRoblem war, würde ich aber mal mit 90% angeben.
Beim Tracen der Pakete ist mir aufgefallen, dass ein Ping Richtung KabelBW ankommt und eine Antowrt auf wieder rausgeht. Nur kam diese Antowrt auf der anderen Seite nie an, d.h. KabelBW hat das ESP Protokoll nach aussen geblockt. In Phase 1 über UDP 500 lief alles wunderbar nur sobalde der Tunnel stand kam es zu Polling timeouts.
Als ich soweit war komplett hohlzudrehen, haben sie es geschafft noch mehr zu verbocken ( die falschen DNS-Server in DHCP einzutragen ). Dann habe ich mit einem Technicker gesprochen, der alles wieder richtig eingerichtet hat und schon ging der VPN-Tunnel.

Hätte ich eigentlich aber auch früher daraufkommen können. Ich konnte mir nur nicht vorstelen, warum ein ISP so etwas blocken sollte.

@Empi
Danke für den Tipp, wir bekommen aber offizielle IP's zugewiesen ( 82......)

Gruss

Marc

COMCARGRU · Beitrag von **COMCARGRU** » 10 Mär 2006, 23:06

Ich konnte mir nur nicht vorstelen, warum ein ISP so etwas blocken sollte.

Na das ist simpel: Um es als Feature extra berechnen zu können...

Gruß
COMCARGRU

Empi · Beitrag von **Empi** » 11 Mär 2006, 11:49

squize hat geschrieben: @Empi
Danke für den Tipp, wir bekommen aber offizielle IP's zugewiesen ( 82......)

Der Rechner bekommt eine 82.... IP zugewiesen das ist klar.
Aber der DHCP Server der diese IPs vergibt hatte zumindest bei mir eine lokale IP und das hat Probleme verusacht.

Gruß Empi