Lancom hinter NAT mit Netz Überschneidung

[tbc233]

An einem entfernten Standort mit einem in die Jahre gekommenen 1781EF (ohne plus), hat uns wohl irgendwann im Laufe der Jahre der Provider mal sein Modem von Routing auf NAT umgestellt und niemand hat was davon gemerkt.
Es befindet sich dort ein 192.168.3.0 Netz. Bemerkenswert ist, dass eben der Lancom nun hinter einem NAT ist (wie lange schon, lässt sich nicht nachvollziehen, bei der Ersteinrichtung war er es jedenfalls nicht - auf DHCP eingestellt war er immer schon) und auf der WAN Seite 192.168.1.100 hat. Trotzdem kann er problemlos ein VPN aufbauen zu einem 192.168.1.0 Netz, alles funktioniert ohne Probleme. Das Gerät hat noch eine LCOS 8.50 (nicht hauen, er ist eh von einem NAT geschützt )

Es war schon lange am Plan, das Gerät zu tauschen und so hab ich dem Team dort vorkonfiguriert einen 1800EF geschickt. Mit dem (10.80 RU2) kriege ich dieses Setup aber nicht mehr zum Laufen. Also das VPN kommt zustande, aber es geht von dem betroffenen Standort kein Traffic ins 192.168.1.0 Netz. Also zumindest nicht ins gewünschte. Wenn ich zb. 192.168.1.1 im Browser eingebe, sehe ich die Oberfläche des Provider Modems. Also das WAN zieht hier VOR dem VPN Netz.
Schräg ist, dass es umgekehrt durchaus funktioniert. Also von dem 192.168.1.0 VPN Netz, kann ich zb. den Lancom 192.168.3.1 pingen und kriege auch Antworten.

Nun ist mir klar, dass das so ohnehin inakzeptabel ist, es wird gerade probiert heraus zu finden wie wir den Internetzugang wieder auf Routing gestellt bekommen.
Aber interessieren würde es mich schon, warum das mit dem alten Gerät klappt und mit dem neuen nicht. Bzw. würde ich es trotzdem gerne hinkriegen, übergangsweise.

Ich hab auch mit der N:N Tabelle experimentiert, um das entfernte 192.168.1.0 Netz auf 192.168.112.0 umzusetzen (inkl. Eintrag in der Routing Tabelle für 192.168.112.0 auf die VPN Verbindung). Das funktionierte leider nicht.

[backslash]

Hi tbc233,

seit der 8.50 haqt sich so viel geändert, daß dir kaum einer sagen kann, was da genau der Unterschied ist - Es wurde definitiv zur 10.40 Routung-Engine wurde ausgetauscht.

Die verwedneten Routen kannst du dir per "show ipv4-fib" auf dem, CLI anschauen. Wenn du willst daß deine Route Vorrang vor der Route zum direkt angebundnene Netz ("Connected WAN", Adminstrative Distanz 2) hat, mußt du sie mit einer niedrigeren administrativen Distanz (z.B. 1) eintragen.

Wegen der "überlappung" solltest du dir ggf. überlegen ob du nicht besser mit Routing-Tags arbeitest um eine saubere Trennung hinzubekommen und z.B. dem WAN-Interface ein Tag ungleich 0 verpasst - du hast ja offenbar keine Dienste, die von aussen erreichbar sein müssen, denn sonst wäre das NAT schon eher aufgefallen...

Gruß
Backslash

[tbc233]

Vielen Dank für Deine Einschätzung!
Mit Routing Tags auf der WAN Seite habe ich noch nie gearbeitet. Es stimmt, von außen muss da nichts erreichbar sein und das steht auch in Zukunft nicht an. Werde diese Variante antesten.

[tbc233]

Habe heute endlich Zeit gefunden, mich dem Thema wieder zu widmen.

Interessant war, dass die Route ins VPN Netz (jenes 192.168.1.0 das sich eben mit dem WAN Netz "überschneidet") nach Einrichtung des VPNs und dessen erfolgreichen Aufbau gar nicht unter "show ipv4-fib" sichtbar war.

Erst als ich wie von Dir vorgeschlagen der VPN Route eine Administrative Distanz von 1 gegeben habe, tauchte sie auch dort auf und dann hat auch gleich alles funktioniert.
Ich lass es jetzt mal so bis wir dem Provider Endgerät das NAT abgewöhnt haben.

Herzlichen Dank backslash für die Hilfe!