Netwerk routering vraagje

[WaSteiL]

Jullie mening even gevraagd. We liggen op mijn werk een klein beetje in strijd met een netwerkleverancier over waar nu het probleem ligt. Zal de situatie even uitleggen.

Netwerk 1:
192.168.10.X range
Default gateway: 192.168.10].1
VPN gateway: 192.168.10.2
Route aangemaakt op de default gateway dat al het verkeer naar 192.168.1.X via 192.168.10.2 moet gaan.

Netwerk 2:
192.168.1.X range
Default gateway: 192.168.1.1
VPN gateway: 192.168.1.28
Route aangemaakt op de default gateway dat al het verkeer naar 192.168.10.X via 192.168.1.28 moet gaan.

Tussen de twee vestigingen ligt een dedicated VPN verbinding.
Vanuit netwerk 1 kan netwerk 2 zonder problemen gepinged worden.
Vanuit netwerk 2 kan de binnenkant van de router op adres 192.168.10.2 bereikt worden, maar de rest van het netwerk niet.

Dit is een tracert naar een actief netwerkadres aan de andere zijde op netwerk 1:

code:

H:>tracert 192.168.10.201
Tracing route to 192.168.10.10 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2    <1 ms    <1 ms    <1 ms  192.168.1.28
  3     8 ms     7 ms     7 ms  192.168.201.46
  4    17 ms    17 ms    17 ms  192.168.201.41
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.

Dit is een tracert naar de binnenzijde van de router op netwerk 1 vanaf netwerk 2.

code:

H:>tracert 192.168.10.2
Tracing route to 192.168.10.2 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2     1 ms    <1 ms    <1 ms  192.168.1.28
  3     8 ms     7 ms     7 ms  192.168.201.46
  4    18 ms    18 ms    18 ms  192.168.10.2

Zoals je kan zien gaat hij bij een tracert naar een adres op het netwerk1 segment helemaal niet over de binnenzijde router, maar loopt hij vast op de buitenkant router van de netwerkleverancier.

Er moet dus ergens een fout zitten aan de router die staat bij netwerk 1. Volgens de netwerkleverancier zou het liggen aan de route op netwerk 1 naar netwerk 2, maar dat verklaart helemaal niet waarom een ping en tracert vanaf netwerk 1 naar netwerk 2 wel goed gaat.

Kleine toevoeging: de beide routers voor het verkeer over de VPN worden niet door ons zelf beheerd helaas, maar door de netwerkpartij. Probleem is alleen dat de lijn echt morgenavond werkend moet zijn vanwege een migratie n.a.v. een fusie tussen twee partijen die elk aan weerszijde zitten.

Iemand?

[Verwijderd]

Je kan van netwerk1 naar netwerk2 pingen zeg je. Dit betekend dat de ping (=verkeer van netwerk1 naar netwerk2) goed gaat EN dat de pong (=de reactie op de ping, dus van netwerk2 naar netwerk1) goed gaat. De routes op beide vestigingen zijn dus goed ingesteld.

De ping van netwerk1 naar netwerk2 is voor netwerk1 uitgaand verkeer voor de firewall (op netwerk1), dit betekend dat de pong die terug komt ook wordt behandeld door de firewall als uitgaand verkeer en dus wordt toegelaten.

De ping van netwerk2 naar netwerk1 wordt door de firewall op netwerk1 gezien als inkomend verkeer, en ik ben van mening dat het daar dus fout gaat. Check dus je firewall instellingen eens in netwerk1.

[wallywally]

Waar komt dat 201 segment vandaan?

[Verwijderd]

wallywally schreef op donderdag 24 augustus 2006 @ 10:41:
Waar komt dat 201 segment vandaan?

Segment 201 is natuurlijk de vpn verbinding.

Je hebt op een vpn router het segment van je lokale netwerk en het segment van de vpn verbinding.

Dus:

192.168.10.x ---- 10.1-| ROUTER | 201.41 ----------- vpn lijn ------ 201.46 | ROUTER | 1.28 ----- 1.x

[WaSteiL]

Verwijderd schreef op donderdag 24 augustus 2006 @ 10:40:
Je kan van netwerk1 naar netwerk2 pingen zeg je. Dit betekend dat de ping (=verkeer van netwerk1 naar netwerk2) goed gaat EN dat de pong (=de reactie op de ping, dus van netwerk2 naar netwerk1) goed gaat. De routes op beide vestigingen zijn dus goed ingesteld.

De ping van netwerk1 naar netwerk2 is voor netwerk1 uitgaand verkeer voor de firewall (op netwerk1), dit betekend dat de pong die terug komt ook wordt behandeld door de firewall als uitgaand verkeer en dus wordt toegelaten.

De ping van netwerk2 naar netwerk1 wordt door de firewall op netwerk1 gezien als inkomend verkeer, en ik ben van mening dat het daar dus fout gaat. Check dus je firewall instellingen eens in netwerk1.

Er zitten niet echt een firewall tussen aangezien het een dedicated VPN verbinding is die niet gebruikt maakt van een internet verbinding. Zijn gewoon 2 Cisco routers.
Ik kan op de betreffende lijnen dus niet internetten.

Het enige wat ik me kan bedenken is dat er op de router in netwerk 2 geen default gateway is ingevuld voor de interface op de binnenzijde. Tijdens het instellen van de router hoorde ik de enigineer daar iets over zeggen. Hij zei dat dit niet nodig zou zijn. Kan dit een verklaring zijn dat hij daardoor de route niet terug kan vinden naar de PC waarvan de ping of tracert plaatsvind?

Dan zou dat alleen toch ook al mis moeten gaan bij een tracert of ping naar de router op netwerk 1.

[Verwijderd]

WaSteiL schreef op donderdag 24 augustus 2006 @ 11:03:
[...]


Er zitten niet echt een firewall tussen aangezien het een dedicated VPN verbinding is die niet gebruikt maakt van een internet verbinding. Zijn gewoon 2 Cisco routers.
Ik kan op de betreffende lijnen dus niet internetten.

Het enige wat ik me kan bedenken is dat er op de router in netwerk 2 geen default gateway is ingevuld voor de interface op de binnenzijde. Tijdens het instellen van de router hoorde ik de enigineer daar iets over zeggen. Hij zei dat dit niet nodig zou zijn. Kan dit een verklaring zijn dat hij daardoor de route niet terug kan vinden naar de PC waarvan de ping of tracert plaatsvind?

Dan zou dat alleen toch ook al mis moeten gaan bij een tracert of ping naar de router op netwerk 1.

Zoals ik al zei wordt vanuit netwerk1 de ping goed verstuurd, en komt de pong ook weer aan, dit betekend dat je routes gewoon goed zijn.

Ik weet niet hoeveel verstand je hebt van cisco routers en IOS, maar ook al heb je geen firewall, cisco IOS kent wel het principe van Access Control Lists (ACL). Met een ACL kun je dus verkeer filteren. Ik ben van mening dat je ACL's dus niet goed zijn.

[WaSteiL]

Verwijderd schreef op donderdag 24 augustus 2006 @ 11:07:
[...]


Zoals ik al zei wordt vanuit netwerk1 de ping goed verstuurd, en komt de pong ook weer aan, dit betekend dat je routes gewoon goed zijn.

Ik weet niet hoeveel verstand je hebt van cisco routers en IOS, maar ook al heb je geen firewall, cisco IOS kent wel het principe van Access Control Lists (ACL). Met een ACL kun je dus verkeer filteren. Ik ben van mening dat je ACL's dus niet goed zijn.

Het meest irritante van deze situatie is dat wij de betreffende routers zelf niet beheren. Ik moet het dus doen met die netwerkpartij die niet echt haast maakt.Normaal zou ik al deze dingen kunnen checken, maar nu dus niet.

[Verwijderd]

WaSteiL schreef op donderdag 24 augustus 2006 @ 11:09:
[...]


Het meest irritante van deze situatie is dat wij de betreffende routers zelf niet beheren. Ik moet het dus doen met die netwerkpartij die niet echt haast maakt.Normaal zou ik al deze dingen kunnen checken, maar nu dus niet.

Tja... snap je probleem.... zou echter toch wat schoppen uit gaan delen naar de beherende partij.... Jullie betalen toch voor dit managed vpn??? Daar mag je dan ook wat voor terug verwachten.

Ken anders nog wel een goede partij die wel wat sneller zijn met dit soort dingen, als je geinteresseerd bent laat het dan maar weten.

[WaSteiL]

Verwijderd schreef op donderdag 24 augustus 2006 @ 11:28:
[...]


Tja... snap je probleem.... zou echter toch wat schoppen uit gaan delen naar de beherende partij.... Jullie betalen toch voor dit managed vpn??? Daar mag je dan ook wat voor terug verwachten.

Ken anders nog wel een goede partij die wel wat sneller zijn met dit soort dingen, als je geinteresseerd bent laat het dan maar weten.

Veranderen van partij zit er nu niet meer in aangezien die VPN vanavond, maar uiterlijk morgenochtend moet gaan werken.

[Verwijderd]

Dan blijft er maar 1 ding over denk ik... en dat is flink schoppen.

[WaSteiL]

Mogelijk toch niet de externe partij.
De ping en tracert aan de andere kant bleek gedaan te zijn terwijl de Default Gateway op de betreffende pc aangepast was. Met de normale standaard gateway gaat dit wel mis terwijl er wel een route is aangemaakt.

Nu schijnt dit veroorzaakt te worden door de configuratie van de betreffende PIX firewall waar de routering op aangemaakt is.

De netwerkbeheerder op de andere vestiging moet gewoon een flinke schop voor zijn kloten hebben.

[ Voor 11% gewijzigd door WaSteiL op 24-08-2006 16:30 ]