[ASTARO FireWall] VPN routing probleem

[DJ]

Hoi,

Ik twijfelde een beetje of deze wel hier hoort of dat hij in NWOS thuis hoort, maar hier gaat hij dan alsnog. Als hij fout staat dan bij deze het verzoek om hem te verplaatsen

Het probleem is alsvolgt:
We hebben drie lokaties die middels een VPN met elkaar gekoppeld moeten worden. Twee ervan hebben een Astaro Linux FireWall (v6) en eentje heeft een SonicWALL Pro3060 met Enhanced OS. Netwerk technisch is het zo dat er een DataCentre is (voorzien van een Astaro) en daarop moeten de beide andere lokaties koppelen. De tweede Astaro staat bij een eindgebruiker die ondersteund moet worden vanuit de lokatie waar de SonicWALL staat.

code:

KLANT (Astaro) <-----> DataCentre (Astaro) <-----> Beheer (SonicWALL)
172.16.8.0/24          172.16.0.0/16               10.1.1.0/24

Nu is de VPN tussen de beide Astaro's geen probleem en ook de VPN tussen de SonicWALL en de Astaro op het DataCentre is geen probleem. Probleem is echter om de routering over de VPN's zo te krijgen dat de Beheer club verbinding kan maken met de klant (van de ene VPN naar de andere dus . . .).

Wij zijn de Beheer club en hebben dus veel SonicWALL's (en PIX'en ) en die Astaro's worden door een derde partij beheerd. Ik heb een test opstelling gebouwd die bovenstaande tekening simuleert.

De SonicWALL's kunnen in een VPN definitie meerdere Subnetten mee krijgen en ook routeren . . . de Astaro's (voor zover ik kan zien) kunnen dat niet. Die kunnen maar één subnet per uiteinde aan in de VPN. Als ze dat wel zouden kunnen dan zou het geen probleem zijn want dan geef ik aan de klant zijde op dat er twee subnetten aan de overkant liggen: 10.1.1.0/24 en 172.16.0.0/16. Nu kan ik alleen de laatste opgeven. Ik moet dus ofwel een extra VPN neerleggen tussen de klant en Beheer (wat geen optie is want er zijn veel meer klanten . . .) ofwel de Astaro op het DataCentre zover krijgen dat hij het Beheer netwerk (10.1.1.0/24) gaat Masq'en naar 172.16.x.x. En daar gaat het nu fout: hoe doe ik dat?

Ik weet dat het moet kunnen, alleen krijg ik die Astaro nog niet zover dat hij het ook snapt . . .

Anyone have any suggestions?

[Verwijderd]

Als je nu het volgende instelt:

op de astaro (linkerkant van de vpn)
left: 0.0.0.0
right 10.1.1.0/24

op de Sonic Wall:
left: 0.0.0.0
right 10.1.1.0/24


Dit zelfde truukje doe je op de Astaro van de klant. Nu wordt al het verkeer door de VPN heen geduwd en vervolgens correct gerouterd.
Gigantisch nadeel hiervan is dat ook het overige internet verkeer via de Astaro in het datacenter loopt.

[DJ]

Ik zal het eens gaan testen. In ieder geval bedankt voor de (mogelijke) oplossing. Al moet ik wel melden dat dit meer een workaround is dan een oplossing omdat al het verkeer dan dus door de VPN gaat . . . en dat is eigenlijk niet de bedoeling. Ik laat nog even weten of het werkt.

[Verwijderd]

is je probleem niet gewoon overlap in subnets? 172.16.8.0/24 is onderdeel van 172.16.0.0/16.

[ Voor 34% gewijzigd door Verwijderd op 18-04-2006 17:16 ]

[palloquin]

Astaro wordt (in mijn ervaring) goed gesupport door contect-isc in enschede, als je er niet uitkomt, is dat misschien wel een optie.

[DJ]

palloquin schreef op dinsdag 18 april 2006 @ 17:21:
Astaro wordt (in mijn ervaring) goed gesupport door contect-isc in enschede, als je er niet uitkomt, is dat misschien wel een optie.

Daar heb ik ook al een mailtje naar toe gestuurd . . . maar nog geen antwoord gehad

Donderdag a.s. kan ik pas weer verder hiermee . . . voorlopig afwachten dus.

[Equator]

Verwijderd schreef op dinsdag 18 april 2006 @ 17:15:
is je probleem niet gewoon overlap in subnets? 172.16.8.0/24 is onderdeel van 172.16.0.0/16.

^ with iis5_rules

Misschien dat je de astaro op het datacenter kan laten natten over de verbinding naar de klant, maar dat gaat het nog niet oplossen.

De astaro op het datacenter zal alle verkeer voor 172.16.8.0 lokaal houden, omdat dat in zijn eigen subnet valt. de tunnel kan wel op zijn, maar er gaat erg weinig verkeer over heen denk ik.

Mogelijke oplossing zou kunnen zijn om de klant een andere IP range te geven, maar dat is niet leuk (ligt ook aan de omgeving) of als het datacenter het toelaat, daar terug gaan naar een 24 bits netmasker.

[DJ]

Nou, het is opgelost. De jongens van de beherende partij hebben een tweede tunnel van de klant naar het DataCentre gelegd. Hierin wordt dan 10.1.1.0/24 getunneld. Dit werkt nu als een trein. Blijkbaar is het voor die Astaro FireWall's niet zo makkelijk om dat op een andere manier op te lossen. De jongens van Astaro schijnen er ook naar gekeken te hebben . . .

Het is nu dus opgelost, al vindt ik het jammer dat Astaro hiermee aantoont dat het geen volwassen en schaalbare FireWall oplossing is . . . ik had meer verwacht . . .

[DJ]

Equator schreef op woensdag 19 april 2006 @ 07:27:
[...]

^ with iis5_rules

Misschien dat je de astaro op het datacenter kan laten natten over de verbinding naar de klant, maar dat gaat het nog niet oplossen.

De astaro op het datacenter zal alle verkeer voor 172.16.8.0 lokaal houden, omdat dat in zijn eigen subnet valt. de tunnel kan wel op zijn, maar er gaat erg weinig verkeer over heen denk ik.

Mogelijke oplossing zou kunnen zijn om de klant een andere IP range te geven, maar dat is niet leuk (ligt ook aan de omgeving) of als het datacenter het toelaat, daar terug gaan naar een 24 bits netmasker.

Even om dit recht te zetten: dit is geen enkel probleem. Je kunt op het DataCentre een subnet mask hebben van /16 en de klanten in kleine /24 subnetjes (of kleiner zelfs) van het grote /16 subnet maken. De FireWall op het DataCentre kan dat perfect aan. Het makkelijke daarvan is dat er vanuit elke vestiging (als dat nodig is) maar één tunnel nodig is (172.16.0.0/16) en daarmee wordt alles gerouteerd . . . in de test opstelling werkte dat dan ook perfect en ook in de huidige live omgeving werkt het zo en draait het als een trein!