Cisco hat Internet - Computer nicht
Hi allerseits,
im Stadium mit meinen "Cisco-Übungen" bin ich mal wieder an einem Punkt, wo ein Rat toll wäre.
Habe zwei Internetanschlüsse an meinem Cisco, die jetzt auch beide laufen. Das Problem ist nur, wenn ich alle meine Geräte über
ip route 0.0.0.0 0.0.0.0 dialer0
rausschicke, haben die kein Internet... Der Cisco selbst löst pings zu google.de bestens auf und pingt sie an, daher suche ich im NAT und access-lists. Richtig soweit?
sh ip route:
Regeln:
Access Lists:
VLAN, wo alle dran sind
Edit: Und natürlich der Dialer selbst, sorry:
Wäre toll, wenn mir jemand helfen könnte.
Viele Grüße,
PharIT
im Stadium mit meinen "Cisco-Übungen" bin ich mal wieder an einem Punkt, wo ein Rat toll wäre.
Habe zwei Internetanschlüsse an meinem Cisco, die jetzt auch beide laufen. Das Problem ist nur, wenn ich alle meine Geräte über
ip route 0.0.0.0 0.0.0.0 dialer0
rausschicke, haben die kein Internet... Der Cisco selbst löst pings zu google.de bestens auf und pingt sie an, daher suche ich im NAT und access-lists. Richtig soweit?
sh ip route:
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
S* 0.0.0.0/0 is directly connected, Dialer0
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.10.10.0/24 is directly connected, Vlan1
L 10.10.10.1/32 is directly connected, Vlan1
82.0.0.0/32 is subnetted, 1 subnets
ip dns server
ip nat inside source list 101 interface GigabitEthernet8 overload
ip nat inside source list 103 interface Dialer0 overload
access-list 101 permit ip 10.10.10.0 0.0.0.255 any
access-list 101 deny ip 10.10.10.0 0.0.0.255 192.168.88.0 0.0.0.255
access-list 103 permit ip 10.10.10.0 0.0.0.255 any
access-list 111 permit icmp any any administratively-prohibited
access-list 111 permit icmp any any echo-reply
access-list 111 permit icmp any any packet-too-big
access-list 111 permit icmp any any time-exceeded
access-list 111 permit icmp any any unreachable
access-list 111 permit udp any eq domain any
access-list 111 permit tcp any eq domain any
access-list 111 permit udp any eq 5060 any
access-list 111 permit udp any eq ntp any
access-list 111 permit udp any any eq isakmp
access-list 111 permit udp any any eq non500-isakmp
access-list 111 permit esp any any
VLAN, wo alle dran sind
interface Vlan1
description Lokales LAN
ip address 10.10.10.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
Edit: Und natürlich der Dialer selbst, sorry:
interface Dialer0
description xDSL Einwahl Interface
mtu 1492
ip address negotiated
ip access-group 111 in
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip inspect myfw out
ip virtual-reassembly in
encapsulation ppp
dialer pool 1
dialer-group 1
no keepalive
ppp chap hostname xx
ppp chap password 0 xx
ppp ipcp dns request
ppp ipcp mask request
no cdp enable
Viele Grüße,
PharIT
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 329497
Url: https://administrator.de/contentid/329497
Ausgedruckt am: 23.11.2024 um 23:11 Uhr
21 Kommentare
Neuester Kommentar
Es fehlt das wichtigste Kommando damit der Dialer überhaupt per PPPoE rauswählt !!!
dialer-list 1 protocol ip list 103
als Schrotschuss geht auch:
dialer-list 1 protocol ip permit
Besser ist aber die erste Version.
Ohne das kann nix gehen...
Was zum Troubleshooting wichtig ist:
sh ip route
sh ip int brie
Zum Testen von den Clients erstmal immer ne nackte IP versuchen (z.B. 8.8.8.8)
Das 2te Overload (NAT) Interface solltest du erstmal zum testen auf shutdown setzen.
Lesenswert:
Cisco Setup Tutorial:
Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
Oder auch dieser Thread dazu:
2921 sicher aufbauen für Internet
dialer-list 1 protocol ip list 103
als Schrotschuss geht auch:
dialer-list 1 protocol ip permit
Besser ist aber die erste Version.
Ohne das kann nix gehen...
Was zum Troubleshooting wichtig ist:
sh ip route
sh ip int brie
Zum Testen von den Clients erstmal immer ne nackte IP versuchen (z.B. 8.8.8.8)
Das 2te Overload (NAT) Interface solltest du erstmal zum testen auf shutdown setzen.
Lesenswert:
Cisco Setup Tutorial:
Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
Oder auch dieser Thread dazu:
2921 sicher aufbauen für Internet
Das ist normal, das ist einmal die Provider IP und die des PPPoE Tunnels am xDSL Anschluss.
Wie gesagt das kann nur noch was mit dem NAT und Routing zu tun haben. Du bist 3mm vor dem Ziel
Mmmhhh etwas komisch sieht deine Routing Tabelle schon aus... So sollte sie eingentlich aussehen:
C = Connected L = Local S = Static
Was auffällig ist das bei dir 2 wichtige Einträge fehlen:
Gateway of Last resort ist das Gateway an das der Cisco alles schickt was er sonst nicht los wird. Die Default Route.
Das müsste zu sehen sein, bei dir fehlt das aber...
Kann es sein das du beides, also ipcp def route im Dialer und die stat Route aktiv hast ??
Das solltest du besser erstmal vermeiden. Normal überbügelt die statische Route alles aber um sicherzugehen solltest du entweder oder machen.
Eleganter ist immer ipcp def route. Sonst das löschen und statische Route 0.0.0.0 oder andersrum.
Dann strategisch vorgehen.
Beispiel IPs hier von einer aktuell laufenden Kiste...musst dir deine denken !
interface Vlan1
description Lokales LAN
ip address 192.168.1.254 255.255.255.0
no ip proxy-arp
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1452
!
Dialer:
interface Dialer0
description Dialin DSL
ip address negotiated
ip access-group 111 in
no ip redirects
no ip unreachables
no ip proxy-arp
ip mtu 1492
ip nat outside
ip inspect myfw out
ip virtual-reassembly in
encapsulation ppp
dialer pool 1
dialer-group 1
no keepalive
ppp authentication pap callin
ppp pap sent-username xyz passwort geheim
ppp ipcp dns request
ppp ipcp mask request
ppp ipcp route default (---> Wenn konfiguriert KEINE def. Route !)
no cdp enable
NAT Overload (PAT):
ip nat inside source list 103 interface Dialer0 overload
access-list 103 permit ip 192.168.1.0 0.0.0.255 any
dialer-list 1 protocol ip list 103
Statische Default Route:
ip route 0.0.0.0 0.0.0.0 int dialer 0
(Nur konfigurieren wenn KEIN ppp ipcp route default im Dialer !!
Entweder oder..
Danach nochmal Check der Routing Tabel ob Last resort und "*" Route da ist ?
Client am lokalen LAN checken:
Mit ipconfig -all ob IP Adress passt zum lokalen LAN und die Cisco IP anpingbar ist
Wenn ja pinge mal die Provider IP bei dir die 82.135.16.28. Müsste auch gehen vom Client
Wenn ja muss auch ein Ping 8.8.8.8 gehen.
Noch ein wichtiger Test falls es immer noch nicht klappt dann schalte testweise mal die Firewall mit NO ip inspect myfw out auf dem Dialer Interface aus !
Keine Sorge passiert nichts, denn die NAT Firewall ist noch aktiv. Kann aber sein das du in der CBAC ACL noch einen Fehler hast und deshalb ICMP Echo Ping nicht durchgeht.
Ohne die FW am Dialer solle es sofort gehen. Wenn nicht dann nimm zusätzlich auch die inbound ACL 111 weg mit NO ip access-group 111 in
Spätestens dann sollte es aber klappen, denn dann hast du nichts mehr als deinen NAT Prozess dazwischen. Zum Testen ist das auch noch sicher..keine Sorge.
Wie gesagt das kann nur noch was mit dem NAT und Routing zu tun haben. Du bist 3mm vor dem Ziel
Mmmhhh etwas komisch sieht deine Routing Tabelle schon aus... So sollte sie eingentlich aussehen:
Gateway of last resort is 217.1.2.3 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 217.1.2.3
81.0.0.0/32 is subnetted, 1 subnets
C 81.1.2.3 is directly connected, Dialer0
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.16.1.0/24 is directly connected, Vlan10
L 172.16.1.254/32 is directly connected, Vlan10
192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.1.0/24 is directly connected, Vlan1
L 192.168.1.254/32 is directly connected, Vlan1
217.1.2.3/32 is subnetted, 1 subnets
C 217.1.2.3 is directly connected, Dialer0
Cisco#
Was auffällig ist das bei dir 2 wichtige Einträge fehlen:
- Gateway of last resort is 217.1.2.3 to network 0.0.0.0
- S* 0.0.0.0/0 [1/0] via 217.1.2.3
Gateway of Last resort ist das Gateway an das der Cisco alles schickt was er sonst nicht los wird. Die Default Route.
Das müsste zu sehen sein, bei dir fehlt das aber...
Kann es sein das du beides, also ipcp def route im Dialer und die stat Route aktiv hast ??
Das solltest du besser erstmal vermeiden. Normal überbügelt die statische Route alles aber um sicherzugehen solltest du entweder oder machen.
Eleganter ist immer ipcp def route. Sonst das löschen und statische Route 0.0.0.0 oder andersrum.
Dann strategisch vorgehen.
Beispiel IPs hier von einer aktuell laufenden Kiste...musst dir deine denken !
- Erstmal alle weiteren Internet Interfaces auf shutdown setzen ! Nur LAN und WAN aktiv
- Nochmals alle NAT relevanten Kommados querchecken minimal ist das nötig:
interface Vlan1
description Lokales LAN
ip address 192.168.1.254 255.255.255.0
no ip proxy-arp
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1452
!
Dialer:
interface Dialer0
description Dialin DSL
ip address negotiated
ip access-group 111 in
no ip redirects
no ip unreachables
no ip proxy-arp
ip mtu 1492
ip nat outside
ip inspect myfw out
ip virtual-reassembly in
encapsulation ppp
dialer pool 1
dialer-group 1
no keepalive
ppp authentication pap callin
ppp pap sent-username xyz passwort geheim
ppp ipcp dns request
ppp ipcp mask request
ppp ipcp route default (---> Wenn konfiguriert KEINE def. Route !)
no cdp enable
NAT Overload (PAT):
ip nat inside source list 103 interface Dialer0 overload
access-list 103 permit ip 192.168.1.0 0.0.0.255 any
dialer-list 1 protocol ip list 103
Statische Default Route:
ip route 0.0.0.0 0.0.0.0 int dialer 0
(Nur konfigurieren wenn KEIN ppp ipcp route default im Dialer !!
Entweder oder..
Danach nochmal Check der Routing Tabel ob Last resort und "*" Route da ist ?
Client am lokalen LAN checken:
Mit ipconfig -all ob IP Adress passt zum lokalen LAN und die Cisco IP anpingbar ist
Wenn ja pinge mal die Provider IP bei dir die 82.135.16.28. Müsste auch gehen vom Client
Wenn ja muss auch ein Ping 8.8.8.8 gehen.
Noch ein wichtiger Test falls es immer noch nicht klappt dann schalte testweise mal die Firewall mit NO ip inspect myfw out auf dem Dialer Interface aus !
Keine Sorge passiert nichts, denn die NAT Firewall ist noch aktiv. Kann aber sein das du in der CBAC ACL noch einen Fehler hast und deshalb ICMP Echo Ping nicht durchgeht.
Ohne die FW am Dialer solle es sofort gehen. Wenn nicht dann nimm zusätzlich auch die inbound ACL 111 weg mit NO ip access-group 111 in
Spätestens dann sollte es aber klappen, denn dann hast du nichts mehr als deinen NAT Prozess dazwischen. Zum Testen ist das auch noch sicher..keine Sorge.
Dein Dialer 0 oben ist auf shutdown !!!!
Da ist dann aber klar das gar nix geht !! 🧐
Mach ein sh ip in brie da siehst du immer den Status der Interfaces.
Das physische Interface und das dazu korrespondierende Dialer Interface dürfen NICHT auf shutdown sein.
Kannst du auch selber checken, denn wenn ein Ping ins Internet vom CLI Prompt klappt dann ist auch der Internet Anschluss aktiv ?
Zum Schluss noch die Kardinalsfrage: Kann es sein das evtl. auf dem Router kein IP Routing aktiviert ist ?
Bei einigen Modellen MUSS als Global Command dediziert ip routing eingegeben werden um das zu aktivieren !
Ansonsten fällt mir auch nicht mehr viel ein...außer einem Defekt was ich aber durch den funktionierenden Internet Port nicht wirklich glaube.
Im Zweifel mit write erase alles platt machen und nochmal ganz sauber von vorne anfangen und erstma ausschliesslich nur das DSL zum Fliegen bringen.
Da ist dann aber klar das gar nix geht !! 🧐
Mach ein sh ip in brie da siehst du immer den Status der Interfaces.
Das physische Interface und das dazu korrespondierende Dialer Interface dürfen NICHT auf shutdown sein.
Kannst du auch selber checken, denn wenn ein Ping ins Internet vom CLI Prompt klappt dann ist auch der Internet Anschluss aktiv ?
Zum Schluss noch die Kardinalsfrage: Kann es sein das evtl. auf dem Router kein IP Routing aktiviert ist ?
Bei einigen Modellen MUSS als Global Command dediziert ip routing eingegeben werden um das zu aktivieren !
Ansonsten fällt mir auch nicht mehr viel ein...außer einem Defekt was ich aber durch den funktionierenden Internet Port nicht wirklich glaube.
Im Zweifel mit write erase alles platt machen und nochmal ganz sauber von vorne anfangen und erstma ausschliesslich nur das DSL zum Fliegen bringen.
Das NAT auf beiden Interfaces sollte eigentlich nichts bewirken und sauber funktionieren:
Du kannst es an einem Cisco eigenen Beispiel sehen was exakt deinem entspricht, einmal PPPoE einmal DHCP:
http://www.cisco.com/c/en/us/support/docs/ip/network-address-translatio ...
Ich vermute das die dynamische Default Route Injizierung hier das eigentliche Problem ist. Das gilt sowohl für den PPPoE Dialin Port als auch für den Kabel TV Port mit DHCP.
Es ist wenigstens so das das nur auf einem Port geht. Der andere muss dan statisch oder mit einer PBR Policy Map konfiguriert werden.
Das o.a. Cisco Beispiel zeigt das wie es geht. Das ist zwar erstmal ein einfaches Failover entsprich aber ja exakt deinem Design mit einem PPPoE und einem DHCP Port beide per NAT ins Internet !
Du kannst es ja mal spaßeshalber so definieren. Erstmal so nackt nur NAT ohne Firewall und CBAC und das verifizieren. Das sollte so fehlerfrei laufen.
Du kannst es an einem Cisco eigenen Beispiel sehen was exakt deinem entspricht, einmal PPPoE einmal DHCP:
http://www.cisco.com/c/en/us/support/docs/ip/network-address-translatio ...
Ich vermute das die dynamische Default Route Injizierung hier das eigentliche Problem ist. Das gilt sowohl für den PPPoE Dialin Port als auch für den Kabel TV Port mit DHCP.
Es ist wenigstens so das das nur auf einem Port geht. Der andere muss dan statisch oder mit einer PBR Policy Map konfiguriert werden.
Das o.a. Cisco Beispiel zeigt das wie es geht. Das ist zwar erstmal ein einfaches Failover entsprich aber ja exakt deinem Design mit einem PPPoE und einem DHCP Port beide per NAT ins Internet !
Du kannst es ja mal spaßeshalber so definieren. Erstmal so nackt nur NAT ohne Firewall und CBAC und das verifizieren. Das sollte so fehlerfrei laufen.
Was genau meinst du mit "den nächsten Hop irgendwo definieren" ??
Der nächste Hop nach dem Privider ist ein interner Provider Router. Dahin hast du ja keinerlei Einfluss.
Oder meinst du deinen beiden statischen Routen im Cisco ?
Hier geht es nach Reihenfolge wenn du 2 Default Routen hast. Irgendwie musst du dem Router ja sagen welche gelten soll sonst verwirrst du ihn
2 Default Routen kann es ja nicht geben.
Du kannst eine Metrik am Ende der Route vergeben, dann zieht er die eine oder die andere vor. Nutzen tut er aber immer nur eine...klar.
Wenn du beide aktiv nutzen willst musst du mit einer Route Map den Traffic klassifizieren der über den einen oder den anderen Links soll mit Backup.
Hier findest du ein Beispiel:
Cisco Router 2 Gateways für verschiedene Clients
Der nächste Hop nach dem Privider ist ein interner Provider Router. Dahin hast du ja keinerlei Einfluss.
Oder meinst du deinen beiden statischen Routen im Cisco ?
Hier geht es nach Reihenfolge wenn du 2 Default Routen hast. Irgendwie musst du dem Router ja sagen welche gelten soll sonst verwirrst du ihn
2 Default Routen kann es ja nicht geben.
Du kannst eine Metrik am Ende der Route vergeben, dann zieht er die eine oder die andere vor. Nutzen tut er aber immer nur eine...klar.
Wenn du beide aktiv nutzen willst musst du mit einer Route Map den Traffic klassifizieren der über den einen oder den anderen Links soll mit Backup.
Hier findest du ein Beispiel:
Cisco Router 2 Gateways für verschiedene Clients
Was bewirkt eigentlich permit 10? Sollte das eine irgendwo definierte ACL sein?
Nein, das ist nur rein eine Index Nummer.Du kannst mehrere permit oder deny Statements in solche Route Map einbauen und mit der Index Nummerierung 10, 20 30...usw. oder 1, 2, 3 usw. bestimmst du die Reihenfolge
Dein grundlegender Fehler ist vermutlich das du wieder "ppp ipcp route default" benutzt im Dialer. Das bewirkt das damit eine Default Route in die Routing Tabelle zwangsweise injiziert wird.
Wenn du also mit einer Route Map arbeitest wie im Cisco Beispiel dann ist es auf alle Fälle ratsam NICHT mit diesen Automatismen zu arbeiten, sprich "ppp ipcp route default" entfernen und das mit einer statischen Router zu machen.
Das entspricht ja auch genau deinem Verhalten das dann nur noch der Dialer Link arbeitet ins Internet. Verifiziert das das autom. Injizieren der PPPoE Route höchste Prio hat.
Das Cisco Route Map Beispiel ist ja erstmal nur ein Failover Beispiel aber das ist ja erstmal egal für den Test.
Das sollte in jedem Falle so umsetztbar sein.
Außerdem ist deinen Route Map auch noch falsch !
route-map m-net permit 10
set ip next-hop 82.135.16.28
set interface FastEthernet0
!
Das Ziel Interface ist niemals das physische sondern immer der Dialer !!! Alles was via PPPoE Provider geht ist IMMER auf das Dialer Interface bezogen. Das hält die Provider IP ! Das musst du korrigieren.
Später kannst du ja die Route Map erweitern und in der Routemap mit einer ACL mal Traffic klassifizieren den du dann mit einer unterschiedlichen Gateway IP in der einen und anderen Route Map dann mal via Kabel TV und PPPoE Anschluss schickst. Das klappt in jedem Falle.
Wenn du die 2 Dinge korrigierst muss es eigentlich klappen.
Mit show ip nat translation kannst du immer sehen welcher Traffic über welchen Anschluss geht.
Mir ist gerade aufgefallen, dass der Router selbst ja garnicht rauspingt.
Hier besteht die Gefahr das du die falsche Absender IP nimmst. Wenn du keinen extended Ping machst kannst du die Absender IP nicht bestimmen und der Router nimmt die niedrigste IP.Mach einen extend Ping mit ping <return> und gibt menügeführt alles an. Bei der Frage extended commands antwortest du mit Ja und gibst deine Absender IP oder Interface an. Alles andere mit Default bestätigen.
Damit kannst du die Adressen genau bestimmen.
Kann mir jemand sagen, wie ich dem Cisco Router noch sagen kann, dass er beide Anschlüsse nutzen kann?
Beide Anschlüsse sind ja online und aktiv. Mit einem extended Ping müsstest du über beide Provider Links pingen können.Der Router oder ein Router allgemein kann nur anhand seiner Routing Tabelle entscheiden wo was hinsoll.
Machst du nix gilt die Default Route z.B. über Provider 1 und immer nur die .
Provider 2 dümpelt dann rum solange bis Provider 1 ausfällt. Siehe deine Konfig.
Wenn du jetzt beide Links benutzen willst musst du erstmal klassifizieren was zum anderen Provider soll.
Das machst du mit der ACL in der Route Map.
Dort steht dann z.B. permit ip <lokales_netz> host 8.8.8.8 next hop <ip_provider2>
Das würde z.B. jeglichen Traffic dann zum Host 8.8.8.8 via Provider 2 senden. Oder
permit ip <lokales_netz> any eq http next hop <ip_provider2>
Sende allen HTTP Trafic via Provider 2.
So kannst du genau customizen was über 1 oder 2 gehen soll.
Wenn du ein Session basiertes Load Balancing willst findest du hier ein Beispiel zum Abtippen:
http://www.cisco.com/c/en/us/support/docs/ip/network-address-translatio ...
https://supportforums.cisco.com/discussion/11710646/dual-isp-connection- ...
Sorry für diese Amateurfragen...
Locker bleiben...dafür ist ein Forum ja da !Wenn ich den Dialer0 overload entferne
Das wäre tödlich, denn damit schlatest du NAT aus, das IP Adresstranslation !Damit gehen deine privaten RFC 1918 IP Adressen dann ins Internet und direkt ins Nirwana weil der Provider sie am Eingang filtert und gleich wegschmeisst.
ist er auch von außen wieder erreichbar. Spricht für richtige ACLs, denke ich.
Klar, denn dann greift die NAT Firewall nicht mehr !Ist die Router-IP selbst denn nicht Bestandteil vom VLAN1
Ja, natürlich da sist sie.Der Router hat ja aber mehrere IPs bzw. kennt immer mehrere IP Netze, die alle Bestandteil der Router IP sind wenn du so willst.
Das Dialer Interface hat ne IP usw. "Die" Router IP gibts ja deshalb gar nicht oder wie meintest du das jetzt ?
Oder muss ich Traffic, der von außen reinkommt, nochmals irgendwo angeben? Bzw. die ACL reinlassen?
Ahem...jaaa !Die ACL 111 regelt ja was von außen reindarf durch die Firewall. Hier hast du zB. die Einträge:
access-list 111 permit udp any any eq isakmp
access-list 111 permit udp any any eq non500-isakmp
access-list 111 permit esp any any
Die erlauben von any (also von jeglicher Absender IP im Internet) IPsec Protokollkomponenten (UDP 500, 4500 und ESP) Zugriff auf die Router IP und zwar die des Dialers.
Das als Ziel any angegeben ist beruht auf der Tatsache das im PPPoE DSL du wechselnde IPs hast.
Wenn du z.B. immer eine feste Internet IP mit 84.1.1.10 von deinem Provider bekommst oder zugeteilt hast dann kannst du die ACL natürlich auch dichter ziehen:
access-list 111 permit udp any host 84.1.1.10 eq isakmp
access-list 111 permit udp any host 84.1.1.10 eq non500-isakmp
access-list 111 permit esp any host 84.1.1.10
Jetzt dürfen nur noch die Protokollkomponenten IPsec mit der Ziel IP 84.1.1.10 dort passieren.
Willst du Webzugriff auf den Router erlauben (was du hoffentlich nie machst!) dann sähe das so aus:
access-list 111 permit tcp any any eq www oder mit IP dann entsprechend:
access-list 111 permit tcp any host 84.1.1.10 eq www
Hier musst du also alles bestimmen was passieren darf auf die Router IP.
Ein deny any any log schaltet übrigens immer ein Logging für die ACL ein ! Damit kannst du dann immer sehen mit sh logg WAS nicht passieren durfte und was die ACL geblockt hat.
Pfiffiger Workaround um ACLs zu troubleshooten
Im Produktivbetrieb sollte man das aber bei heftig frequentierten ACls lassen, da es sehr CPU intensiv ist.
Bei den Internet ACLs hast du Port Scan und Angriffe im Sekundentakt.
Wenn du Port Forwarding machen willst vom Internet direkt ins interne LAN, dann ist das wieder eine andere Geschichte. Das geht dann über statisches NAT.
Ein gutes Buch ist auch:
https://www.amazon.de/Network-Warrior-Gary-Donahue/dp/1449387861/ref=sr_ ...
Nochmal zur Klarstellung:
Wenn du die Erzwingung der Default Route via IPCP entfernst kann der die konfigurierten Routen nicht mehr "übermangeln" !
Du musst dann 2 statische Routen einrichten:
ip route 0.0.0.0 0.0.0.0 109.125.67.193
ip route 0.0.0.0 0.0.0.0 dialer0
Da es ja jetzt KEIN Kommando ppp ipcp route default mehr auf dem Dialer0 gibt, ignoriert der Router die Default Route von dort und nimmt nur das was ihm statisch konfiguriert ist.
Ein sh ip route zeigt dir das dann auch.
Bei 2 statischen default Routen mit gleicher Metrik macht der Router automatisch ein Session basiertes Round Robin also ein Balancing über beide Leitungen anhand der Ziel IP Adressen.
Per Default nutzt er also aktiv beide Links.
Wenn du das nicht willst und bestimmte UDP oder TCPDienste oder Absender IPs über dedizierte Links schicken willst musst du mit einer route-map, ACL und entsprechendem Next Hop Gateway arbeiten.
Du kannst auch z.B. eine der Routen in der Metrik herabsetzen:
ip route 0.0.0.0 0.0.0.0 109.125.67.193 metric 100
ip route 0.0.0.0 0.0.0.0 dialer0
(Höhere Metrik = Schlechter)
So würde alles über den Dialer gehen. Erst wenn der weg ist (down Status) geht das über die andere Route.
Das Cisco Backup Beispiel nennt das so. Dort sogar noch verbunden mit einem Tracking was das Failover Verhalten natürlich verbessert !
Eigentlich ist das alles in allem ein einfach nachzuvollziehendes Verhalten.
Wenn du die Erzwingung der Default Route via IPCP entfernst kann der die konfigurierten Routen nicht mehr "übermangeln" !
Du musst dann 2 statische Routen einrichten:
ip route 0.0.0.0 0.0.0.0 109.125.67.193
ip route 0.0.0.0 0.0.0.0 dialer0
Da es ja jetzt KEIN Kommando ppp ipcp route default mehr auf dem Dialer0 gibt, ignoriert der Router die Default Route von dort und nimmt nur das was ihm statisch konfiguriert ist.
Ein sh ip route zeigt dir das dann auch.
Bei 2 statischen default Routen mit gleicher Metrik macht der Router automatisch ein Session basiertes Round Robin also ein Balancing über beide Leitungen anhand der Ziel IP Adressen.
Per Default nutzt er also aktiv beide Links.
Wenn du das nicht willst und bestimmte UDP oder TCPDienste oder Absender IPs über dedizierte Links schicken willst musst du mit einer route-map, ACL und entsprechendem Next Hop Gateway arbeiten.
Du kannst auch z.B. eine der Routen in der Metrik herabsetzen:
ip route 0.0.0.0 0.0.0.0 109.125.67.193 metric 100
ip route 0.0.0.0 0.0.0.0 dialer0
(Höhere Metrik = Schlechter)
So würde alles über den Dialer gehen. Erst wenn der weg ist (down Status) geht das über die andere Route.
Das Cisco Backup Beispiel nennt das so. Dort sogar noch verbunden mit einem Tracking was das Failover Verhalten natürlich verbessert !
Eigentlich ist das alles in allem ein einfach nachzuvollziehendes Verhalten.