Als je als reseller een wireless netwerk installeert, met bijvoorbeeld de situatie van een van elkaar geïsoleerd kantoor- en gasten VLAN, dan stellen we voor de SSID van het gasten-WLAN veelal de optie “cliënt isolatie” in. Met deze oplossing zullen de wireless cliënts, verbonden met het betreffende access point, elkaar niet kunnen zien. “So far so good” zal je denken. Maar als je deze vorm van cliënt isolatie aanzet, dan merk je dat in sommige gevallen de Wi-Fi cliënts elkaar toch nog kunnen zien. In deze blog wat meer uitleg en uiteraard de oplossing om cliënts aangesloten op switches binnen één VLAN, volledig af te schermen.
Wat is er aan de hand:
Bij een Wireless controller waar alle netwerkverkeer door de controller zelf gaat, kan je in de meeste gevallen vrij eenvoudig de WLAN-cliënts van elkaar afschermen, maar bij de modernere Wireless controller zie je deze vorm van filteren meestal niet meer. Vanwege de dubbele netwerkbelasting heeft men in de praktijk afscheid genomen van deze oplossing en gaat het netwerkverkeer van de AP’s niet meer door de Wireless controller zelf. Nadeel van deze verandering is dat de Wireless controller geen invloed meer kan uitoefenen op het netwerkverkeer zelf, dus ook niet op de functie van “cliënt isolatie”. Hierdoor zie je dat, als je meerdere AP’s in een netwerk aangesloten hebt de cliënts verdeeld over verschillende AP’s elkaar nog steeds kunnen zien. Dit komt omdat cliënt isolation alleen nog werkt voor cliënts aangesloten op hetzelfde AP in hetzelfde SSID, dit komt omdat de switch het netwerkverkeer tussen de AP’s gewoon uitwisselt. Deze eigenschap vind je ook bij de toepassing van een Cloud gebaseerde WLAN-controller. Wil je dit oplossen dan zal je port isolatie op de switch moeten toepassen, maar als je een switchpoort volledig isoleert dan werkt dit weer tegen voor de andere VLAN’s waar je misschien wel wilt dat de cliënts elkaar wel kunnen zien. Denk hierbij aan een netwerkprinter, fileshare, VoIP-telefoons die moeten kunnen doorverbinden, enz. De meest praktische oplossing voor dit probleem is om het netwerkverkeer te filteren door middel van Acces Control Lists, ofwel afgekort met ACL’s. Over ACL’s kan je uiteraard complete boekwerken schrijven maar mijn streven is om je op een eenvoudige manier op weg te helpen met een kort voorbeeld. Als je wat dieper in de ACL materie wilt duiken, dan heb ik deze NETGEAR link voor je.
Wat zijn ACL’s?
ACL’s zijn filters bestaande uit regels met beperkingen of toestemmingen ten behoeve van netwerkverkeer over een aangewezen poort of VLAN van een Ethernet Switch. Vergelijk het maar een beetje met firewall rules toegepast bij een Internet-router. Je hebt verschillende typen ACL’s waar we het nu over gaan hebben zijn IP-gebaseerde ACL’s. Een veel gebruikte term hierbij is “Extended ACL’s”. Met Extended ACL’s kunnen we restricties aanbrengen op een IP-segment en deze filter op VLAN-niveau koppelen aan een poort van de switch. De bedoeling van deze scenario is een filter te bouwen waar de Wi-Fi cliënts van een bepaald VLAN alleen maar bij de default gateway kunnen komen en niet onderling bij elkaar maar wel gebruik kunnen maken van de bovenliggende segmenten van het netwerk. De tekening boven deze blog schetst de situatie.
Punten van aandacht bij ACL’s:
- Zodra er een regel in de ACL overeenkomt met de criteria dan “stapt” het netwerkverkeer direct uit de filter. Met de hierop volgende regels wordt dan niets meer gedaan. Hierdoor is de volgorde van de regels die je opstelt essentieel voor de juiste werking.
- Een ACL wordt automatisch afgesloten met een impliciete “deny”. Vervelend is dat je dit niet terugziet in je overzicht van de opgestelde regels, hou hier dus rekening mee. Want als niets aan de gestelde regels voldoet dan sterft het netwerkverkeer op de betreffende poort uit. Maak, als dit niet het gewenste gedrag is, een wildcard regel aan waarmee je de rest van het verkeer op de betreffende switchpoort doorlaat.
- Andere tip is om de Sequence Number’s in stappen van 10 op te laten lopen. Voordeel is dat je achteraf, indien nodig, nog een paar regels tussen kunt voegen zonder dat je de ACL geheel opnieuw hoeft in te voeren.
- Zorg ervoor dat de VLAN configuratie op de switch klaar is voordat je de ACL’s gaat configureren.
Nu de praktijk:
Stel we hebben een netwerk met twee VLAN’s, beide VLAN’s hebben via een router firewall toegang tot het Internet. Het kantoor VLAN heeft IP-range 192.168.1.X en het gast VLAN heeft IP-range 192.168.100.X met als default gateway 192.168.100.254, hoe bouwen we deze configuratie dan op in een switch?
Als eerste configureren we de ACL. De onderstaande afbeelding laat de instelling van de ACL zien. In dit voorbeeld hebben we de ACL-ID nummer 100 gegeven omdat we hier spreken over Extended ACL’s en Extended ACL’s dienen een nummer te hebben tussen de 100 en de 199. In dit voorbeeld is ook gekozen om het gasten-VLAN, VLAN 100 te noemen. Uiteraard hoeft het VLAN nummer niet gelijk te zijn aan het ACL-ID nummer.
In de zogeheten Extended ACL rule table, zien we 4 regels staan: In dit voorbeeld regels, 10, 20, 30, 40.
In Sequence Number 10 staan we toe dat de default gateway 192.168.100.254 altijd toegang heeft tot IP-range 192.168.100.0. De default gateway heeft zodoende altijd toegang tot elk IP-nummer binnen de betrokken IP-range.
Onderstaand scherm laat zien hoe je dit invult. 
In Sequence Number 20 staan we toe dat IP-range 192.168.100.0 altijd toegang heeft tot de default gateway, namelijk IP-nummer 192.168.100.254. Alle IP-nummers uit de range mogen hierdoor altijd naar de default gateway.
Onderstaand scherm laat zien hoe je dit invult. 
In Sequence Number 30 blokkeren we elk IP-nummer uit de IP-range 192.168.100.0 ten opzichte van elkaar. Alle verkeer tussen alle IP-nummers uit VLAN100 worden hierdoor van elkaar geïsoleerd, uitgezonderd de default gateway, deze mocht immers al naar de rest van het IP-segment vanwege regel 10.
Onderstaand scherm laat zien hoe je dit invult
In Sequence Number 40 geven we de rest van alle netwerkverkeer toestemming voor de rest van de netwerk-functionaliteit, hierdoor wordt het overige netwerkverkeer wat niet aan de bovenstaande criteria voldoet ongehinderd doorgelaten.
Onderstaand scherm laat zien hoe je dit invult.
Je kunt een ALC koppelen aan een of meerdere poorten maar bij de wat recentere switches kun je een ACL ook aan een VLAN koppelen, deze mogelijkheid is in praktijk flexibeler en eenvoudiger in onderhoud dan het toewijzen van een ACL aan een of meerdere poorten. Nu de ACL uit het voorbeeld af is, kunnen we deze koppelen aan het betreffende VLAN op de switch. Dit kan met de optie “VLAN Binding table” onderin het Advanced ACL menu:
Onderstaand scherm laat zien hoe je dit invult.
Elke poort op de switch behorende bij VLAN 100 wordt nu gefilterd met ACL-ID 100.
Als alles goed ingevoerd is dan ziet de VLAN binding table er als volgt uit: 
Heb je meerdere switches in je netwerk en het zojuist geïsoleerde VLAN is ook van toepassing op deze switches, dan kan je dezelfde procedure volgen voor de rest van de switches.
Nu ben je op het punt aangekomen dat je kunt gaan testen. Een handige tool om te testen is uiteraard Wireshark.
Tip voor NETGEAR Insight Pro resellers
Maak je gebruik van NETGEAR Insight, dan kan je deze instellingen niet doen vanuit het Insight management console. Om de ACL’s alsnog te configureren, kan je de volgende stappen volgen:
- Ga met je browser naar het IP-Adres van de switch
- Log in en zet de Insight cloud optie in het configuratiescherm uit.
- Configureer de benodigde ACL filters.
- Schakel hierna de switch weer terug naar Insight management
- Maak als de switch weer terug is in Insight, voor de zekerheid een back-up van de instellingen
Heb je zelf een onderwerp voor een blog gerelateerd aan NETGEAR, stuur mij dan een email of schrijf in voor een van mijn volgende webinars.
Eric Lindeman
Sr. SE NETGEAR Benelux
