routing Vlans op L3 switches

[TheJukeBox]

Ik doe op dit moment een opdracht voor een bedrijf om twee zaken te bereiken:

Ten eerste heb ik een vraagstuk over (virtuele)firewalls.
Het bedrijf heeft op dit moment twee fysieke clusters (2x2) aan firewalls. Het ene cluster is een Cisco ASA het andere cluster is een Fortigate 100D (dit zijn de nieuwe firewalls).

Mijn vraagstuk is hoe ik vanuit de ASA naar de fortigate de Vfirewall (met daarin een stuk of 30-40 vlans) kan overzetten.
Ik heb de volgende oplossingen bedacht:

Alles handmatig overzetten, dus de Vlans uitlezen, rules op toe passen (hardening, sommige staan permit any\any) en opnieuw configureren

forticonverter (spreekt voor zich, maar kost centjes).

Een mix daarvan, dus uitlezen met forticonverter en handmatig overzetten zodat je de fouten eruit kunt halen en hardening kunt toepassen.

De tweede vraag die is gesteld is, kunnen de Vlans gerouteerd worden op L3 switches, zo ja, hoe?
De verbindingen komen op dit moment binnen op een aantal routers (out of scope) en het verkeer gaat vervolgens naar de firewalls. Hierop worden Vlans gerouteerd voor het interne verkeer. De firewalls zijn redundant verbonden aan een tweetal layer 3 Hp 5406ZL core switches. Hierna gaat het verkeer via de access layer (L2 switches) naar de servers etc.

De vraag is, waar kan ik het beste de routering kunnen laten plaatsvinden en hoe?
Het doel is om de load op de firewalls te verminderen.

Zelf denk ik om bepaalde interne Vlans (moet nog uitgezocht worden) op de core switches te routeren, en ik denk dat OSPF daarbij kan helpen.
Statische routes kunnen ook, in combinatie met ACL's. Ik heb dus geen idee wat "de beste" oplossing hierin is en of het allemaal gemakkelijk geconfigureerd kan worden.

Het netwerk:



Misschien nog een verduidelijking van de situatie:



Hoe regel ik hier de default routes af? Want als je een 0.0.0.0/0 naar de firewall doet ben ik bang dat je hierdoor niet meer je rules kan aanpassen op de Vlans.

Let me know!

[ Voor 13% gewijzigd door TheJukeBox op 06-04-2018 11:29 . Reden: Plaatje toevoegen ]

[Bigs]

De Fortigate 100D kan dankzij zijn ASIC altijd 2.5Gbps stateful forwarding doen, los van de IPS performance. Loop je tegen die grens aan? (Had je dan geen zwaardere firewall moeten aanschaffen?)

Als het filteren van het verkeer tussen VLANs niet noodzakelijk is dan kun je prima op een daarvoor geschikte L3 switch routeren. Je mogelijkheden qua beveiliging zijn voor de toekomst dan wel beperkt. Aannemende dat je access laag uit L2 switches bestaat en daf de core switches gestackt zijn zou ik gewoon eenvoudig beginnen, dus met statische routes.

[ Voor 16% gewijzigd door Bigs op 05-04-2018 11:19 ]

[DukeBox]

TheJukeBox schreef op donderdag 5 april 2018 @ 11:05:
De tweede vraag die is gesteld is, kunnen de Vlans gerouteerd worden op L3 switches, zo ja, hoe?

Meestal wel maar zonder te weten om welke switches het gaat is dat niet te vertellen.
Overheen gekeken.

[ Voor 4% gewijzigd door DukeBox op 05-04-2018 11:26 ]

[TheJukeBox]

@DukeBox , staat in het verhaal

[DukeBox]

TheJukeBox schreef op donderdag 5 april 2018 @ 11:23:
@DukeBox , staat in het verhaal

Ah. overheen gelezen, 5406ZL is makkelijk. Gewoon het commando 'ip routing' en de VLAN's die moeten routeren een IP geven op de switch.

Voor wat betreft je firewall rules.. het zijn nogal wat VLAN's automagisch overzetten kan natuurlijk veel tijd en geld schelen maar het hangt er vanaf of het nu allemaal netjes is.

Je kan ook tijdelijk met ICMP redirect werken.

[ Voor 5% gewijzigd door DukeBox op 05-04-2018 11:28 ]

[TheJukeBox]

Bigs schreef op donderdag 5 april 2018 @ 11:17:
De Fortigate 100D kan dankzij zijn ASIC altijd 2.5Gbps stateful forwarding doen, los van de IPS performance. Loop je tegen die grens aan? (Had je dan geen zwaardere firewall moeten aanschaffen?)


Als het filteren van het verkeer tussen VLANs niet noodzakelijk is dan kun je prima op een daarvoor geschikte L3 switch routeren. Je mogelijkheden qua beveiliging zijn voor de toekomst dan wel beperkt. Aannemende dat je access laag uit L2 switches bestaat en daf de core switches gestackt zijn zou ik gewoon eenvoudig beginnen, dus met statische routes.

Die 100D's had ik geen invloed op, die waren er al.

Het verkeer moet gerouteerd worden tussen bepaalde (interne) Vlans. Externe Vlans blijven gerouteerd via de firewall wegens het filteren.

Bedankt voor je tip om met statische routes te beginnen!

[TheJukeBox]

DukeBox schreef op donderdag 5 april 2018 @ 11:26:
[...]

Ah. overheen gelezen, 5406ZL is makkelijk. Gewoon het commando 'ip routing' en de VLAN's die moeten routeren een IP geven op de switch.

Voor wat betreft je firewall rules.. het zijn nogal wat VLAN's automagisch overzetten kan natuurlijk veel tijd en geld schelen maar het hangt er vanaf of het nu allemaal netjes is.

en dus zijn het statische routes?
Is het niet makkelijker om een routing protocol hiervoor te gebruiken wegens eventuele overhead oid?

[DukeBox]

TheJukeBox schreef op donderdag 5 april 2018 @ 11:28:
en dus zijn het statische routes?

Die begrijp ik niet helemaal, op deze manier routeren je switches de VLAN's. Wie de switch als route gebruikt moet je natuurlijk nog zelf per host configureren.
Je kan op je firewall ICMP redirect doen voor de interne routes als je je hosts niet wilt aanpassen. Andersom kan je je switches als default gw gebruiken en daar de routering afhandelen (5406 kan ook rip en v2 bgp).

[WhizzCat]

TheJukeBox schreef op donderdag 5 april 2018 @ 11:28:
[...]


en dus zijn het statische routes?
Is het niet makkelijker om een routing protocol hiervoor te gebruiken wegens eventuele overhead oid?

Ik denk dat het tijd wordt om sowieso even een fatsoenlijke tekening van de huidige situatie te maken en van hoe je het hebben wil. Tekst is leuk, maar ik zie op dit moment veel kreten door elkaar staan en een fatsoenlijk plan van aanpak kan je later een hoop ellende besparen.

[TheJukeBox]

WhizzCat schreef op donderdag 5 april 2018 @ 11:35:
[...]


Ik denk dat het tijd wordt om sowieso even een fatsoenlijke tekening van de huidige situatie te maken en van hoe je het hebben wil. Tekst is leuk, maar ik zie op dit moment veel kreten door elkaar staan en een fatsoenlijk plan van aanpak kan je later een hoop ellende besparen.

Heb een snelle tekening gemaakt en toegevoegd

[WhizzCat]

TheJukeBox schreef op donderdag 5 april 2018 @ 12:13:
[...]


Heb een snelle tekening gemaakt en toegevoegd

Routering zou ik inderdaad naar de HP's trekken (hebben we hier ook, werkt zelfs in Enterprise redelijk goed). Firewalls moeten IPS en zo doen, niet routen en switchen.

Stap 1.

- Bepaal of en waar je Layer2/3 wil hebben.
- Hoe ga je je uplinks naar de core maken? STP, Trunks? Dit heeft impact op de uitvoering van je plan en je Layer2/Layer3 ontwerp.
- Maak een IP nummer en VLAN plan en/of pas het huidige aan

Stap 2.

- Maak hier een briljante Visio tekening van. Maak gebruike van Lagen (Visio lagen he ) en zet zowel Layer2 als Layer3 d'r in. Is een k-klus, maar scheelt je later wel weer documenteren.

Ik mis vast nog iets, maar dat laat ik aan mijn collega's over

[TheJukeBox]

WhizzCat schreef op donderdag 5 april 2018 @ 12:34:
[...]


- Maak hier een briljante Visio tekening van. Maak gebruike van Lagen (Visio lagen he ) en zet zowel Layer2 als Layer3 d'r in. Is een k-klus, maar scheelt je later wel weer documenteren.

Ik heb een beste L2 tekening gemaakt, dat was er een hoop werk. een L3 gaat hem voor nu niet worden, ga ik teveel tijd mee verliezen.

Er bestaat er een IP plan met alles gedocumenteerd dus dat scheelt wel weer.

Ik ben wel benieuwd hoe jij die Vlans heb geconfigureerd op de switches. heb je een voorbeeld?
Waar ik vooral benieuwd naar ben is hoe het precies zit met de ACL's. Die Vlans zijn zo in te stellen.

[ Voor 7% gewijzigd door TheJukeBox op 05-04-2018 13:18 ]

[WhizzCat]

TheJukeBox schreef op donderdag 5 april 2018 @ 13:17:
[...]


Ik heb een beste L2 tekening gemaakt, dat was er een hoop werk. een L3 gaat hem voor nu niet worden, ga ik teveel tijd mee verliezen.

Er bestaat er een IP plan met alles gedocumenteerd dus dat scheelt wel weer.

Ik ben wel benieuwd hoe jij die Vlans heb geconfigureerd op de switches. heb je een voorbeeld?
Waar ik vooral benieuwd naar ben is hoe het precies zit met de ACL's. Die Vlans zijn zo in te stellen.

Als je jezelf in de vingers wil gaan snijden, moet je ACL's gebruiken. Dat doen wij dus niet. Ons netwerk is alleen iets groter, maar dat maakt niet heel veel uit.

Kwestie van VLAN's instellen met IP nummers en IP routing aanzetten. Op je client zorg je dan dat het IP nummer op de routerende switch de gateway is. Meer is 't niet. Dan zorgt die er wel voor dat je traffic van links naar rechts gaat

[TheJukeBox]

WhizzCat schreef op donderdag 5 april 2018 @ 13:28:
[...]


Als je jezelf in de vingers wil gaan snijden, moet je ACL's gebruiken. Dat doen wij dus niet. Ons netwerk is alleen iets groter, maar dat maakt niet heel veel uit.

En dan de security afvangen op de firewalls oid?

[WhizzCat]

TheJukeBox schreef op donderdag 5 april 2018 @ 13:32:
[...]


En dan de security afvangen op de firewalls oid?

Sowieso. Een ACL is qua security niet veel toevoegend. Een Firewall hoort daar wel thuis. De switch switched (L2) de router route (L3) en de Firewall firewalled (L7, als je mazzel hebt).

Je zou ipv de core routers een paar stevige NextGen L7 firewalls neer kunnen zetten, maar dan mag je de porotomonnee trekken

[TommyboyNL]

Als je uiteindelijk toch graag het routeren door je Fortigate wil laten doen, kan je ook al je VLANs in dezelfde zone zetten, en intra-zone traffic toestaan. Op die manier wordt al het verkeer binnen je zone gerouteerd in plaats van gefirewalled. Je hoeft dus geen any/any policies aan te maken.
Zelf zou ik er echter voor kiezen om alles door de L3 switches te laten routeren (daar zijn het immers L3 switches voor, anders had L2 volstaan).

[Fabian]

Waar ik vooral benieuwd naar ben is hoe het precies zit met de ACL's. Die Vlans zijn zo in te stellen.

Als je moet firewallen tussen vlans dan kun je deze toch het beste op de firewalls laten uitkomen. ACL's op switches zijn niet statefull. Voor je retourverkeer moet dus erg veel open gezet worden. Ga je een deel van je vlans laten routeren door de switches en een deel door de firewalls, dan wordt naar mijn idee het troubleshooten in de toekomst lastiger.

[TheJukeBox]

Fabian schreef op vrijdag 6 april 2018 @ 07:42:
[...]


Als je moet firewallen tussen vlans dan kun je deze toch het beste op de firewalls laten uitkomen. ACL's op switches zijn niet statefull. Voor je retourverkeer moet dus erg veel open gezet worden. Ga je een deel van je vlans laten routeren door de switches en een deel door de firewalls, dan wordt naar mijn idee het troubleshooten in de toekomst lastiger.

Maar, dan zit je nog steeds met het "load probeem".
Er gaan soms iso's tussen verschillende interne vlans door wat dus ook door de firewalls gaat. Hiermee wordt de verbinding soms wat dichtgetrokken. het is dus de bedoeling deze "pieken" weg te werken. En mij lijkt dat door de routering van deze vlans op de core switches te doen.

In principe raakt al het verkeer de core switches dus ik denk dat het met de troubleshooting niet eens zo heel gek verkeerd is.

Zie jij een andere oplossing?

Misschien distributed firewalls oid?

[Kabouterplop01]

Waarom denk je dat als de routering via de firewalls loopt het verkeer ook via de firewalls loopt?

[TheJukeBox]

Kabouterplop01 schreef op vrijdag 6 april 2018 @ 13:37:
Waarom denk je dat als de routering via de firewalls loopt het verkeer ook via de firewalls loopt?

Omdat dit de access is naar binnen/buiten toe, daarom.

Al het verkeer loopt ook over de core switches.

[Kabouterplop01]

Ah ik had duidelijker moeten zijn. Ik bedoelde het interVLAN verkeer.
Ik doel op het routeren op de firewalls.
Als de routering bekend is en de mac-adressen zijn bekend na het ARP-en dan weten de switches toch dat de data niet via de L3 interfaces hoeft te lopen?

[it0]

Kabouterplop01 schreef op vrijdag 6 april 2018 @ 14:02:
Ah ik had duidelijker moeten zijn. Ik bedoelde het interVLAN verkeer.
Ik doel op het routeren op de firewalls.
Als de routering bekend is en de mac-adressen zijn bekend na het ARP-en dan weten de switches toch dat de data niet via de L3 interfaces hoeft te lopen?

Alles wat niet binnen je subnet zit moet geroute worden.
Persoonlijk zou ik de routing van de firewall scheiden waar mogelijk.

[DukeBox]

Juist met die HP's is het heel mooi om de interVLAN's te routeren. Je kan je 2 'cores' als failover (VRRP) van elkaar instellen.

Kabouterplop01 schreef op vrijdag 6 april 2018 @ 14:02:
Als de routering bekend is en de mac-adressen zijn bekend na het ARP-en dan weten de switches toch dat de data niet via de L3 interfaces hoeft te lopen?

Nee alleen als je ICMP redirect gebruikt (én je switches routeren).

[ Voor 19% gewijzigd door DukeBox op 06-04-2018 14:10 ]

[Kabouterplop01]

Dat is dan toch prima met ICMP redirect en dot1q trunks? Maar ik snap it0's punt. Ik ken het ip nummerplan niet (heb de tekening niet bekeken) maar OSPF zou dan een snelle oplossing kunnen zijn. Ook als er gebruik wordt gemaakt van meerdere RFC1918 reeksen kun je die in een andere area's hangen. en de default route naar buiten zetten.
Het heeft wel een nadeel welk al is gesteld de ACL's op de L3 interfaces zijn niet statefull. Aan de andere hand heb je dan wel meer controle over wat er in en uitgaat.

[TheJukeBox]

Kabouterplop01 schreef op vrijdag 6 april 2018 @ 14:02:
Ah ik had duidelijker moeten zijn. Ik bedoelde het interVLAN verkeer.
Ik doel op het routeren op de firewalls.
Als de routering bekend is en de mac-adressen zijn bekend na het ARP-en dan weten de switches toch dat de data niet via de L3 interfaces hoeft te lopen?

Mijn vraag is juist hoe ik het moet routeren op de cores, dat de firewalls nu routeren is duidelijk. Bekijk het tweede plaatje eens goed, misschien dat het wat verduidelijking geeft.

[DukeBox]

TheJukeBox schreef op vrijdag 6 april 2018 @ 14:37:
Mijn vraag is juist hoe ik het moet routeren op de cores..

Is toch al meerdere keren gemeld ? Hosts default naar de cores. Cores default naar de firewall(s).

[TheJukeBox]

DukeBox schreef op vrijdag 6 april 2018 @ 15:18:
[...]

Is toch al meerdere keren gemeld ? Hosts default naar de cores. Cores default naar de firewall(s).

Klopt. maar als je dit wilt instellen op deze manier, dan maak je dus een default trunk aan op de cores naar de firewalls. Kunnen de firewalls dan alsnog het verkeer filteren om met bepaalde poorten naar buiten te kunnen? Of moet je per Vlan een soort van default route naar de firewalls maken?

[Vorkie]

TheJukeBox schreef op vrijdag 6 april 2018 @ 16:31:
[...]


Klopt. maar als je dit wilt instellen op deze manier, dan maak je dus een default trunk aan op de cores naar de firewalls. Kunnen de firewalls dan alsnog het verkeer filteren om met bepaalde poorten naar buiten te kunnen? Of moet je per Vlan een soort van default route naar de firewalls maken?

Zolang de Core geen routes heeft buiten de bekende netwerken gaat het natuurlijk nergens naartoe.

Core switch
Vlan1 10.10.10.1/24
Vlan2 10.10.11.1/24
Vlan3 10.10.12.1/24
Vlan4 10.10.13.1/24
Deze netwerken kunnen elkaar vinden.

Route 0.0.0.0 0.0.0.0 10.10.13.254

Al onbekend verkeer wordt over de lijn gegooid naar de Firewall.

Firewall
Vlan4
10.10.13.254/24

Routes toevoegen voor bovenstaande netwerken via 10.10.13.1.

Verder kan je dan gewoon Firewall rules maken op basis van source en destination.

Even in een notendop hoor via mobiel.

[TheJukeBox]

Vorkie schreef op vrijdag 6 april 2018 @ 16:46:
[...]

Zolang de Core geen routes heeft buiten de bekende netwerken gaat het natuurlijk nergens naartoe.

Core switch
Vlan1 10.10.10.1/24
Vlan2 10.10.11.1/24
Vlan3 10.10.12.1/24
Vlan4 10.10.13.1/24
Deze netwerken kunnen elkaar vinden.

Route 0.0.0.0 0.0.0.0 10.10.13.254

Al onbekend verkeer wordt over de lijn gegooid naar de Firewall.

Firewall
Vlan4
10.10.13.254/24

Routes toevoegen voor bovenstaande netwerken via 10.10.13.1.

Verder kan je dan gewoon Firewall rules maken op basis van source en destination.

Even in een notendop hoor via mobiel.

Werkt dit ook als je bv met Vlan 10 intern naar Vlan 20 moet (bv prt 21) en volgens met Vlan 10 ook naar het Inet moet met bv prt 80?

Heb echt het gevoel dat ik veel te ingewikkeld denk..

[Vorkie]

TheJukeBox schreef op vrijdag 6 april 2018 @ 16:52:
[...]


Werkt dit ook als je bv met Vlan 10 intern naar Vlan 20 moet (bv prt 21) en volgens met Vlan 10 ook naar het Inet moet met bv prt 80?

Heb echt het gevoel dat ik veel te ingewikkeld denk..

Alle ip reeksen niet bekend op de l3 switch wordt doorgestuurd naar de Firewall met deze route, dus als op de Firewall vlan20 leeft met ip adres 10.10.15.0/24 zal die daar naartoe gaan want de l3 switch kent geen interface met die range.

Een Router doet niets met poortjes. Deze doet wat het moet doen, regelen van pakketjes naar de juiste locatie, udp tcp icmp alles.

Verder vindt ik op professioneel vlak het belangrijk dat je opdrachten doet die je ook daadwerkelijk aan kan, in dit geval zou ik leergeld investeren in een netwerkdude die het uitvoert en jou gelijk kan leren.

[ Voor 23% gewijzigd door Vorkie op 06-04-2018 16:58 ]

[DukeBox]

TheJukeBox schreef op vrijdag 6 april 2018 @ 16:31:
Klopt. maar als je dit wilt instellen op deze manier, dan maak je dus een default trunk aan op de cores naar de firewalls.

Nee, je routeert.

Kunnen de firewalls dan alsnog het verkeer filteren om met bepaalde poorten naar buiten te kunnen? Of moet je per Vlan een soort van default route naar de firewalls maken?

Nee, routeren heeft niets met firewalling te maken.

[Fabian]

Er gaan soms iso's tussen verschillende interne vlans door wat dus ook door de firewalls gaat. Hiermee wordt de verbinding soms wat dichtgetrokken. het is dus de bedoeling deze "pieken" weg te werken. En mij lijkt dat door de routering van deze vlans op de core switches te doen.

In principe raakt al het verkeer de core switches dus ik denk dat het met de troubleshooting niet eens zo heel gek verkeerd is.

Zie jij een andere oplossing?

Als je niet hoeft te firewallen tussen je interne vlans, is routeren op een L3 switch prima. Zodra je ook maar iets met een ACL wil doen, Layer 3 of 4, dan heb je niets aan een L3 switch. Zoals eerder gemeld zijn de ACL's zijn niet stateful, dus je moet voor beide verkeersstromen een allow opnemen. Van client naar server poort 80, van server poort 80 naar client (1024 - 65531 ?). waarmee dus alles open staat.

Wil je wel firewallen tussen je interne vlans dan heb je simpelweg een zwaardere firewall nodig en bijvoorbeeld 2x 4x 1gig etherchannel tussen je switches en je firewall(s).

[bigfoot1942]

Je wil een transit vlan gebruiken tussen je core switches en je firewall.
Op deze manier kan je al je lokale verkeer 'lokaal' houden, zonder dit door de firewalls te hoeven trekken. Ook kan je je broadcast domains beperken, qua aantal deelnemers maar ook kan je zorgen dat dit beperkt blijft tot specifieke switches.

Vorkie schreef op vrijdag 6 april 2018 @ 16:46:
[...]

Zolang de Core geen routes heeft buiten de bekende netwerken gaat het natuurlijk nergens naartoe.

Core switch
Vlan1 10.10.10.1/24
Vlan2 10.10.11.1/24
Vlan3 10.10.12.1/24
Vlan4 10.10.13.1/24
Deze netwerken kunnen elkaar vinden.

Route 0.0.0.0 0.0.0.0 10.10.13.254
Al onbekend verkeer wordt over de lijn gegooid naar de Firewall.

Firewall
Vlan4
10.10.13.254/24
Routes toevoegen voor bovenstaande netwerken via 10.10.13.1.
Verder kan je dan gewoon Firewall rules maken op basis van source en destination.

Dit dus maar duidelijk vind ik de uitleg niet: vlan 1-3 zijn client vlans en vlan4 is dan het transit vlan wat alleen gebruikt wordt tussen core en firewall.

[ Voor 58% gewijzigd door bigfoot1942 op 09-04-2018 17:26 ]

[Vorkie]

bigfoot1942 schreef op maandag 9 april 2018 @ 17:21:
Je wil een transit vlan gebruiken tussen je core switches en je firewall.
Op deze manier kan je al je lokale verkeer 'lokaal' houden, zonder dit door de firewalls te hoeven trekken. Ook kan je je broadcast domains beperken, qua aantal deelnemers maar ook kan je zorgen dat dit beperkt blijft tot specifieke switches.


[...]

Dit dus maar duidelijk vind ik de uitleg niet: vlan 1-3 zijn client vlans en vlan4 is dan het transit vlan wat alleen gebruikt wordt tussen core en firewall.

Transit vlan is in mijn mening nog steeds een design naam, het blijft een vlan, enig verschil is dat het alleen gebruikt wordt om verkeer te transporteren tussen netwerkapparatuur, core layer naar distribution layer. Of in dit geval tussen "core" naar Firewall, zonder alle ellende van de diverse vlans zoals jij ook stelt

Voor de netheid kan je inderdaad het een transit vlan noemen.

[_-= Erikje =-_]

Vorkie schreef op vrijdag 6 april 2018 @ 16:46:
[...]


Core switch
Vlan1 10.10.10.1/24
Vlan2 10.10.11.1/24
Vlan3 10.10.12.1/24
Vlan4 10.10.13.1/24
Deze netwerken kunnen elkaar vinden.

en hebben zonder verdere ACLs op de switch (of andere truken) dus ongelimiteerd access naar elkaar

Route 0.0.0.0 0.0.0.0 10.10.13.254

Al onbekend verkeer wordt over de lijn gegooid naar de Firewall.

Firewall
Vlan4
10.10.13.254/24

Routes toevoegen voor bovenstaande netwerken via 10.10.13.1.

Verder kan je dan gewoon Firewall rules maken op basis van source en destination.

met uitzondering van wat je dus routeert op je l3 switch :-)

[TheJukeBox]

bigfoot1942 schreef op maandag 9 april 2018 @ 17:21:
Je wil een transit vlan gebruiken tussen je core switches en je firewall.
Op deze manier kan je al je lokale verkeer 'lokaal' houden, zonder dit door de firewalls te hoeven trekken. Ook kan je je broadcast domains beperken, qua aantal deelnemers maar ook kan je zorgen dat dit beperkt blijft tot specifieke switches.

Maar, het Vlan moet ook het inet op kunnen, ofwel, hij moet niet alleen lokaal blijven. (zoals uitgelegd in het 2e plaatje)

maar, ik ga ff testen en uitproberen, kijken wat goed werkt

[bigfoot1942]

Ontsluiting zou je dan dus op je core switch moeten inregelen.
3 vlans bv
192.168.10.1/24 interface op core in vlan 10
192.168.20.1/24 interface op core in vlan 20
192.168.30.1/24 interface op core in vlan 30
192.168.100.254/24 interface op core in vlan 100 (transit vlan) met firewall op 192.168.100.1

Vervolgens maak je een route aan in je core switch: 0.0.0.0/0 (default route) naar 192.168.100.1

[Zoetjuh]

Wel een juiste VLAN-map op de switch configureren om inter-VLAN routing op je switch te voorkomen lijkt me zo. Anders zal alsnog alleen internet-traffic via je firewall lopen.

[TheJukeBox]

Zoetjuh schreef op vrijdag 13 april 2018 @ 11:16:
Wel een juiste VLAN-map op de switch configureren om inter-VLAN routing op je switch te voorkomen lijkt me zo. Anders zal alsnog alleen internet-traffic via je firewall lopen.

Maar dat is ook de bedoeling voor sommige vlans!
Alleen, mogen maar bepaalde poorten naar elkaar.

Dus bijvoorbeeld, verkeer voor prt 80 vanuit Vlan 10 moet vanaf een bepaald IP van Vlan 10 naar 20, de rest van het prt 80 verkeer moet naar buiten toe.

Het gaat om heel gerichte source/destination adresses.

Is PBR hier iets voor?

[DukeBox]

TheJukeBox schreef op woensdag 11 april 2018 @ 14:07:
Maar, het Vlan moet ook het inet op kunnen, ofwel, hij moet niet alleen lokaal blijven.

En dat is nu precies hoe routing werkt

TheJukeBox schreef op vrijdag 13 april 2018 @ 13:38:
Dus bijvoorbeeld, verkeer voor prt 80 vanuit Vlan 10 moet vanaf een bepaald IP van Vlan 10 naar 20, de rest van het prt 80 verkeer moet naar buiten toe.

Om mijzelf te quoten:

DukeBox schreef op vrijdag 6 april 2018 @ 17:33:
Nee, routeren heeft niets met firewalling te maken.

[ Voor 48% gewijzigd door DukeBox op 13-04-2018 13:43 ]

[Vorkie]

@bigfoot1942
Het is precies hetzelfde wat ik had gepost, beetje raar om dit nogmaals te herhalen maar dan met andere IP adressen? [/small]

Verder @TheJukeBox
Internet heeft ook gewoon IP adressen, bijvoorbeeld Google DNS. 8.8.8.8, dit adres is niet bekend op de router, door route 0.0.0.0 via de firewall interface te sturen zal deze dus, omdat ie niet bekend is, richting de firewall worden gerouteerd.

[ Voor 38% gewijzigd door Vorkie op 13-04-2018 13:44 ]

[TommyboyNL]

Tip van Flip: Zoek een boek voor het Cisco ICND-1 (en eventueel ICND-2, samen zijn die CCNA routing&switching) examen, daarin staat alle kennis die je nodig hebt om dit tot een goed einde te brengen. Het lijkt er nu namelijk op dat je geen idee hebt wat switching, routing, en firewalling zijn, hoe die samen hangen, en hoe dat relateert aan wat jij nu voor elkaar probeert te krijgen.

[bigfoot1942]

TheJukeBox schreef op vrijdag 13 april 2018 @ 13:38:
[...]
Het gaat om heel gerichte source/destination adresses.

Is PBR hier iets voor?

PBR moet je zien als het hijacken van verkeer, iemand denkt naar www.nu.nl te gaan maar door middel van PBR kan je zorgen dat je op een (bijvoorbeeld) lokale reverse proxy uitkomt.

PBR heb ik nog nergens echt (goed) gebruikt zien worden.
Wat jij wil, vanaf een specifiek IP mag je naar poort 80 op een ander specifiek IP, is firewall functionaliteit.
Met een PBR kan je zorgen dat je ipv de webinterface van je storage, je dus ineens nu.nl te zien krijgt (met certificate warning etc). Niet echt een beveiligingsfeature, wel een hoge kans om er een zooi van te maken.

Je kan met ACL's aan de slag gaan als 'workaround', maar als je het simpel en beheerbaar wil houden zou ik gewoon een firewall hiervoor inzetten.

Ook is een goed netwerkontwerp belangrijk, het is positief dat je dit zelf ook inziet, maar wellicht kan je beter hiervoor iemand inhuren - en ik schat zo in dat je prima kan meedenken / groeien binnen een omgeving met een juist ontwerp.

@Vorkie
Op zich heb je gelijk. Toch vond ik je uitleg niet voldoende helder (qua afwijking mbt transit vlan) dat ik je uitleg initieel helemaal verkeerd had begrepen, maar na opnieuw lezen werd het pas duidelijk.
Vervolgens heb ik hem dunnetjes over gedaan, om juist dat verschil van het transit vlan uit te leggen. Worst case zou TS namelijk clients in dit transit vlan gaan plaatsen en met lokale persistent routes gaan prutsen...

[Predator]

Een FW design begint altijd met het verdelen van zones/
Je begint met je interne netwerken te groepen in zones. Hosts binnen een zone kunnen vrij communiceren, communicatie tussen de zones wil je beveiligen.

Een vb is bv:
- Datacenter (vlans met servers/Datacenter infrastructuur)
- Clients (Pc's, printers, enz)
- Internet access
- 1 of meerdere DMZ's (zones met internet services zoals webservers)
- ....

Elke zone is een FW interface (dat kunnen ook virtuele interfaces zijn).
Tussen elke zone kan je de security Policy implementeren op de firewall.
Je firewall routeert tussen de zones, en naar het internet.

Dat is zowat de basic setup. Het kan uiteraard een stuk complexer, of nog veel simpeler.

Je gebruikt de L3 switches om de inter-vlan routering te doen tussen de verschillende vlan's in eenzelfde zone. In de praktijk is dat meestal tussen de datacenter vlan's en tussen clients vlan's.
De L3 switches in de clients & datacenter zone wijzen via hun default route naar de FW cluster.
Of je nu statische of dynamische routering doet, maakt weinig uit.

Binnen elke zone heb je geen performance impact met routering tussen vlans via de L3 swiches.
Verkeer dat door de FW gaat, heeft wel een performance hit.
Als je wil dat alle clients geen performance hit hebben richting datacenter, dan moet je de zones samenvoegen. Je hebt dan wel geen security meer tussen beide.
Een tussenoplossing is bv van een management netwerk te creëren voor IT, die wel in de datacenter zone zit.

ACL's op vlan interfaces zetten in L3 switches is inderdaad geen structurele oplossing. Het kan voor kleine zaken. Zoals bv een zeer kritiek netwerk (bv infractuur services zoals UPS/Airco) extra inperken.
Anders wordt het een grote knoeiboel van ACL's, waar niemand nog aan uit geraakt.

bigfoot1942 schreef op zondag 15 april 2018 @ 14:33:
[...]

PBR moet je zien als het hijacken van verkeer, iemand denkt naar www.nu.nl te gaan maar door middel van PBR kan je zorgen dat je op een (bijvoorbeeld) lokale reverse proxy uitkomt.

PBR heb ik nog nergens echt (goed) gebruikt zien worden.
Wat jij wil, vanaf een specifiek IP mag je naar poort 80 op een ander specifiek IP, is firewall functionaliteit.
Met een PBR kan je zorgen dat je ipv de webinterface van je storage, je dus ineens nu.nl te zien krijgt (met certificate warning etc). Niet echt een beveiligingsfeature, wel een hoge kans om er een zooi van te maken

Wat je schrijft is geen correct VB voor PBR. De reverse proxy zal namelijk niets kunnen aanvangen met de data, want het destination IP adres is niet de reserve proxy. PBR past geen adressen aan.
Hiervoor kan je NAT inzetten.

Routering houdt normaal gezien enkel rekening met het destination IP in het IP packet. Via PBR kan je de routering beslissing van meer zaken laten afhangen. Via route-maps kan dat heel uitgebreid.
In de praktijk zie je dat inderdaad niet zo vaak.
Een vb is bv het volgende:
Je hebt tussen 2 sites een MPLS WAN link (hoge SLA, QoS support, betrouwbaar, maar duur) en een site2site VPN over een low cost (high speed) internet verbinding. Via PBR kan je minder belangrijk verkeer over de VPN routeren (bv http, network backups, ...), en belangrijker verkeer (voice, core apps) over de betrouwbare MPLS link sturen.
Een ander vb is bv een router met 2 internet verbindingen. Via PBR kan je een deel van de clients over 1 link sturen, en ander deel van de clients over de andere. Bv aan de hand van het source IP.
PBR kan heel erg krachtig zijn, maar het zijn inderdaad zeer specifieke business cases.

[ Voor 33% gewijzigd door Predator op 16-04-2018 08:49 ]

[Simon1984]

Ik blijf me erover verbazen waarom men altijd een /24 pakt met een (interconnect/transit/koppel) vlan.
Max een /28, voor hele grote groei mogelijkheden .

Veelal zou ik ook een ander subnet pakken voor het ' logische'. verschil.

bv.
vlan 10 data - 192.168.10.0/24
vlan 20 voice - 192.168.20.0/24
vlan 30 printers - 192.168.30.0/24
vlan 100 IC - 10.255.255.240/28
vlan 172 - Gasten WiFi - 172.31.12.0/24(23)

Met netwerken gebruik je eigenlijk 2 termen.......trusted en untrusted, trusted verkeer mag met elkaar kletsen, untrusted verkeer niet (afvangen door ACL/FW).

Uiteraard is de keuze reuze maar ook zeer bepalend voor je architectuur.....
Je kunt een FW gaan bezwaren met allerlei taken (waar die officieel niet altijd voor is bedoelt) en zie het vaak genoeg dat er alles over de firewall loopt (L3+) en uiteindelijk een grote backup terugzetten de hele omgeving platlegt.....

Let goed op welke data stromen je hebt, waar moet je veel bandbreedte hebben en waar wil je je Security hebben (gasten WiFi / DMZ).


Maar ik ben het eens met eerdere berichten en niet om iemand af te vallen, want we moeten het allemaal leren. Maar als je dit zakelijk gaat doen, moet je wel weten hoe/wat.
Basis kennis networking is wel vereist.

Hoevaak ik wel niet op Datacenter omgevingen bent geweest met a-sync routeringen en nog meer slechte dingen terwijl de klant enorm afhankelijk was van zijn netwerk en de snelheid/stabiliteit.

Misschien goed om eens met iemand te sparren van hoe/wat, die wat meer ervaring heeft, misschien kan hij je wat standaard zaken uitleggen en onderbouwen waarom men voor bepaalde keuzes kiest.

[TheJukeBox]

@Simon1984 ,Wil je sparren?

[Predator]

Simon1984 schreef op vrijdag 20 april 2018 @ 12:07:
Ik blijf me erover verbazen waarom men altijd een /24 pakt met een (interconnect/transit/koppel) vlan.
Max een /28, voor hele grote groei mogelijkheden .

Veelal zou ik ook een ander subnet pakken voor het ' logische'. verschil.

bv.
vlan 10 data - 192.168.10.0/24
vlan 20 voice - 192.168.20.0/24
vlan 30 printers - 192.168.30.0/24
vlan 100 IC - 10.255.255.240/28
vlan 172 - Gasten WiFi - 172.31.12.0/24(23)

Er is niet echt een goed of fout antwoord voor subnetting. In theorie moet je subnet groot genoeg zijn voor groei/migraties, maar verder wel zo klein mogelijk. In de praktijk moet het vooral groot genoeg zijn, en klein genoeg om een globaal adres schema te maken.

Echter, in veel kleine tot middelgrote omgevingen is er genoeg ruimte om gewoon een standaard mask aan te houden van /24. Het zorgt voor eenvoudiger configuraties en ACLs/route-maps/prefix lists zijn veel eenvoudiger. Ook is de kans op (typ)fouten kleiner.
Tenminste als we over private adressering spreken.

Ik moet in mijn omgeving wat zuiniger zijn, maar ik heb zowel /24 als /28 transit segmenten, afhangkelijk van de ruimte in het supernet voor de zone.

In ipv6 wordt er zelfs aangeraden van gewoon overal op /64 te werken, ook voor p2p links. standardisatie. Er is natuurlijk wel wat meer ruimte


Persoonlijk vind ik je voorbeeld niet zo goed. Je gebruikt ranges in alle 3 de private ip ranges. De kans dat je bij een fusie overlap gaat krijgen is groot. Ik ben meer voorstander van in 1 private segment te blijven.

[DukeBox]

Eens met @Predator voor wat betreft verschillende ranged. Ook bij VPN's is het handiger een range te tunnelen dan meerdere.

[Simon1984]

DukeBox schreef op zaterdag 21 april 2018 @ 18:46:
Eens met @Predator voor wat betreft verschillende ranged. Ook bij VPN's is het handiger een range te tunnelen dan meerdere.

Opzich niet mee eens, behalve als het gaat om een EVPN oid en dan nog meer gemakzucht dan wat anders.....alsof voor je VPN dezelfde poorten gelden voor de verschillende subnetten...

En helemaal eens met hoe subnetting(/supernetten) doet niets is goed/fout maar puur mijn voorkeur zodat het voor mij duidelijk en overzichtelijk is. Je kunt ook met octetten zaken gaan categoriseren als je idd niet alle verschillende interne subnetten wilt gebruiken 😝😎.
De kans op een dubbele IP reeks heb je altijd bij overnames oid.

Voornarmelijk......als je maar snapt wat je doet en het (technisch) kunt onderbouwen zit je vaak al goed.
Maar samen sparren is nooit verkeerd .