kein Internetzugriff aber VPN-Tunnel geht

[Ganzfix]

Hallo,
ich habe seit heute in einer Filiale das Problem, dass der Internetzugang nicht mehr geht. Die VPN-Verbindung zu unserer Hauptstelle geht.
Ich hatte gestern eine Änderung an der Konfiguration vorgenommen um an der VPN-Einwahl etwas zu ändern, nachdem heute die Probleme
mit dem Internetzugang auftraten habe ich die alte Konfiguration wieder eingespielt und dieses auch nochmal extra kontrolliert.

Man kann interne Webseite aufrufen, auch von der Hauptstelle (192.168.39.x). Aber externe gehen weder mit der IP noch noch mit dem Namen.
Wenn ich im Lanmonitor einen Ping auf die Adressen machen gehen die Pakete alle verloren.

Der Zugriff erfolgt normalerweise über KABELBW und als Backup über eine VDSL-Leitung der Telekom, aber mit beiden Leitungen geht es nicht.

Einen Neustart habe ich schon durchgeführt und auch den Router kurz stromlos machen lassen. Leider habe ich nun keine Ahnung mehr wo ich den Fehler noch suchen könnte

Gruß, Nils

[Dr.Einstein]

Hallo Nils,

der Ping über den Monitor taugt nix. Klinkt dich mal über VPN via Telnet/SSH auf den Außen-Router ein, und mach dann dort deine Pingtests mit IP-Adresse und/oder Namen.

Sollte inet Ping klemmen, mach z.B. trace # ip-r @ 8.8.8.8 und ping danach über die Commandline 8.8.8.8

Gruß Dr.Einstein

[Ganzfix]

Hallo Nils,

der Ping über den Monitor taugt nix. Klinkt dich mal über VPN via Telnet/SSH auf den Außen-Router ein, und mach dann dort deine Pingtests mit IP-Adresse und/oder Namen.

Sollte inet Ping klemmen, mach z.B. trace # ip-r @ 8.8.8.8 und ping danach über die Commandline 8.8.8.8

Gruß Dr.Einstein

Direkt auf dem Router:
Ping auf die Adresse ist erfolgreich:
56 Byte Packet from 193.99.144.80 seq.no=0 time=17.078 ms
56 Byte Packet from 193.99.144.80 seq.no=1 time=19.690 ms
Ping auf die IP ist erfolgreich:
56 Byte Packet from 193.99.144.80 seq.no=0 time=18.442 ms
56 Byte Packet from 193.99.144.80 seq.no=1 time=21.147 ms

Das Ping über die Commandline 8.8.8.8 führt zu Paketverlusten.

trace # ip-r @ 8.8.8.8
IP-Router ON @ 8.8.8.8

root@DRC_KA:/
>
[IP-Router] 2015/12/08 11:43:51,930
IP-Router Rx (intern, RtgTag: 0):
DstIP: 8.8.8.8, SrcIP: 192.168.178.20, Len: 66, TOS: ----
Prot.: UDP (17), DstPort: 53, SrcPort: 37557
Route: WAN Tx (KABELBW)

[IP-Router] 2015/12/08 11:43:52,769
IP-Router Rx (intern, RtgTag: 0):
DstIP: 8.8.8.8, SrcIP: 192.168.178.20, Len: 70, TOS: ----
Prot.: UDP (17), DstPort: 53, SrcPort: 38569
Route: WAN Tx (KABELBW)

[IP-Router] 2015/12/08 11:43:54,224
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 8.8.8.8, SrcIP: 10.0.0.129, Len: 60, TOS: ----
Prot.: ICMP (1), echo request, id: 0x0001, seq: 0x0039
Route: WAN Tx (KABELBW)

[IP-Router] 2015/12/08 11:43:58,834
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 8.8.8.8, SrcIP: 10.0.0.129, Len: 60, TOS: ----
Prot.: ICMP (1), echo request, id: 0x0001, seq: 0x003a
Route: WAN Tx (KABELBW)

[IP-Router] 2015/12/08 11:44:03,834
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 8.8.8.8, SrcIP: 10.0.0.129, Len: 60, TOS: ----
Prot.: ICMP (1), echo request, id: 0x0001, seq: 0x003b
Route: WAN Tx (KABELBW)

[IP-Router] 2015/12/08 11:44:08,476
IP-Router Rx (intern, RtgTag: 0):
DstIP: 8.8.8.8, SrcIP: 192.168.178.20, Len: 66, TOS: ----
Prot.: UDP (17), DstPort: 53, SrcPort: 38830
Route: WAN Tx (KABELBW)

[IP-Router] 2015/12/08 11:44:08,835
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 8.8.8.8, SrcIP: 10.0.0.129, Len: 60, TOS: ----
Prot.: ICMP (1), echo request, id: 0x0001, seq: 0x003c
Route: WAN Tx (KABELBW)

[Dr.Einstein]

Hallo Nils,

da im Trace

Code: Alles auswählen

Route: WAN Tx (KABELBW)

steht, würde ich mal in Richtung WAN schauen und den Lancom Router ausklammern. Außer die Parameter der Gegenstelle Kabel BW sind irgendwie falsch. Hast du da eine Fritzbox bekommen? Vielleicht die mal neu starten, oder einen Mitarbeiter via Laptop direkt ranhängen lassen und probieren?

[Ganzfix]

Hallo Nils,

da im Trace

Code: Alles auswählen

Route: WAN Tx (KABELBW)

steht, würde ich mal in Richtung WAN schauen und den Lancom Router ausklammern. Außer die Parameter der Gegenstelle Kabel BW sind irgendwie falsch. Hast du da eine Fritzbox bekommen? Vielleicht die mal neu starten, oder einen Mitarbeiter via Laptop direkt ranhängen lassen und probieren?

Ja, es ist eine Fritzbox. Der VPN-Tunnel geht aber über die Fritzbox, insofern scheint ja die Verbindung zu funktionieren. Sonst dürfte doch auch der Ping auf dem Lancom nicht funktionieren.
Ich habe die Fritzbox trotzdem schon neu gestartet. Da es aber mit der Backup-Leitung auch nicht geht, wenn ich die Verbindung zur Fritz-Box trennen lasse vermute ich doch eher ein Problem beim Lancom.

root@DRC_KA:/
> trace # ip-r @ 8.8.8.8
IP-Router ON @ 8.8.8.8

root@DRC_KA:/
>
[IP-Router] 2015/12/08 12:11:02,859
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 8.8.8.8, SrcIP: 10.0.0.129, Len: 60, TOS: ----
Prot.: ICMP (1), echo request, id: 0x0001, seq: 0x003d
Route: WAN Tx (KABELBW) (backup via T-DSLBIZ)

[IP-Router] 2015/12/08 12:11:07,444
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 8.8.8.8, SrcIP: 10.0.0.129, Len: 60, TOS: ----
Prot.: ICMP (1), echo request, id: 0x0001, seq: 0x003e
Route: WAN Tx (KABELBW) (backup via T-DSLBIZ)

[IP-Router] 2015/12/08 12:11:12,444
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 8.8.8.8, SrcIP: 10.0.0.129, Len: 60, TOS: ----
Prot.: ICMP (1), echo request, id: 0x0001, seq: 0x003f
Route: WAN Tx (KABELBW) (backup via T-DSLBIZ)

[MariusP]

Hi,
Hört sich ein bisschen nach möglichem DNS Problem an. Dienste die eine IP als Adresse verwenden vs Dienste die eine URL als Adresse verwenden.
Macht es einen unterschied ob du einen Ping von besagtem Router an eine IP und an eine URL abschickst?
Gruß

[Ganzfix]

Hi,
Hört sich ein bisschen nach möglichem DNS Problem an. Dienste die eine IP als Adresse verwenden vs Dienste die eine URL als Adresse verwenden.
Macht es einen unterschied ob du einen Ping von besagtem Router an eine IP und an eine URL abschickst?
Gruß

Das hatte ich kurzfristig auch mal gedacht. Aber auch ein Ping vom PC an eine IP scheitert.

Am Trace sieht man ja eigentlich dass, die Anfragen den Router erreichen, aber die Antwort-Pakete fehlen im Trace. Die gehen irgendwo verloren.

[backslash]

Hi Ganzfix

dann mach doch mal einen Ethernet-Trace davon - natürlich auch wieder auf die 8.8.8.8 gefiltert (und per Telnet auf das Gerät, *nicht* per SSH - sonst tracet du die Tace-Ausgaben mit und erhälst einen Teilchenbeschleuniger...):

trace # ip-ro eth @ 8.8.8.8

dann solltest du sehen, daß das Ping im LAN reinkommt, über den Router läuft und auf dem WAN wieder reusgeht. Wenn dann keine Antwort kommt, dann ist das LANCOM aussen vor...

Gruß
Backslash

[Ganzfix]

Hi Ganzfix

dann mach doch mal einen Ethernet-Trace davon - natürlich auch wieder auf die 8.8.8.8 gefiltert (und per Telnet auf das Gerät, *nicht* per SSH - sonst tracet du die Tace-Ausgaben mit und erhälst einen Teilchenbeschleuniger...):

trace # ip-ro eth @ 8.8.8.8

dann solltest du sehen, daß das Ping im LAN reinkommt, über den Router läuft und auf dem WAN wieder reusgeht. Wenn dann keine Antwort kommt, dann ist das LANCOM aussen vor...

Gruß
Backslash

Hallo Backslash, ich hoffe ich habe dich richtig verstanden.
Was mir dabei auffällt, ist das im zweiten Paket als"Src Address: 10.0.0.129" also die lokale IP angegeben ist. Wenn ich, das gleiche bei uns in der Hauptstelle
laufen lasse, steht dort die öffentliche IP des Routers. Weiß nun die entsprechende Stelle überhaupt wohin sie antworten soll?
Hier das Ergebnis

Code: Alles auswählen

> trace # ip-ro eth @ 8.8.8.8
IP-Router            ON  @ 8.8.8.8
Ethernet             ON  @ 8.8.8.8

root@DRC_KA:/
>
[Ethernet] 2015/12/08 18:16:07,073
Received 74 byte Ethernet packet via LAN-1:
HW Switch Port      : ETH-1
IPv4 Hdr Checksum   : OK
-->IEEE 802.3 Header
Dest                : 00:a0:57:1d:3e:a7 (LANCOM 1d:3e:a7)
Source              : 00:1c:c0:77:73:a7 (Intel-Malaysia 77:73:a7)
Type                : IPv4
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x00) (Precedence 0) / (DSCP CS0/BE)
Total length        : 60
ID                  : 2323
Fragment            : Offset 0
TTL                 : 128
Protocol            : ICMP
Checksum            : 5918 (OK)
Src Address         : 10.0.0.129
Dest Address        : 8.8.8.8
-->ICMP Header
Msg                 : echo request
Checksum            : 19703 (OK)
Identifier          : 1
Sequence            : 100
Body                : 61 62 63 64 65 66 67 68 abcdefgh
                      69 6a 6b 6c 6d 6e 6f 70 ijklmnop
                      71 72 73 74 75 76 77 61 qrstuvwa
                      62 63 64 65 66 67 68 69 bcdefghi


[IP-Router] 2015/12/08 18:16:07,073
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 8.8.8.8, SrcIP: 10.0.0.129, Len: 60, TOS: ----
Prot.: ICMP (1), echo request, id: 0x0001, seq: 0x0064
Route: WAN Tx (T-DSLBIZ)

[Ethernet] 2015/12/08 18:16:07,075
Sent 82 byte Ethernet packet via DSL-2:
-->IEEE 802.3 Header
Dest                : 00:90:1a:a0:15:ef (Unisphere a0:15:ef)
Source              : 02:a0:57:1d:3e:a7 (LANCOM(local-0) 1d:3e:a7)
Type                : PPPoE Session
-->PPPoE Session Packet
Version             : 1
Type                : 1
Code                : Session
Session-ID          : 7330
Payload Length      : 62
--->PPP Payload
Protocol            : IPv4
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x00) (Precedence 0) / (DSCP CS0/BE)
Total length        : 60
ID                  : 2323
Fragment            : Offset 0
TTL                 : 127
Protocol            : ICMP
Checksum            : 6174 (OK)
Src Address         : 10.0.0.129
Dest Address        : 8.8.8.8
-->ICMP Header
Msg                 : echo request
Checksum            : 19703 (OK)
Identifier          : 1
Sequence            : 100
Body                : 61 62 63 64 65 66 67 68 abcdefgh
                      69 6a 6b 6c 6d 6e 6f 70 ijklmnop
                      71 72 73 74 75 76 77 61 qrstuvwa
                      62 63 64 65 66 67 68 69 bcdefghi

Log aus Hauptstelle:

Code: Alles auswählen

oot@DRC-DSL18:/
> trace # ip-ro eth @ 8.8.8.8
IP-Router            ON  @ 8.8.8.8
Ethernet             ON  @ 8.8.8.8

root@DRC-DSL18:/
> 

[Ethernet] 2015/12/08 20:38:00,962
Received 74 byte Ethernet packet via LAN-1:
HW Switch Port      : ETH-1
IPv4 Hdr Checksum   : OK
-->IEEE 802.3 Header
Dest                : 00:a0:57:1e:94:36 (LANCOM 1e:94:36)
Source              : 00:22:4d:82:c2:10
Type                : IPv4
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x00) (Precedence 0) / (DSCP CS0/BE)
Total length        : 60
ID                  : 10206
Fragment            : Offset 0
TTL                 : 128
Protocol            : ICMP
Checksum            : 6786 (OK)
Src Address         : 192.168.39.169
Dest Address        : 8.8.8.8
-->ICMP Header
Msg                 : echo request
Checksum            : 19575 (OK)
Identifier          : 1
Sequence            : 228
Body                : 61 62 63 64 65 66 67 68 abcdefgh
                      69 6a 6b 6c 6d 6e 6f 70 ijklmnop
                      71 72 73 74 75 76 77 61 qrstuvwa
                      62 63 64 65 66 67 68 69 bcdefghi


[IP-Router] 2015/12/08 20:38:00,962
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0): 
DstIP: 8.8.8.8, SrcIP: 192.168.39.169, Len: 60, DSCP/TOS: 0x00
Prot.: ICMP (1), echo request, id: 0x0001, seq: 0x00e4
Route: WAN Tx (HEAG)

[Ethernet] 2015/12/08 20:38:00,963
Sent 74 byte Ethernet packet via DSL-2:
-->IEEE 802.3 Header
Dest                : 00:27:0d:69:9c:3f (Cisco 69:9c:3f)
Source              : 02:a0:57:1e:94:36 (LANCOM(local-0) 1e:94:36)
Type                : IPv4
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x00) (Precedence 0) / (DSCP CS0/BE)
Total length        : 60
ID                  : 5399
Fragment            : Offset 0
TTL                 : 127
Protocol            : ICMP
Checksum            : 20525 (OK)
Src Address         : (öffentliche statisch IP)
Dest Address        : 8.8.8.8
-->ICMP Header
Msg                 : echo request
Checksum            : 25974 (OK)
Identifier          : 59137
Sequence            : 228
Body                : 61 62 63 64 65 66 67 68 abcdefgh
                      69 6a 6b 6c 6d 6e 6f 70 ijklmnop
                      71 72 73 74 75 76 77 61 qrstuvwa
                      62 63 64 65 66 67 68 69 bcdefghi


[Ethernet] 2015/12/08 20:38:00,973
Received 74 byte Ethernet packet via DSL-2:
HW Switch Port      : ETH-4
IPv4 Hdr Checksum   : OK
-->IEEE 802.3 Header
Dest                : 02:a0:57:1e:94:36 (LANCOM(local-0) 1e:94:36)
Source              : 00:27:0d:69:9c:3f (Cisco 69:9c:3f)
Type                : IPv4
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x00) (Precedence 0) / (DSCP CS0/BE)
Total length        : 60
ID                  : 0
Fragment            : Offset 0
TTL                 : 49
Protocol            : ICMP
Checksum            : 45892 (OK)
Src Address         : 8.8.8.8
Dest Address        : (öffentliche statisch IP)
-->ICMP Header
Msg                 : echo reply
Checksum            : 28022 (OK)
Identifier          : 59137
Sequence            : 228
Body                : 61 62 63 64 65 66 67 68 abcdefgh
                      69 6a 6b 6c 6d 6e 6f 70 ijklmnop
                      71 72 73 74 75 76 77 61 qrstuvwa
                      62 63 64 65 66 67 68 69 bcdefghi


[IP-Router] 2015/12/08 20:38:00,974
IP-Router Rx (HEAG, RtgTag: 0): 
DstIP: 192.168.39.169, SrcIP: 8.8.8.8, Len: 60, DSCP/TOS: 0x00
Prot.: ICMP (1), echo reply, id: 0x0001, seq: 0x00e4
Route: BRG-1 Tx (INTRANET): 

[Ethernet] 2015/12/08 20:38:00,974
Sent 74 byte Ethernet packet via LAN-1:
HW Switch Port      : ETH-1
-->IEEE 802.3 Header
Dest                : 00:22:4d:82:c2:10
Source              : 00:a0:57:1e:94:36 (LANCOM 1e:94:36)
Type                : IPv4
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x00) (Precedence 0) / (DSCP CS0/BE)
Total length        : 60
ID                  : 0
Fragment            : Offset 0
TTL                 : 48
Protocol            : ICMP
Checksum            : 37472 (OK)
Src Address         : 8.8.8.8
Dest Address        : 192.168.39.169
-->ICMP Header
Msg                 : echo reply
Checksum            : 21623 (OK)
Identifier          : 1
Sequence            : 228
Body                : 61 62 63 64 65 66 67 68 abcdefgh
                      69 6a 6b 6c 6d 6e 6f 70 ijklmnop
                      71 72 73 74 75 76 77 61 qrstuvwa
                      62 63 64 65 66 67 68 69 bcdefghi

[backslash]

Hi Ganzfix,

Was mir dabei auffällt, ist das im zweiten Paket als"Src Address: 10.0.0.129" also die lokale IP angegeben ist. Wenn ich, das gleiche bei uns in der Hauptstelle
laufen lasse, steht dort die öffentliche IP des Routers. Weiß nun die entsprechende Stelle überhaupt wohin sie antworten soll?

und da hast du auch schon das Problem - und eigentlich auch die Lösung des Selben - vor Augen...

Deine Internetverbindung ist nicht maskiert...

Auch wenn die Maskierungsoption in der Routing-Tabelle an den Routen hängt ist sie eine Eigenschaft der Verbindung und es wird die Einstellung der Route verwendet, in der die Gegenstelle zum ersten mal auftaucht.... Daher: Immer darauf achten, daß die Maskierungsoption an allen Routen, die auf eine Gegenstelle zeigen, gleich ist...

Nach Umstellung der Maskierungsoption mußt du einmal die Internetverbindung trennen, damit die Einstellung wirksam wird...

Gruß
Backslash

[Ganzfix]

Hallo Backslash,

und da hast du auch schon das Problem - und eigentlich auch die Lösung des Selben - vor Augen...
Deine Internetverbindung ist nicht maskiert...
...

Auf die Maskierungsoption in der Routing-Tabelle war ich auch gekommen, konnte dort aber nichts ungewöhnliches erkennen. Erst kamen die VPN-Einwahlen, dann die VPN-Standort-Verbindungen. Diese waren "nicht maskiert". Dann kamen die Block-Routen für die privaten Netze und Multicast.
Zum Schluss kam die Maskierte Verbindung für den Rest. Ich hatte diese sogar testweise auf "nicht maskiert" und zurück auf "maskiert" gestellt sogar mit Neustarts dazwischen - ohne Ergebnis.
Ich hatte sogar einen Werksreset gemacht und versucht alte Konfigurationen zu verwenden die mehrere Wochen ohne Probleme liefen, aber irgendwo muss der Wurm drin gewesen sein.
Ich habe also ein Update auf die neueste Firmware gemacht und die Konfigurationen größtenteils manuell wieder eingegeben. Bisher tritt der Fehler nicht mehr auf. Habe mir nun eine Notkonfiguration gebaut in der nur das Notwendigste enthalten ist, sollte der Fall nochmal auftreten.
Sollte ich mal Zeit haben, was leider zu selten vorkommt, werde ich nochmal auf Fehlersuche begeben.

Gruß, Nils