[Routerboard] VLAN- NAS intern niet te bereiken - extern wel

[kroepmoesje]

Hallo,

Ik hoop dat jullie mij even de juiste weg op kunnen sturen, ik kom er namelijk even niet meer uit.

Situatieschets:
Er is 1 internet verbinding (ziggo) welke we delen met verschillende personen. Elke persoon heeft zijn eigen subnet, (172.16.10.X, 172.16.11.X, 172.16.12.x etc),

De DHCP server op de firewall geeft per poort een /24 range uit, met als netmask: 255.255.0.0.

Vanaf de firewall komt in eth1 de internet verbinding binnen. Persoon A zit op eth2 en wordt naar een switch (HP1810-24) doorgeprikt, met een VLAN (untagged) . Persoon B zit op eth3, gaat ook naar dezelfde switch naar een andere VLAN. etc. Op de switch worden vervolgens de computers van de persoon aangesloten.

Probleem

Het is de bedoeling dat persoon A niet op het netwerk van persoon B kan komen en vice versa, maar wel de internet verbinding delen. Tot zo ver is dat gelukt.

Nu moet echter 1 VLAN / subnet ook bereikbaar zijn voor persoon A en persoon B. Hierop zit o.a. een gedeelde NAS. Dit krijg ik niet voor elkaar. Vanaf buiten (met bijvoorbeeld een 4G verbinding) is de NAS wel de bereiken, maar intern enkel via de eigen VLAN. Een andere VLAN krijgt geen verbinding. De NAS heeft zelf ook verbinding met het internet.

In de firewall heb ik rules aangemaakt dat dit interne verkeer doorgelaten moet worden, maar dit blijkt niet voldoende. Het mask zoals aangegeven op zowel de nas als de PC's 255.255.0.0, dus dat zal niet het probleem mogen zijn.

Wanneer ik blokkades in de firewall verwijder blijkt ook dat ik niet naar andere subnets kan verbinden. Ergens wordt dit verkeer tegen gehouden, zonder dat ik zelf de blokkades instel. Ook wanneer ik in de firewall expliciet de verbindingen toesta, werkt dit niet intern over verschillende

Zelf heb ik gedacht dat de switch de boosdoener kon zijn, dus heb ik de poort van de NAS "getagged" in elke VLAN, dit blijkt ook geen oplossing. In dat geval is de NAS zelfs niet via zijn eigen VLAN bereikbaar.

Kan iemand mij op weg helpen met dit vraagstuk of mij een richting op kan wijzen waar het probleem mogelijkerwijs zit?



(groen en rood zijn geen fysieke, rood geeft aan wat geen verbinding mag maken, groen wat wel verbinding mag maken)

[ Voor 3% gewijzigd door kroepmoesje op 10-11-2014 13:39 ]

[plizz]

Wat mij opvalt is dat subnet niet correct is. 172.16.1.x 255.255.0 = 172.16.0.0 - 172.16.255.255. Je hebt nu een grote 172.16.x.x netwerk gemaakt als ik het zo leest. Zorg dat elk netwerk echt een /24 subnet krijgt. dus 255.255.255.0. Begin daarmee. Misschien helpt het.

[garriej]

kroepmoesje schreef op maandag 10 november 2014 @ 13:16:
Hallo,

Ik hoop dat jullie mij even de juiste weg op kunnen sturen, ik kom er namelijk even niet meer uit.

Situatieschets:
Er is 1 internet verbinding (ziggo) welke we delen met verschillende personen. Elke persoon heeft zijn eigen subnet, (172.16.10.X, 172.16.11.X, 172.16.12.x etc),

De DHCP server op de firewall geeft per poort een /24 range uit, met als netmask: 255.255.0.0.

/24 = 255.255.255.0

255.255.0.0 is /16

[kroepmoesje]

Klopt, maar het is de bedoeling dat 172.16.10.X wél verbinding kan maken met 172.16.12.X. Het lijkt mij dat het subnet dan groot genoeg moet zijn? Ook als het subnet 255.255.255.0 (/24) wordt gebruikt, kan geen verbinding worden gemaakt.

[ Voor 23% gewijzigd door kroepmoesje op 10-11-2014 13:41 ]

[garriej]

Ja dat snap ik, maar je dhcp kan geen /24 subnet uitgeven, als je een /16 subnet heb

Het gaat ergens fout in je routering van je vlans.

[mbaltus]

Ja en Nee, dat hangt af van wat je wilt bereiken.
Als je 1 (V)LAN wilt hebben waarin alle systemen zitten, dan moet je 1x een /16 aanmaken. Als je dit verschillende reeksen wil scheiden en wel met elkaar wilt laten praten, dan moet je de verschillende /24s routeren.

[ Voor 0% gewijzigd door mbaltus op 10-11-2014 13:45 . Reden: spuit elf ]

[Thralas]

Ik zie niet in welk nut VLANs hebben in je situatieschets.

Als je iedere poort een eigen /24 toekent en er verder voor zorgt dat ze geen switch of bridge groups delen dan moet alles door je firewall.

Van daaruit is het simpelweg een kwestie van een 'default deny' rule met een LOG target ervoor, en dan ACCEPT rules toevoegen tot het werkt (al dan niet op basis van inzicht, alles wat denied wordt vind je terug in je logs).