Router wil niet routeren

[Verwijderd]

Ben deze week tig uur bezig geweest met een Microsoft Server 2003 met daarop Routing and Remote Access.

De server is schoon geinstalleerd en alleen Routing is aangezet.

De server staat in de DMZ en gaat met twee Cisco routers naar klanten toe.

Vanuit de DMZ kunnen wij bij beide klanten. Werkt allemaal probleemloos.

Maar wanneer ik vanuit het produktie segment kom en hij dus moet gaan routeren komt er geen bit op de andere interface.

Alles routes zijn met Static routes vast gelegd en deze werken ook goed vanaf de DMZ.

IP routing staat aan op de interfaces en op de routing optie van de server.

Ook de registry entry IPEnableRouter heb ik op 1 gezet. Maar het kreng weigert het verkeer van de DMZ interface naar de Klant interface door te zetten.

Enig idee waarom dit niet zou werken?

[Verwijderd]

het eerste wat in me opkomt is dat misschien je ip's niet kloppen of dat het verkeerd aangesloten is...

[ Voor 15% gewijzigd door Verwijderd op 10-05-2010 21:37 ]

[Verwijderd]

Lijkt mij niet, er hebben al 5 man naar gekeken en hij is wel 3 keer opnieuw geconfigureerd. Elke keer met hetzelfde resultaat.

Ik heb dus:

Produktie ---- Firewall ----- DMZ ----- Windows Router ----- Cisco router klant ------ Klant netwerk

Vanuit produktie kan ik bij de windows router komen.

Vanuit de Windows router kan ik bij de klant komen.

Maar vanuit Produktie kan ik net bij de Klant router komen en alles wat er achter ligt.

Ik krijg een reply t/m de Klant interface van de Windows router. 1 stap verder is de Cisco interface en die geeft geen antwoord meer. Daar komt geen bit aan.

Ook als ik ga sniffen dan zie je dat op de DMZ interface verkeer wordt aangeboden, maar aan de klanten kant blijft de teller op 0 staan.

Oftewel, hij zet het niet over van de ene interface naar de andere. En laat dat nou net de enige toupassing van deze router zijn.....

[Verwijderd]

kan je er de ip range's bijzetten, dat maakt het wat duidelijker

[Verwijderd]

Produktie = 10.10.0.0/16
DMZ = 192.168.50.0/24
Klant = 2.128.196.0/20

Op de firewall (= Default Gateway voor Produktie) staat een static route dat 2.128.196/20 naar 192.168.50.2 wordt gestuurd, dit is de IP aan de DMZ kant van de Router.

Op de router staat een static route van 2.128.196.0/20 naar de 2.128.48.82. Dit is de interface in de router waar de Cisco op is aangesloten.

Default gateway van de Router is 192.168.50.1 (firewall)

Ik kan dus vanuit produktie 2.128.48.82 pingen, maar 2.128.48.81 niet.

Op de router kan ik pingen naar het hele 2.128.196/20 segement

Een traceroute naar 2.128.196.1 geeft dan ook eerst de firewall en staop 2 de router (192.168.50.2).

Maar dan houdt het op....

[Verwijderd]

en tracert vanaf klant naar productie?

[Verwijderd]

Weet ik niet.

Ze kunnen tot op hun Cisco router komen.

Op de Windows Router staat een port forwarding naar de firewall die het weer doorzet naar een server. Dit werkt goed.

O ja, op de Windows Router staat richting de klant NAT ingesteld. Hij gaat dus met het .82 adres naar de Cisco router (tenminste, dat zou hij moeten doen).

[Brahiewahiewa]

Omdat je routing niet begrijpt ga je maar in de registry zitten prutsen en NAT aanzetten?

Het probleem hier is dat de Cisco geen route heeft naar 10.10.0.0/16
Dat je wel kunt pingen naar 2.128.48.82 betekent dat de Windows router z'n werk goed doet.

[Verwijderd]

het zou juist niet uit moeten maken dat cisco geen route heeft omdat ie nat heeft ingesteld...

die regedit snap ik inderdaad ook niet...

[rapture]

Verwijderd schreef op zondag 18 februari 2007 @ 01:17:
het zou juist niet uit moeten maken dat cisco geen route heeft omdat ie nat heeft ingesteld...

De Cisco kent alleen de DMZ-subnet en je moet vermelden dat er ook productiesubnet bestaat en naar welke gateway de pakketjes moeten. Zorg dat er naar overal routes bestaan en als je een route ergens heen legt, zorg dan ook voor een terugweg.

Een duidelijke tekening met de nodige subnetten en ip-adressen zou duidelijker zijn. Routingtabellen ook maar posten, de inhoud van firewalls/ACL's/NAT/portforwarding/... kunnen we ook gebruiken. Alle netwerkdevices vermelden en liefst ook vermelden van waar naar waar geNAT wordt.

[ Voor 15% gewijzigd door rapture op 18-02-2007 01:38 ]

[Verwijderd]

maar hij kan niet pingen van productie naar klant, dat is vreemd want cisco zou dan alleen de route naar de nat (windows server) moet weten om terug te komen, want nat stuurt het pakketje dan door naar productie terug...

maar inderdaad, een duidelijk tekening met ip's/subnets van elke interface en route tables van alles zou het een stuk duidelijker maken...

[Verwijderd]

Brahiewahiewa schreef op zondag 18 februari 2007 @ 01:11:
Omdat je routing niet begrijpt ga je maar in de registry zitten prutsen en NAT aanzetten?

Het probleem hier is dat de Cisco geen route heeft naar 10.10.0.0/16
Dat je wel kunt pingen naar 2.128.48.82 betekent dat de Windows router z'n werk goed doet.

In de help file van RAS staat dat de optie IPEnableRouter van 0 naar 1 gezet moet worden.

De Cisco hoeft ook geen route naar 10.10.0.0 te hebben want dat segment gebruiken ze helemaal niet. De klant praat tegen een IP adres in z'n eigen range (2.128.48.82). En daarom moet NAT juist wel aangezet worden want anders is het pakket afkomstig van 10.10.0.0 en dat kennen zij niet.

Dat ik naar 2.128.48.82 kan ping klopt natuurlijk, want dat is een interface op de router zelf. Dit zegt niks over wel of niet routeren. De .81 is de Cisco en die is niet te bereiken, en daarvoor moet hij juist routeren...

[Verwijderd]

Misschien dat dit helpt.

A = Produktie, B = DMZ, C = Klant.

Van A kan ik B pingen
Van B kan ik C pingen
Maar van A kan ik niet C pingen.

Hoewel niet van veel belang, Van C kan ik B pingen, en via de port forwarding van C ook A bereiken.

Dit is het klassieke voorbeeld waar een router tussen moet zitten. En met de static routes kan het ook niet veel moeilijker zijn. Want de pakketjes gaan de goede kant op.

De firewall speel hier geen rol in, die stuurt alles gewoon door (A kan immers B pingen en Vanaf C is de server A bereikbaar).

Vandaag heeft er nog een 6e persoon naar gekeken maar ook die komt er niet uit. Ik begin langzamerhand te denken dat de configuratie gewoon goed is maar dat het kreng gewoon kapot is, het blijft Windows...

[Verwijderd]

Het werkt weer.

Uiteindelijk waren het de windows updates waarna het weer ging werken.

Op zich vreemd, want de oude server deed het al vanaf 2004 zonder die updates.

[ Voor 83% gewijzigd door Verwijderd op 20-02-2007 11:10 ]

[Silver7]

Verwijderd schreef op dinsdag 20 februari 2007 @ 11:09:
Het werkt weer.

Uiteindelijk waren het de windows updates waarna het weer ging werken.

Op zich vreemd, want de oude server deed het al vanaf 2004 zonder die updates.

Misschien heb je niet alles geinstalleerd -> schone installatie, waardoor je bepaalde onderdelen miste om goed te laten functioneren