VLAN aan beide kanten Site to Site VPN

[Verwijderd]

Hoofdlocatie_A heeft een Site to Site VPN verbinding met Locatie_B.
• Hoofdlocatie_A heeft een ESX omgeving met een server-VLAN (172.16.x.x).
• Locatie_B is momenteel de uitwijk/backup locatie wat betreft storage.

Nu overwegen wij om ook een ESX (dus server-VLAN) omgeving op Locatie_B in te richten. Beide locaties hebben een Cisco ASA die de S2S VPN regelen.

Wat is er globaal netwerktechnisch voor nodig om server-VLAN ook op Locatie_B te configureren? Zodat users het server-VLAN kunnen benaderen ongeacht of het zich nu op Hoofdlocatie_A of Locatie_B bevindt.

[CyBeR]

Routing?

[ik222]

Inderdaad, gewoon zorgen dat de subnets van zowel server als clients op beide locatie verschillend zijn en dan op beide ASA's routes aanmaken zodat de ASA op locatie A weet dat de subnets van locatie B via de VPN bereikbaar zijn en andersom.

[ Voor 4% gewijzigd door ik222 op 06-11-2013 19:04 ]

[Verwijderd]

Oké bedank beiden. Mijn kennis op dit gebied is beperkt. Nog even een paar vragen.

Ons server-VLAN (Hoofdlocatie A) heeft het subnet 172.16.0.0/16, de servers/ESX-omgeving hangen aan een L3 Switch.

Stel ik wil 172.16.222.0/24 gebruiken voor server-VLAN op Locatie_B. Moeten wij dan een route plaatsen op de L3 Switch richting de ASA/VPN_Gateway?. Dat 172.16.222.0/24 richting de ASA gaat.

De ASA gooit het dan toch vanzelf over de VPN als 172.16.222.0/24 gedefineerd staat in de cryptomap? Of moet ik hier ook nog een route plaatsen?

[Insehh]

Volgens mij heb je daar aparte route voor nodig ?

[ik222]

Ik zou op de tweede locatie niet het subnet 172.16.222.0/24 gaan gebruiken omdat dat overlapt met het 172.16.0.0/16 subnet dat je al hebt. Mogelijk kan je het wel werkend krijgen omdat 172.16.222.0/24 een meer specifieke route is maar ik zou zorgen dat je subnets gewoon niet overlappen, dat voorkomt veel mogelijk problemen.

172.16.0.0/16 is wat dat betreft ook wel een erg groot subnet maar ik kan me voorstellen dat je dit nu niet makkelijker meer kleiner krijgt dus dan zou ik aan de andere kant een subnet gebruiken in de 10.x.x.x of 192.168.x.x reeks.

[Verwijderd]

Dank.

Maar in geval van 10.x.x.x valt hij niet meer onder het gedefineerde subnet voor het server-VLAN. Op de L3 switch draait de interface voor het server-VLAN met het ip addres 172.16.1.1 255.255.0.0. Is er ook een manier om in locatie_B hetzelfde VLAN aan te kunnen houden?

[CyBeR]

ik222 schreef op donderdag 07 november 2013 @ 10:49:
Ik zou op de tweede locatie niet het subnet 172.16.222.0/24 gaan gebruiken omdat dat overlapt met het 172.16.0.0/16 subnet dat je al hebt. Mogelijk kan je het wel werkend krijgen omdat 172.16.222.0/24 een meer specifieke router is maar ik zou zorgen dat je subnets gewoon niet overlappen, dat voorkomt veel mogelijk problemen.

Meh, dat is de basis van CIDR en veroorzaakt echt geen problemen.

[ik222]

Dat snap ik maar er zijn ook genoeg L3 switches die het niet snappen als ze zelf connected 172.16.0.0/16 hebben en een route naar bijvoorbeeld 172.16.222.0/24. In het geval van de TS zullen de ASA's het sowieso prima snappen maar er is een mogelijkheid dat de apparaten achter die L3 switch de andere kant niet kunnen bereiken. Daarom zou ik indien mogelijk dit soort dingen altijd vermijden.

[Verwijderd]

Ok...dus het zou wel kunnen, maar beter van niet.

Maar in het geval van 10.x.x.x of 172.17.x.x valt hij niet meer onder het gedefineerde subnet voor het server-VLAN. Op de L3 switch draait de interface voor het server-VLAN met het ip addres 172.16.1.1 255.255.0.0. Is er ook een manier om in locatie_B hetzelfde VLAN aan te kunnen houden?

[ik222]

Je moet even het onderscheid maken tussen VLAN's (laag 2) en subnets (laag 3). Dezelfde VLAN nummers kun je prima op meerdere locaties gebruiken. Alleen als je dezelfde subnets gebruikt aan beide kanten kunnen je ASA's niet bepalen welk verkeer ze over de tunnel naar de andere locatie moeten sturen.

Wat bedoel je overigens met "10.x.x.x valt buiten het gedefinieerde server-VLAN". Aangezien je het verkeer gaat routeren is dat toch precies wat je wilt, namelijk een subnet dat buiten het huidige op locatie A gebruikte subnet valt?

Je kunt dan bijvoorbeeld dit doen wat betreft routering:

L3 switch
172.16.0.0/16 kent deze zelf connected
route 0.0.0.0/0 (default gateway) naar de ASA op locatie A

ASA A
route 172.16.0.0/16 naar de L3 switch
route 10.0.0.0/24 (als voorbeeld) via de VPN naar locatie B


ASA B
route 172.16.0.0/16 naar de ASA op locatie A
10.0.0.0/24 hier bijvoorbeeld gewoon connected opde interface waar je servers op zitten. Of als je hier ook een L3 switch zou gaan gebruiken routeer je deze hier net als op locatie A naar je L3 switch.

[ Voor 63% gewijzigd door ik222 op 07-11-2013 14:33 ]

[CyBeR]

ik222 schreef op donderdag 07 november 2013 @ 13:56:
Dat snap ik maar er zijn ook genoeg L3 switches die het niet snappen als ze zelf connected 172.16.0.0/16 hebben en een route naar bijvoorbeeld 172.16.222.0/24.

Welke dan, want ik ben dat nog nooit tegengekomen.

[Predator]

CyBeR schreef op donderdag 07 november 2013 @ 13:36:
[...]


Meh, dat is de basis van CIDR en veroorzaakt echt geen problemen.

Dat is het probleem niet.
Als zijn servers echt in 172.16.0.0/16 zitten, dan weten die niet dat 172.16.222.0/24 niet meer lokaal is, maar via een router moet.
Dan heb je op al je servers een route nodig voor 172.16.222.0/24.
Kinda annoying

Wil de TS niet gewoon een L2 extension over de VPN ?

[ik222]

Dat ook nog inderdaad maar zo heb je ook L3 switches die als ze 172.16.0.0/16 connected hebben het verkeer voor het 172.16.0.0/16 netwerk gaan broadcasten op hun connected interface in plaats van naar hun route tabel te kijken.

[CyBeR]

Predator schreef op donderdag 07 november 2013 @ 14:51:
[...]

Dat is het probleem niet.
Als zijn servers echt in 172.16.0.0/16 zitten, dan weten die niet dat 172.16.222.0/24 niet meer lokaal is, maar via een router moet.

Dat is waar, maar dat is niet de situatie waar ik van uitga als je iemand voor je hebt die wel enigszins van de hoed en de rand weet.

Als dat wél zo is, moet je idd een niet-overlappend subnet gebruiken of je moet lelijke proxy-arp dingen gaan doen. Maar dat wil je niet.