Switch als next-hop voor meerdere ip-reeksen

[alm]

Ik heb een vraagstuk waarover ik aan het twijfelen ben geraakt of het kan werken of niet.

Op het werk hebben we drie publieke IP-reeksen en twee firewalls waarover deze verdeeld zijn.
Reeks A is de primaire reeks en bestaat uit 8 adressen. De beide firewalls gebruiken ieder een IP-adres uit deze A reeks. Reeks B en C worden via een next-hop principe afgeleverd op de tweede firewall (via het IP-adres uit reeks A). Dit functioneert op zich prima, ware het niet dat we meer adressen op de eerste firewall willen kunnen gebruiken en dat kan nu niet omdat we de adressen uit reeks B en C niet kunnen verdelen over firewall 1 en 2. Achter de firewalls hangen weer andere interne netwerken.

Mijn idee om dit op te lossen was om een managed (bij voorkeur Cisco) switch voor de firewalls te plaatsen en daar een adres uit reeks A op te zetten (op het vlan dat aan de publieke verbinding hangt) en dan parallel als secondary IP adressen een adres uit reeks B en C erop. De next-hop zou dan moeten verwijzen naar het IP-adres van de switch. De overige adressen uit reeks B en C worden dan verdeeld over de twee firewalls (als secondary IP-adressen). Momenteel zijn deze allemaal op firewall 2 geconfigureerd. Instellen op firewall 1 heeft momenteel geen zin, dat wordt door de firewall geblokkeerd en heeft bovendien als nadeel dat als firewall 2 down is, dat dat verkeer dan ook niet aankomt op firewall 1.

Kan dit inderdaad werken? Kan dit zoals ik dacht met een L2 switch of is daar toch een switch met L3 functies voor nodig?

Er is maar één enkel VLAN tussen de firewalls en de router van de provider, momenteel nog een unmanaged L2 switch. Er wordt en zal geen DHCP op de publieke reeksen gebruikt worden, alles is statisch geconfigureerd.

Iemand die weet of het kan of niet en wat er nodig is?

[jvanhambelgium]

Dan heb je echt een L3-switch nodig, niet zomaar en L2-switch maar je toevallig een management IP kan inkloppen...

Voor de rest zou zo'n setup wel kunnen werken ja, je gaat dan gewoon een extra "router" voor je ISP router zetten en gaat dan zelf kunnen controleren wat je wil routen naar welke FW-interface.

[ik222]

Hoe ziet je internetverbinding er precies uit? Heb je één subnet met gateway bij je provider waarover dan nog eens 2 x een subnet (/29 ?) naar specifieke adressen in dat subnet gerouteerd worden? Uit je startpost is me dat namelijk niet helemaal duidelijk.

[alm]

ik222 schreef op woensdag 02 april 2014 @ 08:35:
Hoe ziet je internetverbinding er precies uit? Heb je één subnet met gateway bij je provider waarover dan nog eens 2 x een subnet (/29 ?) naar specifieke adressen in dat subnet gerouteerd worden? Uit je startpost is me dat namelijk niet helemaal duidelijk.

Ja, dat klopt. De gebruikte reeksen komen allemaal vanaf dezelfde provider, alleen het primaire subnet is direct aanwezig op de gateway van de provider. Het mooiste zou zijn om de overige reeksen gewoon parallel binnen te krijgen aan de primaire reeks, maar dat wordt niet ondersteund werd ons gezegd. De provider is KPN en zij managen ook de router (heb dus geen toegang daartoe). Ze bieden voor de extra subnets alleen de next-hop methode aan en dat dient een device te zijn in ons netwerk.

Ik zoek een manier om de drie reeksen meer te kunnen verdelen over de twee aangesloten firewalls. Mijn idee was om dit te doen met een stack van twee switches en dan de aansluitingen zoveel mogelijk te verdelen zodat een maximaal mogelijke redundantie (ondanks blijvende beperkingen) ontstaat.

[Verwijderd]

Indien je toch van plan bent om te investeren, zou het niet beter zijn om meteen 2x hetzelfde type/model firewall aan te schaffen en deze in een cluster configureren? (Poprietary, VRRP,... - afhankelijk van het merk -> anyway, iets dat je 1 virtueel IP geeft voor beide firewalls).

Je provider kan dan de bijkomende IP subnets rechtstreeks hiernaartoe laten routeren. Je hebt dan volgens mij een pak meer flexibiliteit, en meteen ook redundancy op firewall niveau, zonder bijkomende point of failure op de 'internet' stack.

Misschien kan je dit zelfs al op de huidige firewalls, tenzij dit twee totaal verschillende merken/modellen zijn?

[ik222]

Op zich dat je niet verschillende subnets met allemaal een andere gateway bij KPN via hetzelfde VLAN binnen kan krijgen klinkt wel vrij logisch. De enige optie zou dan zijn één groot subnet te hebben (bijvoorbeeld een /27)

Maar goed als dat niet kan dan heb je twee opties, de mooiste is in mijn ogen dat je gaat werken met één centrale firewall (al dan niet in een HA setup) waar je beide reeksen naartoe laat routeren.

De andere optie is inderdaad een router (bijvoorbeeld een L3 switch) tussen je modem en je firewall plaatsen die je het verkeer laat verdelen. Die geef je dan een IP in subnet A (dus de reeks met gateway bij je provider) en daar laat je beide /29 subnets naartoe routeren, vervolgens kun je dan die switch ook een VLAN interface geven in beide /29's en die als gateway gebruiken voor je firewalls. Aan je firewalls biedt je dan een trunk met beide VLAN's daarin aan. Een L2 switch gaat het hem in elk geval niet doen.

[Paul]

Je hebt daar inderdaad een router voor nodig, al dan niet in de vorm van een L2 switch.

Echter, je firewalls krijgen dan de adressen op hun 'WAN'-interface en moet je dus gaan NATten naar de interne servers. Als je firewall de next-hop is dan hoeven ze alleen te routeren en zit je dus niet met alle gezeik dat NAT op kan leveren.

Het beste is inderdaad ofwel heel B op één firewall en heel C op de andere (dan heb je het ook verdeeld, ik weet alleen niet of dat een wenselijke verdeling is) of je firewalls in een HA-opstelling zetten, en alle netwerken (zowel B en C als ook alle interne netten) op dat ene cluster configureren.

Nog een optie, maar dat kost een heleboel adressen, is B en C verder opdelen in subnetten...

[pablo_p]

De mooiste oplossing in een HA cluster. Dat is ook mijn eerste advies

Als er echter redenen zijn om twee firewalls te houden (bv scheiding van beheerdomeinen) is (uitgaande dat nu al NAT gebruikt wordt), is de flexibelste oplossing om een L3 switch of router in subnet A te plaatsen het het externe adres van de tweede firewall.
Vervolgens maak je een interconnectie subnetje (mag 192.168.xx of 10.x.x.x zijn) waarin een VLAN interface van de L3 switch zit + interfaces van de de eerste en de tweede firewall. Door middel van host routes (/32) of eventueel sub-subnets kan je dan geregisteerde adressen naar de verschillende firewalls zetten. Maximale flexibiliteit. Je kan functies makkelijk van firewall 1 naar firewall 2 verhuizen. Eventueel kan je zoiets gebruiken als tussenfase in een migratie naar een enkele firewall. En met /32 route-statements kan je zelfs IP adressen uit subnet A gebruiken.

Ik ben geen voorstander van een oplossing van firewalls die beiden op Interconnectie subnet B en C zitten, want dan krijg je ellende met routering van uitgaande sessies. Handiger is als systemen maar een default route hebben.

[alm]

Bedankt voor jullie reacties.

Verwijderd schreef op woensdag 02 april 2014 @ 10:54:
Indien je toch van plan bent om te investeren, zou het niet beter zijn om meteen 2x hetzelfde type/model firewall aan te schaffen en deze in een cluster configureren? (Poprietary, VRRP,... - afhankelijk van het merk -> anyway, iets dat je 1 virtueel IP geeft voor beide firewalls).

Dat hebben we al, voor de eenvoud heb ik firewall 1 en firewall 2 voorgesteld als losse firewalls, maar in de praktijk zijn het twee firewall clusters.

Je provider kan dan de bijkomende IP subnets rechtstreeks hiernaartoe laten routeren. Je hebt dan volgens mij een pak meer flexibiliteit, en meteen ook redundancy op firewall niveau, zonder bijkomende point of failure op de 'internet' stack.

Misschien kan je dit zelfs al op de huidige firewalls, tenzij dit twee totaal verschillende merken/modellen zijn?

Deze situatie bestond al voor ik hier kwam werken en het idee daarvoor was om nog meer onafhankelijkheid tussen de achterliggende netwerken te creëren. Onderhoud op firewall-cluster 1 heeft geen effect op firewall-cluster 2 en andersom.

ik222 schreef op woensdag 02 april 2014 @ 11:03:
Op zich dat je niet verschillende subnets met allemaal een andere gateway bij KPN via hetzelfde VLAN binnen kan krijgen klinkt wel vrij logisch. De enige optie zou dan zijn één groot subnet te hebben (bijvoorbeeld een /27)

Eén groot subnet zou ook mijn voorkeur hebben, maar dat is schijnbaar wat lastig volgens de mensen die ik gesproken heb.

Ik weet wel dat het mogelijk is om meerdere subnets parallel te hangen, sterker nog dat was bij m'n vorige werk ook gedaan op het netwerk (niet mijn keus in die situatie) waarbij een router op een enkele interface drie IP-adressen had (in ieder subnet een adres). Nadeel in die situatie was dat je maar in één van de subnets een DHCP server kon hebben draaien, want anders wist je nooit in welk netwerk je uit zou komen. Niet handig als je statische DHCP-toewijzingen wilt doen.

Door afhankelijkheid van mensen uit een buitenlandse hoofdvestiging zijn we daar nooit echt vanaf gekomen, behalve door uitfasering van die subnetten.

Voor nu zie ik hier echter geen probleem, de toewijzing is toch altijd statisch en het wijzigt toch niet zo snel.

Maar goed als dat niet kan dan heb je twee opties, de mooiste is in mijn ogen dat je gaat werken met één centrale firewall (al dan niet in een HA setup) waar je beide reeksen naartoe laat routeren.

De andere optie is inderdaad een router (bijvoorbeeld een L3 switch) tussen je modem en je firewall plaatsen die je het verkeer laat verdelen. Die geef je dan een IP in subnet A (dus de reeks met gateway bij je provider) en daar laat je beide /29 subnets naartoe routeren, vervolgens kun je dan die switch ook een VLAN interface geven in beide /29's en die als gateway gebruiken voor je firewalls. Aan je firewalls biedt je dan een trunk met beide VLAN's daarin aan. Een L2 switch gaat het hem in elk geval niet doen.

Ik zal eens kijken of VLAN's ook ondersteund worden op de WAN interface, op de interne interfaces overigens wel.

Paul schreef op woensdag 02 april 2014 @ 11:11:
Je hebt daar inderdaad een router voor nodig, al dan niet in de vorm van een L2 switch.

Echter, je firewalls krijgen dan de adressen op hun 'WAN'-interface en moet je dus gaan NATten naar de interne servers. Als je firewall de next-hop is dan hoeven ze alleen te routeren en zit je dus niet met alle gezeik dat NAT op kan leveren.

Het verkeer wordt inderdaad naar binnen toe geNAT. Gezien een beperkt aantal IP-adressen worden deze intern ook verdeeld over meerdere servers (SMTP, WWW, FTP, etc).

Het beste is inderdaad ofwel heel B op één firewall en heel C op de andere (dan heb je het ook verdeeld, ik weet alleen niet of dat een wenselijke verdeling is) of je firewalls in een HA-opstelling zetten, en alle netwerken (zowel B en C als ook alle interne netten) op dat ene cluster configureren.

Het verbruik is niet gelijk verdeeld over de firewall-clusters, maar we willen wel meer adressen kunnen gebruiken op firewall-cluster 1 dan nu het geval is. Andere optie is nog een vierde reeks erbij en die reeks laten afleveren op het eerste firewall-cluster, maar zo is er nog niet heel veel flexibiliteit en neemt het verlies nog verder toe (omdat ieder subnet weer een netwerk en broadcast nodig hebben - in dit geval geen router-adres omdat dit adres ook bruikbaar is op de firewall).

Nog een optie, maar dat kost een heleboel adressen, is B en C verder opdelen in subnetten...

Da's geen optie, zoveel IP-adressen hebben we niet helaas.

pablo_p schreef op woensdag 02 april 2014 @ 11:38:
De mooiste oplossing in een HA cluster. Dat is ook mijn eerste advies

Als er echter redenen zijn om twee firewalls te houden (bv scheiding van beheerdomeinen) is (uitgaande dat nu al NAT gebruikt wordt), is de flexibelste oplossing om een L3 switch of router in subnet A te plaatsen het het externe adres van de tweede firewall.

Dat wilde ik dus doen via de switch.

Vervolgens maak je een interconnectie subnetje (mag 192.168.xx of 10.x.x.x zijn) waarin een VLAN interface van de L3 switch zit + interfaces van de de eerste en de tweede firewall. Door middel van host routes (/32) of eventueel sub-subnets kan je dan geregisteerde adressen naar de verschillende firewalls zetten. Maximale flexibiliteit. Je kan functies makkelijk van firewall 1 naar firewall 2 verhuizen. Eventueel kan je zoiets gebruiken als tussenfase in een migratie naar een enkele firewall. En met /32 route-statements kan je zelfs IP adressen uit subnet A gebruiken.

Klinkt een stuk ingewikkelder en ik vraag me af of dit nodig is.

Ik ben geen voorstander van een oplossing van firewalls die beiden op Interconnectie subnet B en C zitten, want dan krijg je ellende met routering van uitgaande sessies. Handiger is als systemen maar een default route hebben.

De default route zou met de switch ervoor volgens mij sowieso het publieke adres van de KPN-router worden. Het netwerk op de switch is in principe een L2 netwerk waarbij geen routering nodig is (als we kijken naar subnet A).

Als ik nu op dezelfde vlan interface een secondary adres toevoeg:

code:

interface vlan 234
     ip address 123.123.123.2 255.255.255.248
     ip address 124.124.124.1 255.255.255.248 secondary
     ip address 125.125.125.1 255.255.255.240 secondary

En dan alle interfaces die hiervoor nodig zijn als volgt instel:

code:

interface range gi 1/0/1 - 4
     switchport access vlan 234
     switchport mode access
!
interface range gi 2/0/1 - 4
     switchport access vlan 234
     switchport mode access

Met de volgende route:

code:

ip route 0.0.0.0 0.0.0.0 123.123.123.1

Uitgaande van een L3 switchstack. Zou dit dan al niet kunnen werken?

Helaas heb ik geen Cisco switch tot mijn beschikking om dit te kunnen testen, anders had ik dat wel gedaan natuurlijk.

[Mikey!]

Secondaire IP-adressen zijn erg handig voor bijvoorbeeld een migratie, maar ik zou het niet voor de lange termijn gebruiken. Het zou mooier zijn om dit met gescheiden VLANs op te lossen.

[alm]

Ik heb nog niet kunnen bekijken of de firewalls ook op de WAN zijde met VLAN's kunnen werken en duidelijk gescheiden paden (dus VLAN's) is natuurlijk beter, maar als de firewalls geen VLAN's op de WAN zijde ondersteunen dan zal ik wel moeten om ze parallel op hetzelfde netwerk te plaatsen.

Ik hoor graag een onderbouwing waarom het niet werkt of juist afgeraden wordt.

Zou het met een 2960S/XR met L3 Lite IOS kunnen werken (m.a.w. heeft die genoeg L3 functies om dit te kunnen, ofwel via VLAN's ofwel via de door mij gesuggereerde methode)? Of hebben jullie een andere suggestie voor een stackable switch die toegepast kan worden voor een oplossing?

Ik wil juist geen HSRP oid toepassen ivm de weinige beschikbare adressen (dan ben je er toch 3 kwijt: 2 vast en 1 virtueel?).

[pablo_p]

Volgens mij kan het gewoon met een 2960S switch, die volstaat als je statisch routeert. Ik heb zelf thuis een 2960G-8 en die kan dat ook prima. Aangezien alles ASICs based is, is of het line-speed, of hij kan het niet.

Onderstaand heb ik mijn voorstel in een tekening gezet. Ik heb 9.9.9.x als geregistreerde ranges gebruikt om het voorbeeld expliciet te maken


Hierbij de volgende opmerkingen:
- De geregisteerde subnets B en C worden in die oplossing niet aan een netwerk toegekend, maar worden naar de firewalls gerouteerd, op basis van wat de firewalls nodig hebben. Hiermee ben je het zuinigst met de adressen, je verliest geen adressen aan host, netwerk en broadcast adressen. Je kan gewoon bv 9.9.9.0 en 9.9.9.15 als NAT adres gebruiken.
- Routering is rechttoe-rechtaan
- Je hebt geen VLAN ondersteuning nodig op de firewalls of de KPN router, alleen op de multilayer switch.
- Enige dat lastiger is is dat de firewalls zelf niet direct naar Internet kunnen comuniceren met hun externe IP adres

Als je dat laatste wel wil, maar de flexibiliteit en efficiente van de routering wilt houden, dan kan je het doen door onderstaande situatie. Als je 'no ip redirects' aanzet op de multilayer switch, zal die bij verkeer vanuit internet in het pad zitten en bij verkeer naar internet niet. Heb je alle flexibiliteit die je wilt, met een determinisch pad heen en terug, dat echter wel verschillend is.

[jvanhambelgium]

alm schreef op vrijdag 04 april 2014 @ 08:31:
Zou het met een 2960S/XR met L3 Lite IOS kunnen werken (m.a.w. heeft die genoeg L3 functies om dit te kunnen, ofwel via VLAN's ofwel via de door mij gesuggereerde methode)? Of hebben jullie een andere suggestie voor een stackable switch die toegepast kan worden voor een oplossing?

De enige feature die jij wil gebruiken is "static routing" en wat basic VLAN-spul en dat lijkt me geen probleem voor het Lite image.

IP Lite introduced enterprise access Layer 3 features to the 2960-XR switch models. IP Lite is subset of IP Base features. Some of the IP Lite features are:

● Routing Information Protocol (RIP) v1
● Routing Information Protocol (RIP) v2
● Open Shortest Path First (OSPF) v2 stub
● Open Shortest Path First (OSPF) v3 stub
● Enhanced Interior Gateway Routing Protocol (EIGRP) stub
● Equal-cost routing
● Hot Standby Router Protocol (HSRP)
● Protocol Independent Multicast PIM (Sparse Mode, Dense Mode, Sparse Dense Mode, Source Specific Multicast) stub
● Virtual Router Redundancy Protocol (VRRP) for IPv4
● Private VLAN
● IPv6 First Hop Security source guard
● Per-VLAN and per-port policers

[bigfoot1942]

Firewalls moeten gewoon meerdere vlans op de WAN IF aankunnen, je kan ze nl ook redundant uitvoeren.

Als je er een L3 stack voor hangt, is dat niet nog steeds een 'logische spof' net zoals je huidige FW oplossingen zijn? Je geeft aan meer onafhankelijkheid te willen maar als je incidenteel je FW's wilt updaten en een klein maintenancewindowtje is lastig, zit je met een stack niet in dezelfde situatie?

[alm]

Ik heb ondertussen gevonden dat de firewalls ook op de externe interface(s) VLAN's ondersteunen.

pablo_p schreef op vrijdag 04 april 2014 @ 09:25:
Onderstaand heb ik mijn voorstel in een tekening gezet. Ik heb 9.9.9.x als geregistreerde ranges gebruikt om het voorbeeld expliciet te maken
[afbeelding]
[...]

[afbeelding]

Je hebt er wel werk van gemaakt, waarvoor dank!

Ik heb nog eens langer nagedacht over je eerdere idee met VLAN's en een tussensubnet, maar het klinkt eigenlijk wel heel goed nadat ik het op papier heb gezet!

Wat nu het idee is, is om het primaire A subnet (123.123.123.0/29) untagged (tagged is geen optie natuurlijk) binnen te laten komen op de switch op een te definiëren Internet VLAN (voorbeeld 234). Dit VLAN loopt ook naar beide firewalls die dus zonder routing (L2) hierover kunnen communiceren. Dit komt untagged binnen op de firewall-clusters. Daar hoeven alleen wat IP-adres toewijzingen te worden gewijzigd, zodat het huidige next-hop adres op de switch komt te hangen.

Dan maak ik een VLAN aan op zowel de switch als beide firewall-clusters met een niet publieke IP-reeks (voorbeeld 10.255.255.0/28, hoewel /29 ook zou werken maar een /28 wat flexibeler is) en koppel het eerste IP-adres (10.255.255.1) aan de switch op dit VLAN. Dan geef ik de firewall-clusters de opvolgende adressen (10.255.255.2 en 10.255.255.3) op het nieuwe VLAN.

Ik zit me alleen nog af te vragen of ik niet twee vLAN's moet maken, naar ieder firewall-cluster één...

Vervolgens configureer ik de gewenste publieke IP-adressen uit de B en C reeksen op de desbetreffende firewall-clusters, op hetzelfde VLAN als waarop de 10.255.255.x adressen staan. Dat werkt nu in de huidige situatie ook zo (maar dan zonder extra VLAN).

Hierna maak ik op de switch routing regels aan, zoals bijvoorbeeld:

code:

ip route 0.0.0.0 0.0.0.0 123.123.123.1
!
ip route 124.124.124.1 255.255.255.255 10.255.255.2
ip route 124.124.124.2 255.255.255.255 10.255.255.2
ip route 124.124.124.3 255.255.255.255 10.255.255.3
!
ip route 125.125.125.1 255.255.255.255 10.255.255.2
ip route 125.125.125.2 255.255.255.255 10.255.255.3
ip route 125.125.125.3 255.255.255.255 10.255.255.3

De optie 'no ip redirects' moet ik nog even uitzoeken, maar die zou dan op het native vlan moeten neem ik aan.

Heb ik het zo inderdaad goed begrepen? Er zijn vast nog wel enkele losse eindjes, maar ik ben al veel opgeschoten denk ik zo.

jvanhambelgium schreef op vrijdag 04 april 2014 @ 09:26:
De enige feature die jij wil gebruiken is "static routing" en wat basic VLAN-spul en dat lijkt me geen probleem voor het Lite image.

IP Lite introduced enterprise access Layer 3 features to the 2960-XR switch models. IP Lite is subset of IP Base features. Some of the IP Lite features are:
[...]

Mooi, bedankt voor de info! Genoeg voor bovenstaande oplossing inderdaad.

bigfoot1942 schreef op vrijdag 04 april 2014 @ 14:50:
Firewalls moeten gewoon meerdere vlans op de WAN IF aankunnen, je kan ze nl ook redundant uitvoeren.

Als je er een L3 stack voor hangt, is dat niet nog steeds een 'logische spof' net zoals je huidige FW oplossingen zijn? Je geeft aan meer onafhankelijkheid te willen maar als je incidenteel je FW's wilt updaten en een klein maintenancewindowtje is lastig, zit je met een stack niet in dezelfde situatie?

Als ik HSRP kan gebruiken zonder extra IP-adressen uit de A reeks nodig te hebben dan zou dat een optie zijn, maar ik weet niet of dat kan (dus dat het standby adres in een andere reeks kan liggen dan het eigenlijke interface adres - bijvoorbeeld 192.168.255.x op de interface en 123.123.123.2 als standby adres)?

[pablo_p]

Ik heb maar tekeningen gemaakt, want dat is op een gegeven moment sneller uitleggen. Ik ben zelf vooral visueel ingesteld, ik moet het kunnen zien om het te kunnen begrijpen.

Als je voor de tweede optie kiest hoef je geen interconnectie subnets meer te maken tussen de switch en de firewalls. Het publieke subnet gebruik je dan ook voor de routering tussen de switch en de firewalls. Je bouwt het of als optie 1 (bovenste tekening), of als optie 2 (onderste tekening), niet als een combinatie (want dan krijg je onduidelijkere routering).
De no-ip redirects zou je alleen in de tweede situatie gebruiken. Ze zijn heel strikt genomen niet nodig (zonder werkt het ook), maar het ik vind het netter. Je configureert dat dan op de VLAN 123.x.x.x interface op de switch.

De statische routes zoals je geeft zijn precies wat de bedoeling is voor optie 1. In optie 2 zou het zijn:

code:

ip route 0.0.0.0 0.0.0.0 123.123.123.1
!
ip route 124.124.124.1 255.255.255.255 123.123.123.2
ip route 124.124.124.2 255.255.255.255 123.123.123.2
ip route 124.124.124.3 255.255.255.255 123.123.123.3
!
ip route 125.125.125.1 255.255.255.255 123.123.123.2
ip route 125.125.125.2 255.255.255.255 123.123.123.3
ip route 125.125.125.3 255.255.255.255 123.123.123.3

.

[alm]

Inderdaad, dat extra VLAN kan vervallen als ik gewoon doe zoals je stelt in optie 2. Scheelt ook gedoe op de firewall-clusters, hoef daar alleen wat IP's te wijzigen. Maar op zich biedt het gebruik van VLAN's wel weer andere mogelijkheden die wellicht interessant kunnen zijn. Ben er nog niet helemaal uit dus.

[pablo_p]

Ik vind het wel een groot voordeel als de firewall aan de buitenkant een geregistreerd IP adres heeft. Zowel met connectietesten vanaf de firewall naar buiten (simpele ping), als met IPsec VPN, waar je gewoon het interface IP als endpoint kan gebruiken. Ik vind optie 2 daarom beter

[ik222]

Nog een andere optie is dat je de L3 switch ook een VLAN interface in de twee gerouteerde /28's geeft. Nadeel daarvan is dat je dat adressen kost in beide subnets (ip voor de gateway, network en broadcast adres) maar het voordeel is dat je dan in beide reeksen gewoon interfaces kan hangen met als gateway het ip op de VLAN interface van de switch.

Overigens als je zeker weet dat je de adressen alleen doormiddel van NAT voor devices achter of als loopback op de firewall wilt gebruiken zou ik dit niet doen omdat het je dan enkel adressen kost. Als je echter bijvoorbeeld ook servers buiten de firewall om rechtsteeks in een van die subnets wilt hangen kan het wel een goede optie zijn.