Top-Themen

Aktuelle Themen (A bis Z)

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit

gelöst Verständnisproblem Routing - Anfängerfrage

Mitglied: niLuxx

niLuxx (Level 1) - Jetzt verbinden

07.12.2018, aktualisiert 10:01 Uhr, 511 Aufrufe, 40 Kommentare

Liebe Community,

Ich habe eine wohl typische Anfängerfrage in Bezug auf IP-Routing und Statische Routen. Die allgemeinen Grundlagen zu diesem Thema hatte ich mir schon durchgelesen, allerdings verstehe ich das Verhalten unseres Netzwerkes trotzdem nicht.

Unser Netzwerk besteht aus:
A) einem Cisco Router mit 2 Subnetzwerken:
Interface_0 => Outside-Interface => PPPoE
Interface_1 => Intern => 192.168.1.0/24

B) aus einem SG-300 Layer-3 Switch mit weiteren 4 Subnetzwerken/VLANs
192.168.1.0/24 => VLAN 1
10.0.2.0/24 => VLAN 22
192.168.3.0/24 => VLAN 33
192.168.4.0/24 => VLAN 44

Router und Switch sind verbunden über das Subnetzwerk 192.168.1.0/24
IP-Adresse des Routers = 192.168.1.1
IP-Adresse des Switch => 192.168.1.254

Als Statische IP-Routen haben wir folgende Einträge (Erst einmal nur zum Einrichten des Netzwerkes:

A) Router
1. 10.0.0.0/16 => Gateway 192.168.1.254 (Interface_1)
2. 192.168.0.0/16 => Gateway 192.168.1.254 (Interface_1)

B) Switch
1. 0.0.0.0./0 => Gateway 192.168.1.1 (Outgoing VLAN1)


Wie gesagt geht es erst einmal darum, dass wir die Server grundlegend konfigurieren möchten, deswegen hat jedes Subnetzwerk (erst einmal) Zugriff auf alles.
Clients, die sich mittels VPN mit dieser Netzwerkinfrastruktur verbinden wollen, erhalten eine IP aus dem Subnetz des Routers 192.168.1.0/24

Folgende Beobachtungen habe ich gemacht, die ich mir nicht erklären kann:

1. VPN-Client (192.168.1.103) hat Zugriff auf das 10.0.2.0/24 Netzwerk (z.B. ping) => Das ist gewollt, aber warum funktioniert das?
=> Verbindungen zu (beispielsweise 10.0.2.6) gehen über Gateway 192.168.1.254 => das ist klar
=> aber müsste in diesem Fall dann nicht die statische Route B.1 die Anfrage dann wieder in Richtung 192.168.1.1. schicken? => wie eine Art "loop"

2. VPN-Client (192.168.1.103) hat KEINEN Zugriff auf das 192.168.3.0/24 Netzwerk (z.B. ping) => Das ist NICHT gewollt, aber warum funktioniert das nicht, wenn Option 1 doch auch funktioniert?

3. Client 10.0.2.5 hat Zugriff auf 192.168.3.254 (Switch Interface des 192.168.3.0/24 Subnetzes)
=> Wie ist das möglich wenn ich VLANs-konfiguriert habe und alle Verbindungen (B.1) eigentlich an die 192.168.1.1. gehen sollten?

Wo ist mein Denkfehler?

Liebe Grüße,
niLuxx
40 Antworten
Mitglied: emeriks
07.12.2018, aktualisiert um 11:29 Uhr
Hi,
Grundsätzlich:
Bloß IP-Adressen der einzelnen Host (z.B. "VPN-Client (192.168.1.103)") anzugeben reicht hier nicht. Du musst uns bitte auch mitteilen, welche Default Gateways und/oder statische Routen diese eingetragen haben.

1. VPN-Client (192.168.1.103) hat Zugriff auf das 10.0.2.0/24 Netzwerk (z.B. ping) => Das ist gewollt, aber warum funktioniert das?
=> Verbindungen zu (beispielsweise 10.0.2.6) gehen über Gateway 192.168.1.254 => das ist klar
=> aber müsste in diesem Fall dann nicht die statische Route B.1 die Anfrage dann wieder in Richtung 192.168.1.1. schicken? => wie eine Art "loop"
Nein. Die Routen in die Netze, an welche der Switch-Router direkt angeschlossen ist, haben eine höhere Priorität. (niedere Kosten)

2. VPN-Client (192.168.1.103) hat KEINEN Zugriff auf das 192.168.3.0/24 Netzwerk (z.B. ping) => Das ist NICHT gewollt, aber warum funktioniert das nicht, wenn Option 1 doch auch funktioniert?
Welches Default Gateway hat dieser Client?

3. Client 10.0.2.5 hat Zugriff auf 192.168.3.254 (Switch Interface des 192.168.3.0/24 Subnetzes)
=> Wie ist das möglich wenn ich VLANs-konfiguriert habe und alle Verbindungen (B.1) eigentlich an die 192.168.1.1. gehen sollten?
Hier ist zu vermuten, dass der Client den Switch mit seiner Adresse aus dem 10'-Netz als Default Gateway eingetragen hat. Falls ja, dann ist das Verhalten logisch. Ein Router braucht für die Netze, an welche er direkt angeschlossen ist, keine extra Routen eingetragen.

E.
Bitte warten ..
Mitglied: Lochkartenstanzer
07.12.2018 um 11:35 Uhr
Zitat von niLuxx:

1. VPN-Client (192.168.1.103) hat Zugriff auf das 10.0.2.0/24 Netzwerk (z.B. ping) => Das ist gewollt, aber warum funktioniert das?
=> Verbindungen zu (beispielsweise 10.0.2.6) gehen über Gateway 192.168.1.254 => das ist klar
=> aber müsste in diesem Fall dann nicht die statische Route B.1 die Anfrage dann wieder in Richtung 192.168.1.1. schicken? => wie eine Art "loop"

Nein, denn der Switch kennt ja das lokale Netz 10.0.2.0/24 und schickt es daher eben nicht ans default Gateway.

2. VPN-Client (192.168.1.103) hat KEINEN Zugriff auf das 192.168.3.0/24 Netzwerk (z.B. ping) => Das ist NICHT gewollt, aber warum funktioniert das nicht, wenn Option 1 doch auch funktioniert?

Welche ACLs sind denn eingestellt? Kennen die ziele in 192.168.3.0/24 denn das richtige Gateway? Was sagt ein Sniffer dazu?

3. Client 10.0.2.5 hat Zugriff auf 192.168.3.254 (Switch Interface des 192.168.3.0/24 Subnetzes)
=> Wie ist das möglich wenn ich VLANs-konfiguriert habe und alle Verbindungen (B.1) eigentlich an die 192.168.1.1. gehen sollten?

Der Switch-Router kennt seine lokalen Netze. Ein spzifischeres netz überstimmt das allgemeinere netz.

lks
Bitte warten ..
Mitglied: niLuxx
07.12.2018 um 11:43 Uhr
Liebe Community,

Danke für eure Kommentare. Punkt 1 und 3 sind mir nun klar. Mir war nicht bewusst, dass der Switch interne Netze automatisch routet. Ich dachte auch das muss ihm erst explizit gesagt werden.

Zu Punkt 2:
Default Gateway des VPN-Clients (192.168.1.103) ist die 192.168.1.1 (er soll gleichzeitig ins Internet). Mich wundert es praktisch nur, dass es bei 10.0.0.0/16 geht und bei 192.168.0.0/16 nicht. Das scheint doch eigentlich das gleiche zu sein....
Ich habe es auch mit der Route 192.168.3.0/24 versucht. Leider ebenso ohne Erfolg.
ACL sind keine definiert. Nur das Standard-Security Level der Cisco Interfaces
Bitte warten ..
Mitglied: emeriks
07.12.2018 um 11:46 Uhr
Zitat von niLuxx:
Ich habe es auch mit der Route 192.168.3.0/24 versucht. Leider ebenso ohne Erfolg.
War diese zusätzlich drin oder als Ersatz für die "192.168.0.0/16 => Gateway 192.168.1.254 (Interface_1)" ?
Bitte warten ..
Mitglied: niLuxx
07.12.2018, aktualisiert um 11:49 Uhr
War diese zusätzlich drin oder als Ersatz für die "192.168.0.0/16 => Gateway 192.168.1.254 (Interface_1)" ?
Als Ersatz
Bitte warten ..
Mitglied: aqui
07.12.2018, aktualisiert um 12:49 Uhr
Dein Design ist ein klassisches VLAN Design mit einem Internet Transfernetz zum Router und sieht genau so aus, richtig ??

sgcisco - Klicke auf das Bild, um es zu vergrößern
Das ist ein Standard Design und die genauen Setups dazu beschreibt dieser Thread:
https://administrator.de/forum/verständnissproblem-routing-sg300-28 ...
Die unterschiedliche IP Adressierung ist dabei kosmetisch und musst du dir auf deine umdenken.

Kommen wir mal zu deinen Fragen:
1.)
VPN-Client (192.168.1.103) hat als Default Gateway den Router 192.168.1.1. Den kontaktiert er wenn er in fremde Netze muss, logisch. Dort findet er eine statische Route, die ihm sagt das er das 10.0.2.0er Netzwerk via Layer 3 (Routing) Switch SG-300 über die next Hop IP 192.168.1.254 findet.
Der Router sendet das Paket jetzt zum Switchport in VLAN 1 (192.168.1.254), der Switch selber "kennt" das 10er Netzwerk ja, da es an ihm selber angeschlossen ist und forwardet das zum gepingten Endgerät im 10.0.2.0er Netz !
Fertisch ! Deshalb funktioniert das ! Works as designed...klassisches IP Routing wie es dir auch HIER_im_Tutorial erklärt wird !
2.)
VPN-Client (192.168.1.103) ist Opfer einer Access Liste am SG-300 Switch !
In dieser Switch IP Access Liste wird explizit der Zugriff von Paketen mit einer Absender IP aus dem Netz 192.168.1.0 /24 auf das Netz 192.168.3.0 /24 verboten !!
Deshalb funktioniert das nicht ! Works also as designed...
3.)
Client 10.0.2.5 sendet seine Pakete an die Switch VLAN IP Adresse in diesem VLAN, denn das ist ja sein Default Gateway wenn er in fremde IP Netze muss ! Logisch....
Der SG-300 Switch ist ein Layer 3 Switch, also auch ein Router der zwischen den VLAN Segmenten routet ! Logisch, sonst wäre er ja auch kein Routing Switch (L3) !!
Der "kennt" also alle direkt an ihm angeschlossenen IP Netze (VLANs) und kann sie routen. Folglich kommt Client 10.0.2.5 dann also auch ins 192.168.3.0er Netz !
Deshalb funktioniert auch das !

Also alles simpelste Routing Grundlagen. Wo ist denn nun dein wirkliches (Freitags fish - Klicke auf das Bild, um es zu vergrößern) Problem ??
Bitte warten ..
Mitglied: niLuxx
07.12.2018 um 12:56 Uhr
Hallo Aqui,

Danke für deine (mal wieder) sehr ausführliche Antwort
Punkte 1 und 3 sind jetzt klar.

Punkt 2 allerdings noch nicht. Müsste dann nicht auch der Zugang vom VPN Client in die 10.0.0.0/16 Netze blockiert werden?

Liebe Grüße,
niLuxx
Bitte warten ..
Mitglied: niLuxx
07.12.2018, aktualisiert um 13:07 Uhr
Vielleicht ein kurzes Update.

Ich habe im 192.168.3.0/24 Netz letztlich 2 Endpunkte die erreichbar sein sollten:
1. 192.168.3.2 => VSphere
2. 192.168.3.254 => IPv4 Interface des Switch

Beide Endpunkte sind nicht vom VPN-Client aus erreichbar.
Probiere ich allerdings ein traceroute vom Router erhalte ich:
A) traceroute 192.168.3.254 =>ping ist erfolgreich
B) traceroute 192.168.3.2 => einen HOP auf 192.168.1.1 und Ende

Von meinem VPN Client erreiche ich keinen der beiden Endpunkte.
Von einem Rechner innerhalb des 10.0.2.0/24 Netzes erreiche ich beide Endpunkte

Das Problem scheint also multiple zu sein.
Fehlendes/Gesperrtes Routing vom VPN-Client ins 192.168.3.0/24 Netz, sowie gesperrtes Routing vom Switch Endpunkt zum 192.168.3.2
Bitte warten ..
Mitglied: aqui
07.12.2018, aktualisiert um 13:15 Uhr
Müsste dann nicht auch der Zugang vom VPN Client in die 10.0.0.0/16 Netze blockiert
Nöö, warum ?
Die Access Liste laute ja irgendwie so:
ip access list DENY ip access list DENY 192.168.1.0 0.0.0.255 192.168.3.0 0.0.0.255
ip access list PERMIT 192.168.1.0 0.0.0.255 any

Siehst du da irgendwas was nach 10.x.x.x Zielnetzen aussieht ??
Die ACL gilt eben nur für Absender 192.168.1.0 und Ziel 192.168.3.0 !
Das Ziel 10.0.0.0/16 ist davon doch gar nicht betroffen und kann da ip access list PERMIT 192.168.1.0 0.0.0.255 any alle anderen Ziele erlaubt sind passieren !
Works as designed...

Ich habe im 192.168.3.0/24 Netz letztlich 2 Endpunkte die erreichbar sein sollten:
Dann passt du deine Access Liste eben an !! und blockierst das ganze Netz mit Ausnahme dieser beiden Hosts !
ip access list PERMIT 192.168.1.0 0.0.0.255 host 192.168.3.2
ip access list PERMIT 192.168.1.0 0.0.0.255 host 192.168.3.254
ip access list DENY ip access list DENY 192.168.1.0 0.0.0.255 192.168.3.0 0.0.0.255
ip access list PERMIT 192.168.1.0 0.0.0.255 any

Die Access Listen Syntax ist ja selbsterklärend....
So kommen vom 192.168.1.0er Netz alle auf die beiden Hosts 192.168.3.2 und 192.168.3.254 aber nicht mehr in den Rest des 192.168.3.0er Netzes. Ganz einfach !

Wenn du auch nicht willst das das 10.0.2.0er Netz aus dem 192.168.1.0er Netz erreichbar ist passt du deine Switch ACL entsprechend an:
ip access list PERMIT 192.168.1.0 0.0.0.255 host 192.168.3.2
ip access list PERMIT 192.168.1.0 0.0.0.255 host 192.168.3.254
ip access list DENY ip access list DENY 192.168.1.0 0.0.0.255 192.168.3.0 0.0.0.255
ip access list DENY ip access list DENY 192.168.1.0 0.0.0.255 10.0.2.0 0.0.0.255
ip access list PERMIT 192.168.1.0 0.0.0.255 any

Fertsch !
Einfache ACL Logik...
Bitte warten ..
Mitglied: niLuxx
07.12.2018 um 13:16 Uhr
Ich befürchte das ist es nicht
show access-list zeigt:
No ACLs are defined (am Switch)
Bitte warten ..
Mitglied: niLuxx
07.12.2018 um 13:19 Uhr
Das muss irgendein dummer Fehler sein!
Beim Switch gibt es das integrierte "Tracerout" Tool. Es funktioniert bei allen IPs im Netz, außer bei 192.168.3.2. Als wäre der Client abgeschalten. Vom 10.0.3.0/24 Netz kann ich den 192.168.3.2 aber aufrufen und sogar den Vsphere Client übers Netz verwenden.
Bitte warten ..
Mitglied: aqui
07.12.2018, aktualisiert um 13:29 Uhr
Beide Endpunkte sind nicht vom VPN-Client aus erreichbar.
Mmmhhh...das kann nur 2 Ursachen haben:
  • Switch VLAN Routen auf dem Internet Router .1.1 fehlen
  • Switch hat eine (falsche) Access Liste
raceroute 192.168.3.254 =>ping ist erfolgreich
Das ist jetzt irgendwie Blödsinn
Traceroute ist kein Ping ! Ping ist ICMP Echo (ICMP Protokoll)
Wenn du eine Winblows Gurke aus Fremdnetzen anpingst musst du das IMMER erst in der lokalen Firewall freigeben !
Winblows blockt hier immer generell ICMP !
https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen

icmp-firewall - Klicke auf das Bild, um es zu vergrößern
traceroute 192.168.3.2 => einen HOP auf 192.168.1.1 und Ende
Also....wie oben schon vermutet !!
Hier FEHLEN deine statischen VLAN Routen auf dem Internet Router !!
Dort muss logischerweise stehen:
Ziel: 192.168.0.0 Maske: 255.255.248.0 Gateway: 192.168.1.254
Ziel: 10.0.0.0 Maske: 255.255.0.0 Gateway: 192.168.1.254

Sonst werden Pakete OHNE diese Routen dann zum Provider und damit ins Daten Nirwana geschickt !
Private RFC 1918 IP Adressen werden im Internet NICHT geroutet !

Wenn es das mit den Routen nicht ist hast du eine FALSCHE Access Liste im Switch ! Sofern du denn überhaupt eine hast ?!
No ACLs are defined (am Switch)
OK, dann sinds die fehlenden Routen ! Oder die fehlenden VLAN IP Adressen im Switch oder...
Die falschen gateway Einträge der Endgeräte in den VLANs ! Die müssen logischerweise IMMER auf die entsprechend korrespondierende Switch VLAN IP zeigen. Das ist ja immer deren Gateway, da der Switch ein Router ist !
Das Problem scheint also multiple zu sein.
Vermutlich eher nicht sondern PEBKAC !
Bitte warten ..
Mitglied: niLuxx
07.12.2018 um 13:42 Uhr
Leider auch nicht die fehlenden Routen befrüchte ich. Ich habe folgende Einträge als Statische Routen schon gesetzt:
10.0.0.0 / 16 => 192.168.1.254
192.168.3.0/24 => 192.168.1.254

Leider keine Änderung
Bitte warten ..
Mitglied: niLuxx
07.12.2018, aktualisiert um 13:51 Uhr
Wobei es wieder eine Änderung gibt (check das langsam echt nimmer...):
1. Ping-Tool am Internet-Router zeigt für 192.168.3.2 SUCCESS
2. Traceroute bleibt wie gesagt hängen an der 192.168.1.254, wähle ich allerdings die Option "Use ICMP" ist traceroute erfolgreich
Bitte warten ..
Mitglied: aqui
07.12.2018 um 13:54 Uhr
Deine Switch Konfig ist dann falsch !
Vermutlich hast du hier die IP Adressen den VLANs falösch zugeordnet oder sie gar nicht den entsprechenden VLANs zugeordnet...?!
Eine andere Option bleibt nicht mehr übrig wenn die Gateway IPs an den Endgeräten stimmen.

Kannst du von einem 10er oder 192.168.3.er Host die .1.254 und dann auch die .1.1 pingen ??
Bitte warten ..
Mitglied: niLuxx
07.12.2018 um 14:56 Uhr
Ja, das sollte auch passen. Ich habe für jedes VLAN ein Interface eingerichtet
VLAN 1 => 192.168.1.254
VLAN 66 => 192.168.3.254
VLAN 33 => 10.0.3.254

. Vom 10er komme ich auf:
die 192.168.3.2, 192.168.3.254, 192.168.1.1 und 192.168.1.254

Kann es sein, dass VSphere irgendwas blockiert was von außerhalb des 192.168.1.1 kommt?
Bitte warten ..
Mitglied: aqui
07.12.2018 um 15:32 Uhr
Ja, das ist sehr gut möglich !
Hier ist von essentieller bedeutung WIE die virtuellen NICs angebunden sind bzw. WIE der vSwitch konfiguriert ist.
Wenn Hypervisor und VMs nur in einem gemeinsamen Netz sind dann das das alles nur im Bridging Mode sein.
Da liegt dann vermutlich der Fehler.
Um das einzugrenzen solltest du alle deine 3 VLANs checken das aus allen 3 Netzen alle anderen erreichbar sind. Also mit einem Laptop erstmal ein Any zu Any Check machen.
Das verifiziert dann das deine reine netzwerk Infrastruktur korrekt und sauber funktioniert.
Dann liegt der Fehler nur im Hypervisor Setup.
Bitte warten ..
Mitglied: niLuxx
10.12.2018 um 05:47 Uhr
Bei längerem Überlegen macht allerdings auch das keinen Sinn... Müsste mein VPN-Client dann nicht wenigstens Zugriff auf die 192.168.3.254 haben?
Bitte warten ..
Mitglied: aqui
10.12.2018 um 13:34 Uhr
Warum eigentlich immer VPN Client ??
Du benutzt doch wohl hoffentlich kein VPN im internen Netzwerk, oder ??
Die .3.254 ist ja der Router im L3 Switch. VPN kann der logischerweise natürlich nicht aber wenn der Client irgendwo in andere IP Netze muss sei es mit dem VPN oder was auch immer, dann muss er die .254 als Default Gateway eingetragen haben wenn er selber ein Endgerät im 192.168.3.0er Netz ist !!
Bitte warten ..
Mitglied: niLuxx
11.12.2018, aktualisiert um 05:44 Uhr
Nein.
Der "VPN-Client" ist ein normaler, via VPN verbundener Laptop.
=> Und der sollte doch eigentlich Zugriff auf den .3.254 haben, selbst wenn das VSphere irgendetwas am .3.2 blockieren sollte.

Wenn ich das mal alles zusammenfasse:
=> Internet-Router erreicht mittels ping .3.254 und .3.2
=> L-3 Switch erreicht ebenfalls .3.254 und .3.2
=> VPN-Client erreicht weder .3.254 noch .3.2, allerdings jeden Client in anderen Subnetzen

Schätzungsweise kann es also nur ein Problem mit dem Routing sein, oder mit einem mir unbekannten ACE...

Gibt es bei Windows nicht eine Möglichkeit den Traffic detailliert zu tracken?
Beispielsweise bei "ping 192.168.3.254" zu sehen, welchen Gateway er wählt und welche Antwort er von dort erhält? (Denied, not found, etc.)?
Bitte warten ..
Mitglied: Lochkartenstanzer
11.12.2018, aktualisiert um 07:06 Uhr
Zitat von niLuxx:

Gibt es bei Windows nicht eine Möglichkeit den Traffic detailliert zu tracken?
Beispielsweise bei "ping 192.168.3.254" zu sehen, welchen Gateway er wählt und welche Antwort er von dort erhält? (Denied, not found, etc.)?

Wireshark ist Dein Freund.

Welcher Deiner Kisten ist eigentlich der VPN-Endpunkt?

lks
Bitte warten ..
Mitglied: niLuxx
11.12.2018 um 09:16 Uhr
Der Internet-Router. Und komischerweise komme ich darüber ja auch in das 10.0.0.0/16 Netz, aber nicht in das 192.168.3.0/24 Netz, was über den gleichen Gateway geht.
Vielleicht ist es auch so eine komische Sache, dass nach Änderung von statischen Routen der VPN Adapter neu gestartet werden muss oder so etwas...
Bitte warten ..
Mitglied: aqui
11.12.2018, aktualisiert um 09:35 Uhr
Und der sollte doch eigentlich Zugriff auf den .3.254 haben
Das kommt darauf an....
Wenn das VPN kein Split Tunneling kann oder macht und er den VPN Client aktiviert hat, gibt es beim VPN dann ein Gateway Redirect der allen Traffic in den VPN Tunnel sendet...auch den zu .3.254 !
Möglich also das er mit aktivem VPN Client die .3.254 nicht erreichen kann mit inaktivem Client aber schon !
Das zeigt dann das kein Split Tunneling oder ein falsches VPN eingerichtet wurde
Hast du das auf dem Radar bei VPN ???
Bitte warten ..
Mitglied: niLuxx
11.12.2018 um 10:27 Uhr
Ich befürchte nicht.
Ich bin leider blutiger Anfänger im Bereich VPN. Ich verwende den AnyConnect Mobile Client von Cisco. Das Routing in Richtung 10.0.0.0/16 wurde damals auch von Cisco eingerichtet.

Liebe Grüße,
niLuxx
Bitte warten ..
Mitglied: aqui
11.12.2018, aktualisiert um 10:38 Uhr
Starte den VPN Client und gib in der Eingabeaufforderung route print ein !!
Dann siehst du die lokale Routing Tabelle des Rechners (Winblows) und wenn du siehst das 10.0.0.0/16 oder der ganze Traffic (Gateway Redirect) in den Tunnel geht weisst du was los ist !
Übrigens richtet Cisco als Hersteller niemals direkt bei Endkunden irgend etwas ein !
Bitte warten ..
Mitglied: niLuxx
11.12.2018, aktualisiert um 11:49 Uhr
Wenn man beim TAC ein Ticket zieht schon Das VPN war ja eingerichtet, nur das Routing ging nicht.

Danke für den Tip mit den Routen. Ich sehe hier meine VPN-Schnittstelle mit sieben Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.103 2
192.168.1.0 255.255.255.0 Auf Verbindung 192.168.1.103 257
192.168.1.103 255.255.255.255 Auf Verbindung 192.168.1.103 257
192.168.1.255 255.255.255.255 Auf Verbindung 192.168.1.103 257
192.168.3.0 255.255.255.0 192.168.1.1 192.168.1.103 2
224.0.0.0 240.0.0.0 Auf Verbindung 192.168.1.103 257
255.255.255.255 255.255.255.255 Auf Verbindung 192.168.1.103 257

=> Endpunkte aus dem Netz 192.168.3.0/24 werden über die 192.168.1.1 geroutet. Das ist ja aber Quatsch...
Die sollten ja über die 192.168.1.254 laufen.
=> Außerdem sehe ich keine Route für das 10.0.0.0/16 Netz
=> Die 0.0.0.0 0.0.0.0 über 192.168.1.1 => fürs Internet OK, aber sollte das nicht dann eine niedrigere Metrik haben (e.g. 1)?

=> es gibt noch die Routen einer anderen Schnittstelle:
192.168.3.0 255.255.255.0 Auf Verbindung 192.168.3.40 28
Das würde doch praktisch bedeuten, dass diese primär durchgeführt oder?
Die 192.168.3.40 ist die Adresse der FritzBox meines Heimnetzes
Bitte warten ..
Mitglied: niLuxx
11.12.2018 um 14:00 Uhr
Ich glaube ich habe das Problem gefunden, ohne es zu verstehen

Der Log des Internet-Routers sagt beim ping 192.168.3.2:

Asymmetric NAT rules matched for forward and reverse flows; Connection for icmp src outside:192.168.1.103(LOCAL\XXXXXX) dst internal:192.168.3.2 (type 8, code 0) denied due to NAT reverse path failure
Bitte warten ..
Mitglied: aqui
11.12.2018, aktualisiert um 14:37 Uhr
Ich sehe hier meine VPN-Schnittstelle mit sieben Routen:
Und ALLE gehen auf das Gateway 192.168.1.103 wie du ja selber sehen kannst !!
Das ist ja ganz sicher NICHT dein Switch !!
Fazit:
VPN Client ist FALSCH konfiguriert ! Musste Split Tunneling machen, macht aber ein Default Gateway Redirect auf die 192.168.1.103 !
Wenn die 192.168.1.103 auch wieder Routen in dein 3.0er netz hat, dann klappts auch wieder
Hat es vermutlich aber nicht. Musst du denjenigen fragen der den VPN Server eingerichtet hat !
Endpunkte aus dem Netz 192.168.3.0/24 werden über die 192.168.1.1 geroutet. Das ist ja aber Quatsch...
Richtig !
Deine Routing Tabble sagt ja das es auch über die 192.168.1.103 geroutet wird !
Hier zeigt dir nur ein Traceroute (tracert bei Winblows) wo es wirklich hingeht. Führe mal ein tracert 192.168.3.254 aus und sehe dir den next Hop an. Da gehts dann auch hin !
Die sollten ja über die 192.168.1.254 laufen.
Das kommt dann noch dazu und legt den Verdacht nahe das du den Endgeräten im 192.168.1.0er Netz ein falsches Default Gateway definiert hast ! Das muss dann auch die 192.168.1.254 sein und nix anderes.
Denk aber immer dran...ein aktiver und ggf. falsch konfigurierter VPN Client kann diese Routen wieder "verbiegen" wenn der VPN Client aktiv ist !!!
es gibt noch die Routen einer anderen Schnittstelle:
Uuuhhh gruselig. Was hast du denn da überall für einen Mist konfiguriert im Gateway und Routing !!!??
Das ist ja gruseliges Chaos !
Oder kann es sein das es diese VPN Netze noch irgendwo anders, also doppelt gibt ?? Das dürfte auch niemals sein !!
Bitte warten ..
Mitglied: niLuxx
11.12.2018, aktualisiert um 14:48 Uhr
Und ALLE gehen auf das Gateway 192.168.1.103 wie du ja selber sehen kannst !!
Ich glaube das war ein Missverständnis bzw. Formatierungsproblem
=> Die 192.168.1.103 bezeichnet das Interface, was in meinem Fall die VPN Verbindung ist. Der Gateway ist entweder mit "Auf Verbindung" bzw. 192.168.1.1 gekennzeichnet in der Übersicht (ist nur alles etwas verschoben)

Hier zeigt dir nur ein Traceroute (tracert bei Winblows) wo es wirklich hingeht. Führe mal ein tracert 192.168.3.254 aus und sehe dir den next Hop an. Da gehts dann auch hin !

Next Hop wird leider gar nicht angezeigt. Ich bekomme nur Zeitüberschreitungen

Das kommt dann noch dazu und legt den Verdacht nahe das du den Endgeräten im 192.168.1.0er Netz ein falsches Default Gateway definiert hast ! Das muss dann auch die 192.168.1.254 sein und nix anderes

Wenn wir mit den VPN-Clients ins Internet möchten, wäre Default-Gateway aber trotzdem die 192.168.1.254?
=> außerdem sollte die Verbindung zum 10.0.0.0/16 ja dann auch nicht gehen oder

Was hast du denn da überall für einen Mist konfiguriert im Gateway und Routing !!!??
Ja gar nix, scheinbar

Kann es sein, dass es etwas mit dem NAT zu tun hat?
Bitte warten ..
Mitglied: aqui
11.12.2018 um 14:52 Uhr
bezeichnet das Interface, was in meinem Fall die VPN Verbindung ist.
Ja, und das ist doch überall als Gateway angegeben !!
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.103
...ist z.B. die default Route und zeigt dahin !!
Ebenso das .1.0er Netz und auch das .3.0er...Eben ALLE Netze !
Next Hop wird leider gar nicht angezeigt.
Zeigt das dein rechner dann das next Hop gar nicht mehr erreichen kann oder wenn doch hat das next Hop Gateway keine (Rück) Route mehr zu deinem Rechner !
Wie gesagt...deutet alles auf einen falsch konfigurierten VPN Client oder Server.
Wenn wir mit den VPN-Clients ins Internet möchten, wäre Default-Gateway aber trotzdem die 192.168.3.254?
Nein !
Siehst du doch auch selber....!!!
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.103 zeigt ja nun mal ganz woanders hin als zur 3.254, oder ?!
Bitte warten ..
Mitglied: niLuxx
11.12.2018, aktualisiert um 14:59 Uhr
Ebenso das .1.0er Netz und auch das .3.0er...Eben ALLE Netze !

Stehe ich jetzt völlig auf dem Schlauch? Im Header steht doch:

Netzwerkziel | Netzwerkmaske | Gateway | Schnittstelle | Metrik
0.0.0.0 | 0.0.0.0 | 192.168.1.1 | 192.168.1.103 | 2

Netzwerkziel | 0.0.0.0
Netzwerkmaske | 0.0.0.0
Gateway | 192.168.1.1
Schnittstelle | 192.168.1.103
Metrik | 2

=> Mal davon angesehen, dass der Gateway dann trotzdem falsch ist... Aber warum kann ich auf die 10.0.0.0/16 Netze zugreifen?
Bitte warten ..
Mitglied: aqui
11.12.2018, aktualisiert um 18:42 Uhr
Sorry, stimmt. Tomaten auf den Augen gehabt... Grrr..
Also alles gut und richtig !
Das .3.0er Netz geht also auch an die 192.168.1.1. Dort (.1.1) sollte dann eine entsprechende Route ins 3er stehen...
Bitte warten ..
Mitglied: niLuxx
11.12.2018 um 15:54 Uhr
Genau...das würde jetzt sogar für mich Sinn machen
Problem ist, dass am 192.168.1.1 zwei statische Routen eingetragen sind:

1. 10.0.0.0 / 16 Gatway 192.168.1.254
2. 192.168.3.0 / 24 Gatway 192.168.1.254

Beides scheint identisch zu sein, aber das eine Subnetz geht, das andere nicht.
Ich denke ja wirklich die Ursache liegt in einer fehlerhaften NAT Einstellung

Asymmetric NAT rules matched for forward and reverse flows; Connection for icmp src outside:192.168.1.103(LOCAL\XXXXXX) dst internal:192.168.3.2 (type 8, code 0) denied due to NAT reverse path failure

Da gibt es bei Cisco was, leider verstehe ich das nicht
https://community.cisco.com/t5/firewalls/asymmetric-nat-rules-matched-fo ...
Bitte warten ..
Mitglied: aqui
11.12.2018, aktualisiert um 18:51 Uhr
Problem ist, dass am 192.168.1.1 zwei statische Routen eingetragen sind:
Wieso ist das ein "Problem" ??? Das muss doch so sein !
Die ganzen 10.0.x.x Netze und auch das 192.168.3.0er sollen doch zum Switch weil si ja am Switch geroutet werden !
Alles gut und richtig also...
die Ursache liegt in einer fehlerhaften NAT Einstellung
Wo denn ??
Du machst doch nirgendwo NAT !! Weder am Client noch am L3 Switch !! NAT spielt doch in deiner lokalen IP Connectivity da gar keine Rolle weil nirgendwo vorhanden zwischen deinen lokalen IP Netzen.
Es sei denn im VPN Tunnel wird irgendwo NAT gemacht und deine 10.0er und 192.168.3er IP Pakete gehen in den Tunnel, werden geNATet und sollen wieder zurück ohne Route dort. Würde dann aber auf ein fehlerhaftes VPN zeigen.

Warum nimmst du dir nicht erstmal einen Client ohne diesen VPN Mist und testest dein Routing mal wasserdicht aus !! Dein Routing ist doch ertsmnal rein nur lokal.
Prüfe das mit einem NICHT VPN Client aus allen Netzen aus und dann weisst du doch was los ist.
Ansonsten: Nimm dir einen Wireshark und checke WO deine Pakete abbleiben.
Bitte warten ..
Mitglied: niLuxx
11.12.2018, aktualisiert um 19:16 Uhr
Wieso ist das ein "Problem" ??? Das muss doch so sein !
=> Das war nur ein ironischer Witz (ein offenbar nicht so Guter)
=> Die Routen wären ja richtig eingestellt, das Problem ist, dass es funktionieren müsste tut es aber nicht...

Wo denn ??
Du machst doch nirgendwo NAT !

Oh doch. Wir haben eine FritzBox (DECT Telefonie) in einem Subnetz an dem I-Net Router. Die braucht NAT. Cisco hatte da einiges eingestellt, aber scheinbar nicht alles komplett korrekt.

Warum nimmst du dir nicht erstmal einen Client ohne diesen VPN Mist und testest dein Routing mal wasserdicht aus !!

Das habe ich schon. Zumindest von den internen SubNetzen aus. Am Internet-Router selbst habe ich leider keinen Client, den ich zum tracken nehmen könnte. Ich selbst verbinde mich auch nur über VPN mit den Systemen

Ansonsten: Nimm dir einen Wireshark und checke WO deine Pakete abbleiben.

Habe ich auch probiert, allerdings dann erfahren, dass ein Packet-Tracker nicht integriert ist. Wireshark kann wohl nur die Pakete sniffen, aber mir nicht sagen wo Pakete hängen bleiben würden.

Ich tippe immernoch auf eine NAT Fehlkonfig:
https://www.theroutingtable.com/asymmetric-nat-rules-matched-for-forward ...

Mein Fehler wird hier recht anschaulich beschrieben, allerdings muss ich mich da wohl erst durch die bestehenden Settings kämpfen...

Liebe Grüße
Bitte warten ..
Mitglied: aqui
LÖSUNG 11.12.2018 um 19:22 Uhr
Oh doch.
Nein, nicht wirklich !
Die FB NATet doch rfein nur das was ins Internet geht, also Richtung Provider.
Deine Netze sind doch alle nur lokale. Da gibt es in den Netzen keinerlei NAT. Das kannst du also knicken, das kann es nicht sein.
Am Internet-Router selbst habe ich leider keinen Client
Häng da einfach mal einen ran. Die FB hat ja 4 Ports dafür

Hast du denn mehrere Router ?? Vielleicht wäre es doch mal hilfreich du postest hier mal eine kleine Skizze wie das gesamte Netz aussieht aus L3 Sicht und wo NAT aktiv ist.
Oder entspricht es völlig der Zeichnung mit den 3 VLANs von oben ??
Bitte warten ..
Mitglied: niLuxx
12.12.2018 um 09:26 Uhr
Ja prinzipiell entspricht es das. Es gibt zwar noch andere Netze, aber die sind entweder nicht am Routing beteiligt, oder haben die gleiche Subnetzmaske (10.0.0.0/16).

Grüße,
niLuxx
Bitte warten ..
Mitglied: niLuxx
13.12.2018 um 06:17 Uhr
Nein nein, der geht zwar in die Richtung, wollte aber eigentlich nur mein NAT verstehen
Im Übrigen. Das Problem ist nun gelöst. Es ist tatsächlich eine fehlende NAT Regel gewesen.

Ich schätze diese NAT Regel hier (Anhang) macht einen automatischen NAT in Richtung Outside Interface. Kann sein, dass sich das mit dem VPN irgendwie beißt wenn da nichts explizit definiert wurde.
nat - Klicke auf das Bild, um es zu vergrößern
Bitte warten ..
Mitglied: aqui
15.12.2018 um 15:27 Uhr
Kann sein, dass sich das mit dem VPN irgendwie beißt
Das kann nicht nur sein, das ist auch so !
Logischerweise musst du IMMER den VPN Traffic von den NAT Regeln excluden.
Siehe auch hier:
https://administrator.de/wissen/cisco-880-890-router-konfiguration-adsl- ...

Aber gut wenn nun alles rennt wie es soll...
Case closed !
Bitte warten ..
Ähnliche Inhalte
Router & Routing
Standortübergreifendes Routing
Frage von flabsRouter & Routing2 Kommentare

Hallo zusammen, ich habe Frage zum Thema Standort übergreifendes Routing. An Standort A habe ich eine Pool an externen ...

LAN, WAN, Wireless
Anfängerfrage Routing
gelöst Frage von PharITLAN, WAN, Wireless10 Kommentare

Hallo allerseits, eine Frage, die ich mir nur mal interessehalber stelle: Die Telekom bietet hier einen Tarif mit 8 ...

Switche und Hubs
Routing Performance
Frage von geforce28Switche und Hubs6 Kommentare

Hallo Leute, aktuell nutzen wir ein Lancom 7100+ VPN Central Site Gateway für's Routing. Als "Coreswitch" haben wir ein ...

Router & Routing
Asynchrones Routing
gelöst Frage von ottokarlRouter & Routing2 Kommentare

Hallo, ich habe mittels der Anleitung von Thomas Krenn zwei default Gateways eingerichtet: Es funktioniert auch wunderbar. In der ...

Neue Wissensbeiträge
Humor (lol)
Administrator.de Perlen
Tipp von DerWindowsFreak2 vor 2 TagenHumor (lol)3 Kommentare

Hallo, Heute beim stöbern auf dieser Seite bin auf folgenden Thread aus dem Jahre 2006 gestossen: Was meint ihr? ...

Erkennung und -Abwehr
OpenSSH-Backdoor Malware erkennen
Tipp von Frank vor 3 TagenErkennung und -Abwehr

Sicherheitsforscher von Eset haben 21 Malware-Familien untersucht. Die Malware soll Hintertüren via OpenSSH bereitstellen, so dass Angreifer Fernzugriff auf ...

iOS
WatchChat für Whatsapp
Tipp von Criemo vor 6 TageniOS5 Kommentare

Ziemlich coole App für WhatsApp User in Verbindung mit der Apple Watch. Gibts für iOS sowohl als auch für ...

iOS
IOS hat nen Cursor!
Tipp von Criemo vor 6 TageniOS5 Kommentare

Nette Funktion im iOS. iPhone-Mauszeiger aktivieren „Nichts ist nerviger, als bei einem Tippfehler zu versuchen, den iOS-Cursor an die ...

Heiß diskutierte Inhalte
Grafikkarten & Monitore
PCIe 1.0 Grafikkarte für 3840x2160
Frage von Windows10GegnerGrafikkarten & Monitore29 Kommentare

Hallo, mein Vater hat einen neuen Monitor gekauft, welcher eine native Auflösung von 3840*2160 hat. Diese muss jetzt auch ...

Windows 10
Windows Enterprise 1809 Eval nicht bootbar
Frage von Sunny89Windows 1022 Kommentare

Hallo zusammen, bevor ich mich jetzt noch stundenlang rumärger wollte ich euch fragen, ob Ihr die gleichen Probleme habt ...

Windows Server
Dienstnamen und oder Deutsche und Englische Beschreibung in services.msc gleichzeitig anzeigen
gelöst Frage von vafk18Windows Server21 Kommentare

Guten Morgen, die Suche nach Diensten in services.msc gestaltet sich immer wieder schwierig, weil mir je nach Aufgabe die ...

Linux
Info Monitor für eine Schule
gelöst Frage von CAT404Linux13 Kommentare

Moin, ich möchte einen Infomonitor betreiben; derzeit läuft da ein Windows 10 Rechner bei dem Firefox beim Start in ...