pharit
Goto Top

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:
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
Regeln:
ip dns server
ip nat inside source list 101 interface GigabitEthernet8 overload
ip nat inside source list 103 interface Dialer0 overload
Access Lists:
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
Wäre toll, wenn mir jemand helfen könnte.


Viele Grüße,

PharIT

Content-ID: 329497

Url: https://administrator.de/forum/cisco-hat-internet-computer-nicht-329497.html

Ausgedruckt am: 27.12.2024 um 12:12 Uhr

aqui
aqui 15.02.2017, aktualisiert am 04.12.2023 um 16:09:59 Uhr
Goto Top
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
PharIT
PharIT 15.02.2017 aktualisiert um 15:54:09 Uhr
Goto Top
Hi Aqui,

ist ja kaum zu glauben, wem Du noch alles nebenher hilfst face-smile


Leider habe ich nicht das Problem aus dem anderen Thread. Wenn ich über mein anderes Interface (GigabitEthernet8) reingehe, läuft ja alles. Das heißt mein VLAN1 macht das ip nat inside korrekt. Der Ping läuft perfekt durch zu 8.8.8.8 und auch trace zeigt die Stationen über M-Net, wo mein PPPoe läuft (das andere, was schon geht, ist Kabel)

Das hier ist meine Config, wenn ich das Internet über 0.0.0.0 0.0.0.0 dialer0 erzwinge:
(wenn ich über 0.0.0.0 0.0.0.0 xxx.xxx.xxx.xxx <- fixe IP von Kabel gehe, dann läuft es bestens...)

Mein sh ip route sieht doch so gut aus, oder?
 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
C        82.135.16.28 is directly connected, Dialer0
      93.0.0.0/32 is subnetted, 1 subnets
C        93.104.143.96 is directly connected, Dialer0

sh ip int brief zeigt mir das hier
Dialer0                    93.104.143.96   YES IPCP   up                    up  

Hast Du noch irgendeine Idee? Wäre super.

Viele Grüße,

PharIT
PharIT
PharIT 15.02.2017 um 15:57:25 Uhr
Goto Top
Da fällt mir auf, hat mein Dialer zwei IP-Adressen???
aqui
aqui 15.02.2017 aktualisiert um 17:28:27 Uhr
Goto Top
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 face-wink
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# 
C = Connected L = Local S = Static
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
Der letzte Routing Eintrag mit dem "*" ist die Default Route, der Stern kennzeichnet diese. Die fehlt irgendwie.
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... face-sad

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:
Lokales LAN Interface:
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.
PharIT
PharIT 15.02.2017 um 18:17:24 Uhr
Goto Top
Hi Aqui,

tausend Dank Dir für die Hilfe, leider noch immer nichts... face-sad face-sad
Hatte auch alle Lists mal aus, ebenso die Firewall. Könntest Du vielleicht nochmals einen Blick darauf werfen?
Zumindest die Routing-Tabelle entspricht nun Deinen Vorstellungen: (Nur weiß ich nicht, ob dort meine IP an der richtigen Stelle steht (die 9xx):
Gateway of last resort is 8x.xx.xx.xx to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 8x.xx.xx.xx
      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
C        82.135.16.28 is directly connected, Dialer0
      93.0.0.0/32 is subnetted, 1 subnets
C        9xx.xx.xx is directly connected, Dialer0
VLAN:
interface Vlan1
 description Lokales LAN
 ip address 10.10.10.1 255.255.255.0
 ip nat inside
 ip virtual-reassembly in
 ip tcp adjust-mss 1452
Dialer stimmt auch, oder?
interface Dialer0
 description xDSL Einwahl Interface
 mtu 1492
 ip address negotiated
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ----------------->ip nat outside<----------------
 ip virtual-reassembly in
 encapsulation ppp
 shutdown
 dialer pool 1
 dialer-group 1
 no keepalive
 ppp authentication chap callin
 ppp chap hostname xx@mdsl.mnet-online.de
 ppp chap password 0 xx
 ppp ipcp dns request
 ppp ipcp mask request
 ppp ipcp route default
 no cdp enable
!
Routes
ip dns server
ip nat inside source list 101 interface GigabitEthernet8 overload
ip nat inside source list 103 interface Dialer0 overload
ip route 0.0.0.0 0.0.0.0 109.125.67.193
ip ssh time-out 60
ip ssh authentication-retries 2
Access-Lists:
dialer-list 1 protocol ip list 103
!
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
aqui
aqui 15.02.2017, aktualisiert am 04.12.2023 um 16:11:03 Uhr
Goto Top
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.
PharIT
PharIT 15.02.2017 um 22:18:43 Uhr
Goto Top
HI Aqui,

habe ich nun erledigt und die ganze Config nur mit PPPoe aufgebaut -hat bestens funktioniert nach Deinen ganzen Hilfestellungen. Tausend Dank für Deine Hilfe und Geduld!

Nun ist es so, dass wenn ich meinen zweiten Internetzugang via Kabel "einschalte" (no sh) und die Route darüber erzwinge, läuft auch alles. Schalte ich den GigabitEthernet8 aber wieder aus, funktioniert mein Dialer-Internet hier am Rechner erst wieder wenn ich:
no ip nat inside source list 101 interface GigabitEthernet8 overload
eingebe und es somit entferne.


Weißt Du, wie ich nun weiter machen kann, wenn ich meine beiden Internetanschlüsse ordentlich nutzen will? Ich würde gerne den VPN über beide IPs erreichen wollen, da ich gemerkt habe, dass M-Net mir unabsichtlich eine feste IP per DHCP vergibt.


Viele Grüße,

PharIT
PharIT
PharIT 15.02.2017 um 22:33:04 Uhr
Goto Top
Und wie kann ich dann einen "intelligenten" Lastenausgleich aus Beiden erzeugen? Im Moment scheinen sie ja noch zu konkurrieren...
aqui
aqui 16.02.2017 um 09:48:35 Uhr
Goto Top
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.
PharIT
PharIT 17.02.2017 aktualisiert um 23:10:13 Uhr
Goto Top
Hi Aqui,

vielen Dank Dir! Nach dem ausgiebigen Studium des Beitrags hänge ich noch an einer Sache.

Da auch mein Kabelanbieter mir eine fixe IP gegeben hat, und es hier etwas umständlich geregelt ist, habe ich per

ip route 0.0.0.0 0.0.0.0 109.xx.xx.xx

den nächsten Hop definiert, während das GigabitEthernet8 Kabel-WAN-Interface meine statische IP trägt. Es wird dann ja aber alles über den next hop geschickt, sobald der steht. Kann ich den nächsten Hop irgendwo definieren, wo es nur den Internetaufbau von meinem GigabitEthernet8 beeinflusst, sodass ich den Lastenausgleich aufsetzen kann?

Und da ich ja kein DHCP dann habe, wie ändert sich der folgende Config-Eintrag aus Deinem Beispiel?

ip nat inside source route-map dhcp-nat interface GigabitEthernet8 overload


Wäre super, wenn Du mir dazu eine Antwort hättest face-wink


Viele Grüße,

PharIT
aqui
aqui 18.02.2017 um 19:21:50 Uhr
Goto Top
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 face-smile
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
PharIT
PharIT 19.02.2017 um 14:07:08 Uhr
Goto Top
Hi Aqui,

Vielen Dank! Habe es probiert, wie in dem Thread -kommt aber nicht zum Fliegen face-sad Könntest Du mal schauen?

Mein GigEth8 Interface bekommt eine feste IP, ich sollte aber den hächsten Hop laut meinem Netzbetreiber kommunizieren (bisher tat ich das über ip route 0.0.0.0 0.0.0.0 nexthopip) jetzt würde das aber ja meinen PPPoe Anschluss dann gesamt ignorieren. FastEth hält den PPPoe

Was bewirkt eigentlich permit 10? Sollte das eine irgendwo definierte ACL sein?

Wenn ich in der Konfig unten jetzt mein GigEth8 via ip nat inside source list 101 interface GigabitEthernet8 overload "freischalte" steht der Verkehr. Hab beide sh ip route unten mal angefügt.


interface FastEthernet0
no ip address
duplex auto
speed auto
pppoe enable group global
pppoe-client dial-pool-number 1
!
interface GigabitEthernet8
description Internet Port Kabelmodem
ip address xx.xx.xx.xx 255.255.255.192
ip access-group 111 in
ip nat outside
ip inspect myfw out
ip virtual-reassembly in
duplex auto
speed auto
!
!
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 xxx@xxx.de
ppp chap password 0 xx
ppp ipcp dns request
ppp ipcp mask request
ppp ipcp route default
no cdp enable
!
!
ip dns server
ip nat inside source list 103 interface Dialer0 overload
ip nat inside source route-map cable interface GigabitEthernet8 overload
ip nat inside source route-map mnet interface FastEthernet0 overload
ip ssh time-out 60
ip ssh authentication-retries 2
!
ip access-list extended vpndynmt
permit ip 10.10.10.0 0.0.0.255 192.168.88.0 0.0.0.255
!
dialer-list 1 protocol ip list 103
!
route-map m-net permit 10
set ip next-hop 82.135.16.28
set interface FastEthernet0
!
route-map cable permit 10
match ip address 10
set ip next-hop 109.125.67.193
set interface GigabitEthernet8
!
access-list 101 permit ip 10.10.10.0 0.0.0.255 any
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

sh ip route nur Dialer:
Gateway of last resort is 8x.xx.xx.xx to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 82.135.16.28
      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
C        82.135.16.28 is directly connected, Dialer0
      88.0.0.0/32 is subnetted, 1 subnets
C        88.xx.xx.xx is directly connected, Dialer0
      109.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        109.xx.xx.xx/26 is directly connected, GigabitEthernet8
L        109.xx.xx.xx/32 is directly connected, GigabitEthernet8

mit GigEth8 funktioniert es nur noch, wenn ich den Dialer komplett ausschalte und alles über ip route zum next-hop erzwinge.

Hast Du vielleicht eine Idee, was falsch ist?


Viele Grüße,

PharIT
aqui
aqui 20.02.2017 um 09:02:30 Uhr
Goto Top
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 face-wink

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.
PharIT
PharIT 20.02.2017 um 21:39:12 Uhr
Goto Top
Vielen vielen Dank, Aqui!!!

Bisher habe ich alles korrigiert und wie hier zu sehen, die Route Map des Cable Anschlusses schon zum Laufen bekommen!

Nur habe ich ein Problem, ich glaube die Access-Lists greifen nicht mehr, da mein VPN nicht mehr geht... Weißt Du, ob ich den noch irgendwo "freischalten" muss?

interface GigabitEthernet8
 description Internet Port Kabelmodem
 ip address 1xx.xx.xx 255.255.255.192
 ip access-group 111 in
 ip nat outside
 ip inspect myfw out
 ip virtual-reassembly in
 duplex auto
 speed auto
!
!
!
interface Vlan1
 description Lokales LAN
 ip address 10.10.10.1 255.255.255.0
 ip nat inside
 ip virtual-reassembly in
 ip policy route-map cable
!
!
!
ip nat inside source list 101 interface GigabitEthernet8 overload
ip nat inside source list 103 interface Dialer0 overload
ip nat inside source route-map cable interface GigabitEthernet8 overload
ip nat inside source route-map m-net interface Dialer0 overload
!
!
!
route-map cable permit 1
 match ip address 101
 set ip next-hop 109.125.67.193
 set interface GigabitEthernet8
!
!
!
access-list 101 permit ip 10.10.10.0 0.0.0.255 any
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
PharIT
PharIT 20.02.2017 um 21:50:12 Uhr
Goto Top
Mir ist gerade aufgefallen, dass der Router selbst ja garnicht rauspingt.

Mein VLAN hat ja nun die richtige Route via route-map. Kann mir jemand sagen, wie ich dem Cisco Router noch sagen kann, dass er beide Anschlüsse nutzen kann?


Viele Grüße,

PharIT
aqui
aqui 21.02.2017 aktualisiert um 14:23:17 Uhr
Goto Top
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- ...
PharIT
PharIT 21.02.2017 um 14:26:13 Uhr
Goto Top
Tausend Dank Aqui! Mache mich direkt mal ans Werk!

Hättest Du vielleicht für den Nichtsahnenden noch eine Idee, warum der VPN nicht mehr gehen könnte, bzw die Access-Lists nicht greifen?


Viele Grüße,

PharIT
aqui
aqui 21.02.2017 um 14:43:03 Uhr
Goto Top
warum der VPN nicht mehr gehen könnte, bzw die Access-Lists nicht greifen?
Ohne Logauszug wird das ne Raterei.
Du musst erstmal klären ob es das VPN selber ist oder ne ACL dir da einen Streich spielt.
PharIT
PharIT 21.02.2017, aktualisiert am 22.02.2017 um 08:32:25 Uhr
Goto Top
Hallo Aqui,

vielen Dank Dir mal wieder für die Antwort und Hilfestellung und besonders die Tutorials, die ich in einem Folgeschritt in Angriff nehmen werde! Also von intern funktioniert der VPN perfekt.

Ich denke mir fehlen einfach absolut die Routing Grundlagen, die ich mir hiermit erarbeiten will face-sad Sorry für diese Amateurfragen...


Wenn ich den Dialer0 overload entferne und ip route 0.0.0.0 0.0.0.0 109.125.67.293 eingebe, ist er auch von außen wieder erreichbar. Spricht für richtige ACLs, denke ich.


Ist die Router-IP selbst denn nicht Bestandteil vom VLAN1? Da hätte ich ja die Route Map ordentlich drauf... Jedenfalls kommt mit meinem Routing von da oben nix mehr rein. Oder muss ich Traffic, der von außen reinkommt, nochmals irgendwo angeben? Bzw. die ACL reinlassen?

Habe mir gerade das CCNA Routing Buch besorgt, vielleicht ist das ein Ausblick face-smile
aqui
aqui 22.02.2017 aktualisiert um 13:04:21 Uhr
Goto Top
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 face-wink
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. face-sad

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_ ...
aqui
aqui 24.02.2017 aktualisiert um 13:46:07 Uhr
Goto Top
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.