136423
Dec 07, 2018, updated at 09:01:39 (UTC)
1842
40
0
Verständnisproblem Routing - Anfängerfrage
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
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
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 395014
Url: https://administrator.de/contentid/395014
Printed on: April 16, 2024 at 23:04 o'clock
40 Comments
Latest comment
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.
E.
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)=> 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?
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.=> Wie ist das möglich wenn ich VLANs-konfiguriert habe und alle Verbindungen (B.1) eigentlich an die 192.168.1.1. gehen sollten?
E.
Zitat von @136423:
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"
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
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
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
Zitat von @136423:
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)" ?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)" ?
Als Ersatz
Dein Design ist ein klassisches VLAN Design mit einem Internet Transfernetz zum Router und sieht genau so aus, richtig ??
Das ist ein Standard Design und die genauen Setups dazu beschreibt dieser Thread:
Verständnissproblem Routing mit 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
) Problem ?? 
Verständnissproblem Routing mit 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
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
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
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
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
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...
Ich befürchte das ist es nicht
show access-list zeigt:
No ACLs are defined (am Switch)
show access-list zeigt:
No ACLs are defined (am Switch)
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.
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.
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
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 !
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
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
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
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
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 ??
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 ??
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?
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?
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.
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.
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?
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 !!
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 !!
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.)?
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.)?
Zitat von @136423:
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.)?
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
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...
Vielleicht ist es auch so eine komische Sache, dass nach Änderung von statischen Routen der VPN Adapter neu gestartet werden muss oder so etwas...
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 ???
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
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
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 !
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 !
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
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
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
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
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 !!
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?
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 ?!
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?
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...
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...
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
Da gibt es bei Cisco was, leider verstehe ich das nicht
https://community.cisco.com/t5/firewalls/asymmetric-nat-rules-matched-fo ...
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 ...
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.
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 !
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
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 ??
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
Grüße,
niLuxx
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.
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.
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:
Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
Aber gut wenn nun alles rennt wie es soll...
Case closed !
