Cisco 2800 NAT funktioniert nicht nach Wechsel von 1800

Hallo miteinander,

ich habe ein seltsames Problem mit einem unserer Standortrouter. Kurze Vorgeschichte:

Vor ca. 1 Jahr musste ich einen Cisco 2800 Router in einem unserer Standorte wegen eines defekten RAM-Moduls gegen einen Cisco 1800 Router austauschen. Im gleichen Atemzug wurde der Standort (wie alle anderen auch) gleich über DMVPN / OSPF mit den anderen Niederlassunge miteinander verbunden.
Da vor Ort eine spezielle Kundensoftware ohne Proxy-Support eingesetzt wird, wurden NAT Regeln angelegt, die den Zugriff aller internen Rechner des Standorts auf eine spezielle, fixe IP des Kunden zulässt. Das hat soweit auch funktioniert.

Nachfolgend einmal der Auszug aus der funktionierenden Konfiguration:

- FastEthernet0/0 : angeschlossen an DSL Modem (SDSL)
- Dialer1 : Einwahlinterface DSL
- VLan1 : Virtuelles LAN Interface des Routers (10.67.110.1)
- Netzwerk-ID : 10.67.0.0 / 255.255.0.0
- IP Adresse des Kunden: 123.123.123.123

!
vpdn enable
!
vpdn-group 1
request-dialin
protocol pppoe
!
interface FastEthernet0/0
no ip address
ip access-group OUTSIDE in
duplex auto
speed auto
pppoe enable group global
pppoe-client dial-pool-number 1
!
interface Vlan1
ip address 10.67.110.1 255.255.0.0
ip nat inside
ip virtual-reassembly
ip tcp adjust-mss 1360
h323-gateway voip bind srcaddr 10.67.110.1
!
interface Dialer1
ip address negotiated
ip access-group OUTSIDE in
ip mtu 1492
ip nat outside
ip virtual-reassembly
encapsulation ppp
dialer pool 1
dialer-group 1
ppp authentication chap pap callin
ppp chap hostname feste-ip8/0123456789@t-online-com.de
ppp chap password 0 9876543210
ppp pap sent-username feste-ip8/0123456789@t-online-com.de password 0 9876543210
!
ip nat inside source list NATOUT interface Dialer1 overload
!
ip access-list extended NATOUT
permit ip 10.67.0.0 0.0.255.255 host 123.123.123.123
!
ip access-list extended OUTSIDE
permit esp any any
permit udp any any eq isakmp
permit icmp any any
permit udp any any eq non500-isakmp
permit ip host 123.123.123.123 any
!
dialer-list 1 protocol ip permit
!

Diese Konfiguration funktioniert. Die Tunnel werden aufgebaut. Alles soweit klappt. Auch das Kundenprogramm kann direkt über den Standardgateway der Clients (das ist der Router vor Ort) zur angegebenen IP connecten.

###

Nun habe ich den urpsrünglich dort im Einsatz befindlichen Cisco 2800 Router wieder aufbauen wollen. Dazu habe ich die Konfiguration weitgehend übernommen. Der 2800 hat im Gegensatz zum 1800er kein Vlan1 Interface als internes Interface. Hierzu habe ich dann einfach das FastEthernet0/1 verwendet. Am 0/0 ist das DSL Modem.
Nach dem Hochfahren funktioniert das Wichtigste sofort. SDSL Verbindung wird aufgebaut, Tunnel zu den Standorten stehen ebenfalls. Telefonie funktioniert. Doch die NAT Freigabe funtkioniert nicht. Die Konfiguration sieht folgendermaßen aus:

!
vpdn enable
!
vpdn-group 1
request-dialin
protocol pppoe
l2tp tunnel receive-window 1024
!
bba-group pppoe global
!
interface FastEthernet0/0
no ip address
ip access-group OUTSIDE in
duplex auto
speed auto
pppoe enable group global
pppoe-client dial-pool-number 1
!
interface FastEthernet0/1
ip address 10.67.110.1 255.255.0.0
ip nat inside
ip virtual-reassembly
ip tcp adjust-mss 1360
duplex auto
speed auto
h323-gateway voip bind srcaddr 10.67.110.1
!
interface Dialer1
ip address negotiated
ip access-group OUTSIDE in
ip mtu 1492
ip nat outside
ip virtual-reassembly
encapsulation ppp
dialer pool 1
dialer-group 1
ppp authentication chap pap callin
ppp chap hostname feste-ip8/123456789@t-online-com.de
ppp chap password 0 9876543210
ppp pap sent-username feste-ip8/123456789@t-online-com.de password 0 9876543210
!
ip nat inside source list NATOUT interface Dialer1 overload
!
ip access-list extended NATOUT
permit ip 10.67.0.0 0.0.255.255 host 123.123.123.123
!
ip access-list extended OUTSIDE
permit esp any any
permit udp any any eq isakmp
permit icmp any any
permit udp any any eq non500-isakmp
permit ip host 123.123.123.123 any
!
dialer-list 1 protocol ip permit
!

Es funktioniert bis auf das Kundenprogramm alles. Ich komme irgendwie nicht von den Client PCs zu der Kunden IP Adresse raus. Übersehe ich hier etwas? Vermutlich ist es nur eine Kleinigkeit. Kann es sein, dass es daran liegt, dass ich aus der 1800er Konfig das VLAN1 einfach zum FastEthernet0/1 umbenannt habe?

###

Ein debug ip nat detailled bringt mit beim Zugriffsversuch auf den Kundenserver folgende Meldungen (unsere externe IP habe ich durch 217.1.2.3 ersetzt). Für mich sieht das eigentlich in Ordnung aus.

#debug ip nat detailed

Jun 19 12:32:33.294: mapping pointer available mapping:0
Jun 19 12:32:33.294: NAT: Allocated Port for 10.67.0.74 -> 217.1.2.3: wanted 51019 got 51019
Jun 19 12:32:33.294: NAT*: i: tcp (10.67.0.74, 51019) -> (123.123.123.123, 7150) [22688]
Jun 19 12:32:33.294: NAT*: i: tcp (10.67.0.74, 51019) -> (123.123.123.123, 7150) [22688]
Jun 19 12:32:33.294: NAT*: s=10.67.0.74->217.1.2.3, d=123.123.123.123 [22688]

Jun 19 12:32:34.354: mapping pointer available mapping:0
Jun 19 12:32:34.354: NAT: Allocated Port for 10.67.0.74 -> 217.1.2.3: wanted 51020 got 51020
Jun 19 12:32:34.354: NAT*: i: tcp (10.67.0.74, 51020) -> (123.123.123.123, 7150) [22690]
Jun 19 12:32:34.354: NAT*: i: tcp (10.67.0.74, 51020) -> (123.123.123.123, 7150) [22690]
Jun 19 12:32:34.358: NAT*: s=10.67.0.74->217.1.2.3, d=123.123.123.123 [22690]

Jun 19 12:32:35.438: mapping pointer available mapping:0
Jun 19 12:32:35.438: NAT: Allocated Port for 10.67.0.74 -> 217.1.2.3: wanted 51021 got 51021
Jun 19 12:32:35.442: NAT*: i: tcp (10.67.0.74, 51021) -> (123.123.123.123, 7150) [22709]
Jun 19 12:32:35.442: NAT*: i: tcp (10.67.0.74, 51021) -> (123.123.123.123, 7150) [22709]
Jun 19 12:32:35.442: NAT*: s=10.67.0.74->217.1.2.3, d=123.123.123.123 [22709]

Jun 19 12:32:36.514: mapping pointer available mapping:0
Jun 19 12:32:36.514: NAT: Allocated Port for 10.67.0.74 -> 217.1.2.3: wanted 51022 got 51022
Jun 19 12:32:36.514: NAT*: i: tcp (10.67.0.74, 51022) -> (123.123.123.123, 7150) [22710]
Jun 19 12:32:36.514: NAT*: i: tcp (10.67.0.74, 51022) -> (123.123.123.123, 7150) [22710]
Jun 19 12:32:36.514: NAT*: s=10.67.0.74->217.1.2.3, d=123.123.123.123 [22710]

Jun 19 12:32:37.590: mapping pointer available mapping:0
Jun 19 12:32:37.590: NAT: Allocated Port for 10.67.0.74 -> 217.1.2.3: wanted 51023 got 51023
Jun 19 12:32:37.590: NAT*: i: tcp (10.67.0.74, 51023) -> (123.123.123.123, 7150) [22713]
Jun 19 12:32:37.590: NAT*: i: tcp (10.67.0.74, 51023) -> (123.123.123.123, 7150) [22713]
Jun 19 12:32:37.590: NAT*: s=10.67.0.74->217.1.2.3, d=123.123.123.123 [22713]
All possible debugging has been turned off

Vielen Dank im Voraus für die kompetente Hilfe.
Ich hoffe, dass ich hier nur eine Kleinigkeit übersehe.

Gruß

Please also mark the comments that contributed to the solution of the article

Content-Key: 186732

Url: https://administrator.de/contentid/186732

Printed on: April 26, 2024 at 11:04 o'clock

9 Comments

Latest comment

Nur mal dumm nachgefragt.... Du schreibst "IP Adresse des Kunden: 123.123.123.123" dieses IP netzwerk taucht aber am o.a. Router gar nicht auf !!
Ist die "123.123.123.123" jetzt nur ein Platzhalter für eine lokale 10.67er IP Adresse oder ist das ein ganz anderes IP Netzwerk.
Wenn letzteres der Fall ist tut sich die Frage auf "Wo" ist denn dieses IP Netz angeschlossen ??
Mit einem weiteren Router am lokalen LAN ??
Und...WO genau sind die Client IPs ?? Im lokalen 10.67er LAN ?
Geht man nach der Konfig oben, dann sieht es so aus das die Clients sich im lokalen 10.67er LAN befinden und diese dann wenn sie auf die 123.123.123.123 Adresse zugreifen einen andere Absender IP bekommen. Ist dem so ?
ip nat inside source list NATOUT interface Dialer1 overload bewirkt das sowie die IP NAT ACL greift also Absender 10.67.x.x und Ziel 123.123.1223.123 und dort dann PAT mit der dynmaisch per PPPoE ausgehandelten Dialer Interface IP gemacht wird.
Fazit: Diese Pakete mit Absender 10.67.x.x und Ziel 123.123.1223.123 bekommen nach dem NAT dann als Absender IP die derzeit aktuelle IP des Dialer Interfaces (overload Kommando).
Ist das so richtig ?
Vermutung wenn dem so ist: Mit dem neuen Router ist logischerweise eine neue PPPoE IP dynamisch am Dialer Interface ausgehandelt worden ! Der Router auf der "123.123.123.123" Seite "sieht" ja als Absender IP der geNATeten Paket nur diese IP und nicht die originale 10.67er IP und hat eine falsche oder fehlerhafte Route dorthin (neue Dialer IP) und kann deshalb die Pakete nicht zurückrouten ?
Hast du das ggf. mal mit einem Traceroute gecheckt ?
Dein Debug Output des NAT Prozesses zeigt ja ganz klar das der NAT Eintrag sauber und korrekt funktioniert am neuen Router !

10.67.x.x / 255.255.0.0 ist das interne Netz. die Clients die raus müssen
123.123.123.123 ist exemplarisch die IP des Kundenservers extern. Da wo die Clients drauf zugreifen müssen (keine Einschränkung der Ports) Die IP ist natürlich aus Datenschutzgründen für das Forum hier ersetzt worden durch die 123.... (mit suchen und ersetzen). Normaleweise steht in den Logfiles also anstelle 123.123.123.123 die IP des servers zu dem ich connecten will.

Die 217.1.2.3 ist die externe IP meine DSL Anschlusses nach der Einwahl ins Internet.

Die Konfig ist außerdem nur ein Auszug des ganzen. Es beinhaltet nur die Interfaces und die NAT geschichten.

Wie gesagt, die Konfiguration ist eigentlich die gleiche wie auf dem 1800er und da lief es über ein Jahr fehlerfrei, auch jetzt wieder. Nur auf dem 2800er Router klappt der Zugriff nicht. Die ursprüngliche Konfig wurde in Zusammenarbeit mit der t-Com erstellt. Die ist nun aber nicht mehr zuständig. Ich gehe also davon aus, das der overload Parameter passt. Bin für Vorschläge aber offen.

Ja, soweit ist das auch alles OK. Diese geNATeten Pakete bekommen durch die Overload Anweisung (PAT) immer die gerade aktuelle PPPoE IP des Dialer Interfaces als Absender IP. In der Beziehung ist das absolut korrekt !
Auf der 123.123.123.123 Serverseite des Kunden tauchen diese IPs also immer mit dieser 217.x.x.x Dialer IP auf. Die wechselt auch mal sofern du keine feste IP bei der T-Com gebucht hast !
Wichtig ist also das der Server 123.123.123.123 dann auch wieder ein saubere Route auf die 217.x.x.x IP hat um die Antwort Pakete routen zu können.
Vermutlich kneift das da also. Deshalb ist es auch wichtig die andere Seite mit der 123... zu kennen !
Ein einfacher Ping von der 123.123.123.123 IP Adresse auf die aktuelle PPPoE Dialer IP des Routers (sofern ICMP nicht irgendwo geblockt ist !) sollte die saubere Connectivity verifizieren. Klappt das nicht hast du wie vermutet irgendwo ein Routing Problem.
Sieh dir mal an wieviele Hits du auf der NATOUT ACL hast. Zeigt der Hitcounter dort einen Wert größer 0 an ist diese ACL auch aktiv. show ip nat trans sollte dir das ja auch zeigen, was es auch tut.
Die Pakete gehen also sauber genattet aus dem Router raus...das Problem liegt also folglich an der 123.123.123.123 Seite.

Stimmt, wir haben einen SDSL mit fixer IP. Auf der Gegenseite passt alles. Erstens ist dort definitiv nichts geblockt. Zweitens komme ich dort ja auch immer mit der selben IP an. Nach meinen Fehlversuchen habe ich den alten Router wieder aufgebaut und bin (mit der selben externen IP) sofort zu einer verbindung gekommen.

Momentan habe ich den Problemrouter hier bei mir. Werde das morgen mal testen mit dem HitCounter wie von Dir vorgeschlagen. Dazu schließe ich den Router an unseren Backup DSL hier an.

Ja das ist eine gute Idee und dann schalte den NAT Debugger auch mal ein um zusehen welche inbound und outbound IPs tatsächlich bei genNATeten Paketen verwendet werden.
Lasse zudem auch erstmal die inbound ACL am Dialer Interface weg also so wenig wie möglich Fallen installieren um erstmal die grundlegende Funktion zu testen.

Welche Debug Befehle wären das?

Also das ist echt zum verzweifeln. Der Server des Kunden funtkioniert. Über die Cisco 1800er Router komme ich raus. Über unsere ForeFront Firewall der Zentrale ebenfalls. Die Kundensoftware und der Server funktioniert.

Nun habe ich bei meinem Testrouter einmal die DSL Konfiguration ersetzt durch eine Konfiguration mit Standardgateway am FaE0/0. Der Cisco 2800 ist nun am FaE0/0 mit einem DSL Router verbunden, der als Std. Gateway fungiert und nichts blockt. Wenn ich dort direkt mit dem Notebook rangehe, dann funktioniert alles.

Hänge ich den Cisco drann ist dieser auch sofort online. Nun habe ich eine am FaE0/1 das interne LAN (ip nat inside) am FaE0/0 das externe (ip nat outside) und folgende Regeln:

!
interface FastEthernet0/0
ip address 192.168.2.199 255.255.255.0
ip nat outside
ip virtual-reassembly
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 10.67.110.1 255.255.0.0
ip nat inside
ip virtual-reassembly
ip tcp adjust-mss 1360
duplex auto
speed auto
h323-gateway voip bind srcaddr 10.67.110.1
!
ip nat inside source list TEST interface FastEthernet0/0 overload
!
ip access-list extended TEST
permit ip any any
!

Damit lasse ich doch alles zu. Am Testrechner kann ich nun auch alles ausgehend machen. Web, Mail, Ping, nslookup, alles was ich versuche klappt.

Nur der Zugriff auf den Server des Kunden, auf den Ports 7150 - 7160 klappt nicht. Der Ping schon.

Der NAT Debug bring folgendes:

Das ist der Ping
*Jun 26 11:40:44.654: NAT*: s=10.67.0.1->192.168.2.199, d=123.123.123.123 [22550]
*Jun 26 11:40:44.730: NAT*: s=123.123.123.123, d=192.168.2.199->10.67.0.1 [62476]
*Jun 26 11:40:45.658: NAT*: s=10.67.0.1->192.168.2.199, d=123.123.123.123 [22551]
*Jun 26 11:40:45.734: NAT*: s=123.123.123.123, d=192.168.2.199->10.67.0.1 [62477]
*Jun 26 11:40:46.662: NAT*: s=10.67.0.1->192.168.2.199, d=123.123.123.123 [22552]
*Jun 26 11:40:46.738: NAT*: s=123.123.123.123, d=192.168.2.199->10.67.0.1 [62478]
*Jun 26 11:40:47.662: NAT*: s=10.67.0.1->192.168.2.199, d=123.123.123.123 [22553]
*Jun 26 11:40:47.738: NAT*: s=123.123.123.123, d=192.168.2.199->10.67.0.1 [62479]

Und das hier die Anfrage zu dem Kundenserver, da fehlt jeweils die zweite Zeile zurück
*Jun 26 11:40:56.335: NAT*: s=10.67.0.1->192.168.2.199, d=123.123.123.123 [22554]
*Jun 26 11:40:57.395: NAT*: s=10.67.0.1->192.168.2.199, d=123.123.123.123 [22555]
*Jun 26 11:40:58.463: NAT*: s=10.67.0.1->192.168.2.199, d=123.123.123.123 [22556]
*Jun 26 11:40:59.523: NAT*: s=10.67.0.1->192.168.2.199, d=123.123.123.123 [22557]
*Jun 26 11:41:00.579: NAT*: s=10.67.0.1->192.168.2.199, d=123.123.123.123 [22558]
*Jun 26 11:41:20.647: NAT: expiring 192.168.2.199 (10.67.0.1) tcp 50903 (50903)
*Jun 26 11:41:21.671: NAT: expiring 192.168.2.199 (10.67.0.1) tcp 50904 (50904)
*Jun 26 11:41:22.695: NAT: expiring 192.168.2.199 (10.67.0.1) tcp 50905 (50905)
*Jun 26 11:41:23.719: NAT: expiring 192.168.2.199 (10.67.0.1) tcp 50906 (50906)
*Jun 26 11:41:24.743: NAT: expiring 192.168.2.199 (10.67.0.1) tcp 50907 (50907)

Kann das irgendwie an den Ports liegen? Die Software versucht zunächst eine Verbindung zu 123.123.123.123 auf Port 7150. Im weiteren Betrieb werden die Ports bis 7160 ebenfalls benötigt. Auf unserer Forefront Firewall der Zentrale habe ich jeweils 7150 - 7160 ausgehend, sekundär eingehend freigegeben.

Ich bin vollkommen am Ende mit dem Latein, zumal alles andere funktioniert.
Kann es an der Firmware liegen? Hier läuft momentan die c2800nm-advipservicesk9-mz.124-15.T14.bin

Der Grund: Der DMVPN Gateway der Zentrale ist ebenfalls ein 2800, da läuft die gleiche Firmware und mir wurde mal gesagt es ist empfohlen, auf den einzelnen Komponenten möglichst den gleichen Stand zu betreiben.

Und siehe da: Es liegt an der Firmware.

Bei der Installation des Routers habe ich es mal wieder gut gemeint und - auf Anraten der T-COM - auf dem Router die gleiche Firmware aufgespielt wie auf dem baugleichen Router in unserer Zentrale: c2800nm-advipservicesk9-mz.124-15.T14.bin

Mit dieser tritt dieses seltsame Problem mit dem Server des Kunden auf. Zusätzlich schlägt jeder 1. Versuch eines Pings nach extern immer fehl.

Mit der vorinstallierten Firmware (C2800NM-ADVIPSERVICESK9-M), Version 12.4(15)T12
habe ich nun plötzlich keinerlei Probleme mehr. Der Zugriff auf den Server des Kunden funktioniert so wie es soll. Ebenso ist bei einem Ping nach extern der Erste Versuch sofort erfolgreich.

Irgendwo war hier also der Wurm drin. Da kann man natürloch lange suchen. Hätte ich den Router gleich Out-Of-The-Box so verwendet, wäre es gar nicht aufgetreten.

Trotzdem danke an Alle.

German solved Question Routers, Routing Networks