VPN-Problem mit bintec R3000

Computer: Hardware Netzwerk
#1

Hallo,

wir haben ein Problem mit dem VPN-Zugang mit einem bintec R3000 Router.
Die letzten 5 Monate funktionierte der Zugang fehlerfrei und wir haben seit Monaten an der Konfiguration des Routers und der VPN-Clients nichts mehr
geändert. Seit dem 17.11.2008 können sich die VPN-Clients nicht mehr mit dem Router verbinden. Vom 17.11.2008 bis 20.11.2008 war es noch möglich,
die VPN-Verbindung jeweils unmittelbar nach einem Neustart des Routers über den „halt“-Befehl genau einmal aufzubauen. Nach dem
Abbau der Verbindung konnte sie jedoch nicht mehr aufgebaut werden. Erst nach einem erneuten Neustart des Routers ging es wieder für einmal.

Darauf hin habe ich unseren Ersatz-Router (ebenfalls ein R3000 mit gleicher Konfiguration) angeschlossen. Der Fehler blieb jedoch unverändert bestehen.
Die Konfiguration des Routers wurde im August zum letzten mal geändert und auf den Ersatz-Router kopiert.

Auf Anraten eines „Experten“ habe ich versucht, den VPN-Verbindungsvorgang über „debug ipsec“ und „debug all“ zu
protokollieren. In beiden Fällen wurden jedoch gar keine (!) Ereignisse angezeigt (und bei „debug all“ müsste eigentlich viel kommen).
Darauf hin habe ich auf beide Router das neueste Update (Release 7.6. Rev. 6) von der Funkwerk-Homepage installiert. Die VPN-Verbindung funktioniert zwar
immer noch nicht, aber die Protokollierung über „debug all“ funktionierte.

Zusätzlich haben wir von unserem Internet-Provider (m-net) unsere DSL-Leitung prüfen lassen. Dort liegt kein Fehler vor.

Zusätzlich habe ich den Verbindungsversuch auf dem Router mit „debug all“ protokolliert (siehe unten).

Wer kann uns sagen, was das VPN-Problem verursacht und was ich tun muss um den Fehler zu beheben?
Oder gibt es noch andere Tests die man mit Router und/oder VPN-Client durchführen kann um das Problem weiter einzugrenzen?

Für Hilfe sind wir mehr als Dankbar :wink:

AXL

PS:
Hier noch eine Kopie des Protokoll des Routers:

Welcome to R3000 version V.7.6 Rev. 6 IPSec from 2008/10/13 00:00:00
systemname is r3000, location

Login: admin
Password:

r3000:> debug all
09:52:40 DEBUG/ATM: titan adsl: ANNEX_B_GS_AccHandleExtEvent: GS_NOTIFY_OPSTATE_
CHANGE: HANDSHAKE (0x10) -> DISCOVERY (0x2e)
09:52:40 DEBUG/ATM: titan adsl: op state 0x2e (DISCOVERY), op progress 0x63 (ST
ARTING UP), last failed status 0x32 (STARTUP FAILED)
09:52:42 DEBUG/INET: new session, 192.168.3.11:63659->192.25.2.131:53 prot: 17 p
arent: false
09:52:42 DEBUG/INET: SIF: No Rule Ignore [1400:192.168.3.11:63659] -> [1:192.25.
2.131:53] :17
09:52:42 DEBUG/ATM: titan adsl: ANNEX_B_GS_AccHandleExtEvent: GS_NOTIFY_OPSTATE_
CHANGE: DISCOVERY (0x2e) -> TRAINING (0x18)
09:52:42 DEBUG/ATM: titan adsl: op state 0x18 (TRAINING), op progress 0x63 (STA
RTING UP), last failed status 0x39 (STARTUP FAILED)
09:52:43 DEBUG/INET: new session, 192.168.3.11:63659->195.85.254.254:53 prot: 17
parent: false
09:52:43 DEBUG/INET: SIF: No Rule Ignore [1400:192.168.3.11:63659] -> [1:195.85.
254.254:53] :17
09:52:43 DEBUG/INET: new session, 192.168.1.55:500->88.217.226.25:500 prot: 17 p
arent: false
09:52:44 DEBUG/INET: new session, 192.168.3.11:63548->192.25.2.131:53 prot: 17 p
arent: false
09:52:44 DEBUG/INET: SIF: No Rule Ignore [1400:192.168.3.11:63548] -> [1:192.25.
2.131:53] :17
09:52:45 DEBUG/INET: new session, 192.168.3.11:63548->195.85.254.254:53 prot: 17
parent: false
09:52:45 DEBUG/INET: SIF: No Rule Ignore [1400:192.168.3.11:63548] -> [1:195.85.
254.254:53] :17
09:52:46 DEBUG/INET: new session, 192.168.1.16:137->192.168.16.1:137 prot: 17 pa
rent: false
09:52:46 DEBUG/INET: SIF: No Rule Ignore [1000:192.168.1.16:137] -> [1:192.168.1
6.1:137] :17
09:52:49 DEBUG/INET: new session, 192.168.3.11:55664->192.25.2.131:53 prot: 17 p
arent: false
09:52:49 ERR/INET: SIF: WARNING Probably an attack from 192.168.3.11->192.25.2.1
31 (12 frames per second rejected)
09:52:50 DEBUG/ATM: titan adsl: ANNEX_B_GS_HandleLinkUp() Called.

09:52:50 DEBUG/ATM: titan adsl: ANNEX_B_GS_HandleLinkUp(): Setting selected std
to .

09:52:50 DEBUG/ATM: titan adsl: ANNEX_B_GS_InitBisEocReg() Called.

09:52:50 DEBUG/ATM: titan adsl: ANNEX_B_GS_AccHandleExtEvent: GS_NOTIFY_OPSTATE_
CHANGE: TRAINING (0x18) -> SHOWTIME (0x1)
09:52:50 INFO/ATM: titan adsl: ADSL link up
09:52:50 DEBUG/INET: new session, 192.168.1.16:1251->192.168.1.255:20001 prot: 1
7 parent: false
09:52:50 DEBUG/INET: SIF: No Rule Ignore [1000:192.168.1.16:1251] -> [1000:192.1
68.1.255:20001] :17
09:52:50 DEBUG/INET: new session, 192.168.3.11:55664->195.85.254.254:53 prot: 17
parent: false
09:52:50 ERR/INET: SIF: WARNING Probably an attack from 192.168.3.11->195.85.254
.254 (12 frames per second rejected)
09:52:50 DEBUG/INET: TIMEOUT Session expired: 192.168.1.1:1025->203.105.3.240:80
prot=6
09:52:50 DEBUG/INET: destroy session, 192.168.1.1:1025->203.105.3.240:80 prot: 6

09:52:51 DEBUG/ATM: titan adsl: op state 0x01 (SHOWTIME), Line Rate Common up 1
274 kbps / down 12028 kbps, Fast up 0 kbps / down 0 kbps, Interleaved up 1274 kb
ps / down 12028 kbps
09:52:51 DEBUG/ATM: titan adsl: SNR margin up 5.5 dB / down -2.4 dB, Attenuation
up 13.5 dB / down 17.0 dB, standard 0x1b (ADSL2PLUS), Annex B
09:52:51 DEBUG/ATM: titan adsl: Local Transmit: power: 12.6 dB, attenuation: 13.
5 dB, number of bins: 64
09:52:51 DEBUG/ATM: titan adsl: Remote Transmit: power: 20.5 dB, attenuation: 17
.0 dB, number of bins: 512
09:52:51 DEBUG/ATM: titan adsl: DSLAM info: ITU Vendor Id: 0x4244434d (‚BDCM‘),
ITU Vendor Country: 0xb500, ITU Vendor specific: 0x6296
09:52:52 DEBUG/PPP: discard message, ver: 1, type: 1, code: 00, length: 50
09:52:52 DEBUG/INET: TIMEOUT Session expired: 192.168.1.1:1026->194.153.113.99:8
0 prot=6
09:52:52 DEBUG/INET: destroy session, 192.168.1.1:1026->194.153.113.99:80 prot:
6
09:52:54 INFO/INET: refuse from if 1400 prot 17 192.168.3.11:137->192.168.3.255:
137 (RI 3 FI 1)
09:52:54 DEBUG/INET: TIMEOUT Session expired: 192.168.1.1:1027->194.153.113.98:8
0 prot=6
09:52:54 DEBUG/INET: destroy session, 192.168.1.1:1027->194.153.113.98:80 prot:
6
09:52:56 DEBUG/INET: new session, 192.168.3.11:63319->192.25.2.131:53 prot: 17 p
arent: false
09:52:56 DEBUG/INET: SIF: No Rule Ignore [1400:192.168.3.11:63319] -> [1:192.25.
2.131:53] :17
09:52:56 DEBUG/INET: TIMEOUT Session expired: 192.168.1.1:1028->194.153.113.93:8
0 prot=6
09:52:56 DEBUG/INET: destroy session, 192.168.1.1:1028->194.153.113.93:80 prot:
6
09:52:57 DEBUG/INET: new session, 192.168.3.11:63319->195.85.254.254:53 prot: 17
parent: false
09:52:57 DEBUG/INET: SIF: No Rule Ignore [1400:192.168.3.11:63319] -> [1:195.85.
254.254:53] :17
09:52:58 DEBUG/PPP: WIZ_XDSL_INT_PPPoE: send PPPoE Active Discovery Initiation (
PADI), interface: 50000

09:52:58 DEBUG/PPP: WIZ_XDSL_INT_PP 2/0/2/1: PPPoE call identified
09:52:58 DEBUG/PPP: WIZ_XDSL_INT_PP 2/1162/2/5: PPPoE session established
09:52:58 DEBUG/PPP: layer 1 type pppoe
09:52:58 DEBUG/PPP: WIZ_XDSL_INT_PPPoE: event: „associated link is operational u
p“,status: „pending dialout“ (dormant) -> „interface up“ (up)
09:52:58 DEBUG/PPP: WIZ_XDSL_INT_PPPoE: outgoing connection established
09:52:58 DEBUG/PPP: WIZ_XDSL_INT_PP 2/1162/2/5: PPPoE call identified
09:52:58 DEBUG/INET: TIMEOUT Session expired: 192.168.1.1:1029->206.253.225.7:80
prot=6
09:52:58 DEBUG/INET: destroy session, 192.168.1.1:1029->206.253.225.7:80 prot: 6

09:52:59 INFO/PPP: WIZ_XDSL_INT_PPPoE: local IP address is 88.217.226.25, remote
is 82.135.16.28
09:52:59 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 192.168.3.11

64916/88.217.226.25:48062 -> 195.85.254.254:53

09:52:59 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 192.168.3.11

64916/88.217.226.25:57573 -> 192.25.2.131:53

09:53:05 DEBUG/INET: NAT: new incoming session on ifc 10001 prot 6 192.168.1.12:
25/88.217.226.25:25 192.168.1.12:25 prot: 6 p
arent: false
09:53:05 DEBUG/INET: SIF: 7 Accept ANY[10001:58.210.51.120:37332] -> ANY[1000:19
2.168.1.12:25] smtp:6
09:53:05 DEBUG/INET: interface 10001: TCP SYNACK [88.217.226.25:25] -> [58.210.5
1.120:37332] clamp MSS 1460 ==> 1452
09:53:07 DEBUG/INET: NAT: new incoming session on ifc 10001 prot 6 192.168.1.12:
25/88.217.226.25:25 192.168.1.12:25 prot: 6 pa
rent: false
09:53:07 DEBUG/INET: SIF: 7 Accept ANY[10001:82.165.26.150:4471] -> ANY[1000:192
.168.1.12:25] smtp:6
09:53:07 DEBUG/INET: interface 10001: TCP SYNACK [88.217.226.25:25] -> [82.165.2
6.150:4471] clamp MSS 1460 ==> 1452
09:53:10 DEBUG/INET: new session, 192.168.1.113:2020->195.13.158.141:80 prot: 6
parent: false
09:53:10 DEBUG/INET: SIF: 2 Accept ANY[1000:192.168.1.113:2020] -> ANY[10001:195
.13.158.141:80] http:6
09:53:10 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 6 192.168.1.113

2020/88.217.226.25:46808 -> 195.13.158.141:80

09:53:10 DEBUG/INET: interface 10001: TCP SYN [88.217.226.25:46808] -> [195.13.1
58.141:80] clamp MSS 1460 ==> 1452
09:53:10 DEBUG/INET: TIMEOUT Session expired: 82.165.26.150:4471->192.168.1.12:2
5 prot=6
09:53:10 DEBUG/INET: destroy session, 82.165.26.150:4471->192.168.1.12:25 prot:
6
09:53:13 DEBUG/INET: NAT: new incoming session on ifc 10001 prot 6 192.168.1.12:
25/88.217.226.25:25 [192.168.
1.12:25] clamp MSS 1460 ==> 1452
09:53:13 DEBUG/INET: new session, 93.177.136.212:3296->192.168.1.12:25 prot: 6 p
arent: false
09:53:13 DEBUG/INET: SIF: 7 Accept ANY[10001:93.177.136.212:3296] -> ANY[1000:19
2.168.1.12:25] smtp:6
09:53:13 DEBUG/INET: interface 10001: TCP SYNACK [88.217.226.25:25] -> [93.177.1
36.212:3296] clamp MSS 1460 ==> 1452
09:53:15 DEBUG/INET: NAT: new incoming session on ifc 10001 prot 6 192.168.1.12:
25/88.217.226.25:25 192.168.1.12:25 prot: 6 pa
rent: false
09:53:15 DEBUG/INET: SIF: 7 Accept ANY[10001:114.198.43.73:3047] -> ANY[1000:192
.168.1.12:25] smtp:6
09:53:15 DEBUG/INET: interface 10001: TCP SYNACK [88.217.226.25:25] -> [114.198.
43.73:3047] clamp MSS 1460 ==> 1452
09:53:16 DEBUG/INET: NAT: new incoming session on ifc 10001 prot 6 192.168.1.12:
25/88.217.226.25:25 192.168.1.12:25 prot: 6 p
arent: false
09:53:16 DEBUG/INET: SIF: 7 Accept ANY[10001:58.210.51.120:37897] -> ANY[1000:19
2.168.1.12:25] smtp:6
09:53:16 DEBUG/INET: interface 10001: TCP SYNACK [88.217.226.25:25] -> [58.210.5
1.120:37897] clamp MSS 1460 ==> 1452

#2

Zusätzlich habe ich den Verbindungsversuch auf dem Router mit
„debug all“ protokolliert (siehe unten).

Was für einen Verbindungsversuch? Von aussen auf den Router?

Wenn du das Protokoll mal auf’s wesentliche reduzierst, das ganze Grundrauschen von smtp, dns und http rausschmeisst, hast du auch eine Chance, zu erkennen was da los ist. Da bleibt dann nichts weiter als eine teilweise aufgezeichnete pppoe-Session übrig, von irgendwelchen VPN-Verbindungsversuchen keine Spur.

Gruß

#3

Hallo,

danke für Deine Antwort.

Was für einen Verbindungsversuch? Von aussen auf den Router?

Ja genau, die Verbindungsversuche von den Clients zum Router. Auf
den Client kommt ja dann immer die Fehlermdlung „Kontakt zur Gegenstelle verloren“.

Wenn du das Protokoll mal auf’s wesentliche reduzierst, das
ganze Grundrauschen von smtp, dns und http rausschmeisst, hast
du auch eine Chance, zu erkennen was da los ist.

Würde ich gerne machen, nur weiß ich nicht genau was sinnvoll und was sinnlos ist. Von daher habe ich jetzt einfach mal alles reinkopiert.

Da bleibt dann nichts weiter als eine teilweise aufgezeichnete
pppoe-Session übrig, von irgendwelchen
VPN-Verbindungsversuchen keine Spur.

Und was genau sagt uns das? Ist das jetzt gut oder schlecht? Eine pppoe-Session muss es doch geben bei einer Verbindung oder nicht?

Gruß

#4

Und was genau sagt uns das? Ist das jetzt gut oder schlecht?
Eine pppoe-Session muss es doch geben bei einer Verbindung
oder nicht?

Nur, wenn ihr einen eigenen DSLAM betreibt und VPN darüber abwickelt. Was ich für eine äusserst ungewöhnliche Architektur hielte. In diesem Fall sollte man jedenfalls annehmen, das ihr jederzeit auf entspr. qualifiziertes Fachpersonal zurückgreifen könnt. Auch glaube ich nicht, dass die Brick 3000 das beherrscht, VPN handelt die Brick m. W. über IPSec ab.

Andernfalls sagt das Protokoll zur VPN-Verbindung nur eines aus: Dass während der Zeit des Mitschnitts definitiv kein Verbindungsversuch stattgefunden hat. Du musst also bei den Clients suchen.

Gruß

#5

so, was sehen wir hier:

Router hat erkannt das es ein DSL Signal gibt

CHANGE: HANDSHAKE (0x10) -> DISCOVERY (0x2e)
09:52:40 DEBUG/ATM: titan adsl: op state 0x2e (DISCOVERY), op
progress 0x63 (ST
ARTING UP), last failed status 0x32 (STARTUP FAILED)

Router wechselt in den Training mode (DSL Sync)

CHANGE: DISCOVERY (0x2e) -> TRAINING (0x18)
09:52:42 DEBUG/ATM: titan adsl: op state 0x18 (TRAINING)

… und hat seinen DSL sync

09:52:50 DEBUG/ATM: titan adsl: ANNEX_B_GS_HandleLinkUp()
Called.

—> DSL ist UP

CHANGE: TRAINING (0x18) -> SHOWTIME (0x1)
09:52:50 INFO/ATM: titan adsl: ADSL link up

infos zur DSL Leitung (speed, gegenstelle(dslam) usw

09:52:51 DEBUG/ATM: titan adsl: op state 0x01 (SHOWTIME), Line
Rate Common up 1
274 kbps / down 12028 kbps, Fast up 0 kbps / down 0 kbps,
Interleaved up 1274 kb
ps / down 12028 kbps
09:52:51 DEBUG/ATM: titan adsl: SNR margin up 5.5 dB / down
-2.4 dB, Attenuation
up 13.5 dB / down 17.0 dB, standard 0x1b (ADSL2PLUS), Annex B
09:52:51 DEBUG/ATM: titan adsl: Local Transmit: power: 12.6
dB, attenuation: 13.
5 dB, number of bins: 64
09:52:51 DEBUG/ATM: titan adsl: Remote Transmit: power: 20.5
dB, attenuation: 17
.0 dB, number of bins: 512
09:52:51 DEBUG/ATM: titan adsl: DSLAM info: ITU Vendor Id:
0x4244434d (‚BDCM‘),

Einwahl per PPPoe

09:52:58 DEBUG/PPP: WIZ_XDSL_INT_PPPoE: send PPPoE Active
Discovery Initiation (
PADI), interface: 50000

09:52:58 DEBUG/PPP: WIZ_XDSL_INT_PP 2/0/2/1: PPPoE call
identified
09:52:58 DEBUG/PPP: WIZ_XDSL_INT_PP 2/1162/2/5: PPPoE session
established
09:52:58 DEBUG/PPP: layer 1 type pppoe
09:52:58 DEBUG/PPP: WIZ_XDSL_INT_PPPoE: event: „associated
link is operational u
p“,status: „pending dialout“ (dormant) -> „interface up“
(up)
09:52:58 DEBUG/PPP: WIZ_XDSL_INT_PPPoE: outgoing connection
established
09:52:58 DEBUG/PPP: WIZ_XDSL_INT_PP 2/1162/2/5: PPPoE call
identified

mach mal ein „debug ipsec$“ und sorg dafür das sich ein Client einwählt ( mit dem FEC IPSec Client?) sollte jetzt keine meldung kommen versucht der Client die Verbindung zu einer falschen ip aufzubauen -> prüfen ob ip stimmt bzw bei dyndns die ip korrekt aktualisiert wurde

#6

Hallo Hilman,

vielen Dank für Deine Antwort.
Jetzt ist mir das Protokoll schon um einiges klarer, dennoch habe ich bzgl. des weiteren Vorgehens noch eine Frage.

mach mal ein „debug ipsec$“ und sorg dafür das sich ein Client
einwählt ( mit dem FEC IPSec Client?) sollte jetzt keine
meldung kommen versucht der Client die Verbindung zu einer
falschen ip aufzubauen -> prüfen ob ip stimmt bzw bei
dyndns die ip korrekt aktualisiert wurde

WIe mache ich ein „debug ipsec$“? Wir haben eine statische IP von unserem Provider, werde aus auf jeden fall kontrollieren ob bei den CLients die IP passt. Aber wie kann ich das Protokoll erweitern?

Gruß