[NAT] Site-to-site VPN NAT

[Freggel_United]

Ik zit een beetje met de handen in het haar, en ik kom er niet uit. Ik wil een tunnel opzetten tussen twee netwerken.

Mijn eigen subnet is 172.17.16.0.x / 21

Gegevens die ik heb gekregen van de peer aan de andere zijde zijn:

- Een Extern IP om tegen te connecten (wat lukt), tunneltje komt keurig in de lucht.

- Een range om mijn subnet naar te NAT'ten: 172.29.11.208 / 30.

- Een range aan de andere kant om tegen aan te praten, waar de servers in zitten die ik nodig heb.

Mijn kant gebruikt een Sonicwall NSA3500, aan de andere kant staat een ASA...

Je raad het al, er is geen traffic mogelijk naar servers aan de andere zijde. Na het doorlezen van diverse handleidingen en ervaringen inzake het NAT'ten van je eigen subnet, voordat je het op de lijn zet naar de andere kant, begin ik ernstig te twijfelen of de range die ik gekregen heb wel gaat werken, ik bedoel, het subnet verschilt nogal van grootte, en naar wat ik gelezen heb dient dit gelijk te zijn. Is dit zo? En wat zouden eventuele adviezen zijn om dit recht te trekken?

Ik stel deze vraag overigens een beetje uit wanhoop, de beheerders van het netwerk aan de andere zijde zijn zeer moeilijk te bereiken, en ik wil zeker weten dat ik alles gedaan heb, zodat de schaarse tijd die ik heb om met die lui te praten nuttig besteed wordt.

[mhofstra]

Mijn ervaring met ASA's aan beide kant is dat een NAT van je source adres eigenlijk wel dezelfde grootte moet hebben kwa subnet. Anders krijg je volgens mij een combinatie van NAT/PAT en dat wil je eigenlijk niet door een VPN tunnel heen aangezien dat weer lastig is met firewal regels.

[CyBeR]

Waarom wil je je tunnel nat'en? Dat is over 't algemeen alleen nuttig als je een ip-rangeconflict hebt. (En dan moet je zowel source als destination nat doen).

Volgens mij moet je gewoon je routing tabellen goed bekijken.

[Freggel_United]

CyBeR schreef op vrijdag 14 december 2012 @ 12:21:
Waarom wil je je tunnel nat'en? Dat is over 't algemeen alleen nuttig als je een ip-rangeconflict hebt. (En dan moet je zowel source als destination nat doen).

Volgens mij moet je gewoon je routing tabellen goed bekijken.

Ik heb geen behoefte om te NAT'ten, dat is een vereiste van de andere kant. Mijn kant is een bedrijf (Kant A) dat werk aanneemt van een groter bedrijf (Kant B ). B heeft licenties draaien voor bepaalde pakketten, waar A gebruik van moet maken. Maar niet alleen A moet dat kunnen, ook vele andere onderaannemers, en ik vermoed dat B graag uniformiteit heeft in de adressen die hun benaderen, qua firewalling etc ook geen onredelijke eis... vandaar...

[pablo_p]

Als je voornamelijk systemen gaat benaderen aan de andere kant, heb je maar 1 IP adres uit de range nodig, waar je je nat overlaad naar gaat doen.

Maar het vereist policy-based nat overload. En in de VPN configuratie gebruik je voor jouw kant het toegekende nat subnet.

Het vereist redelijk wat configuratie flexibiliteit aan jouw kant.

[Vicarious]

Let wel op dat je in je tunneldefinitie aan de lokale kant dan het NAT-adres gebruikt en niet jouw eigen IP-range

Dus aan jouw kant is het local network 172.29.11.209/32 en het remote network <x.x.x.x> (staat niet genoemd)

Aan hun kant is hun local network <x.x.x.x> en hun remote network 172.29.11.209

Op je Sonicwall maak je dan een NAT die al het verkeer van 172.16.0.0 naar x.x.x.x unidirectional NAT naar het adres 172.29.11.209 en dan werkt het.

[pablo_p]

Ik zou als definitie van het lokale netwerk wel de /30 opgeven. Dan kan je zonder aanpassing van de tunnel definitie later ook inkomend verkeer mogelijk maken door een 1-op-1 nat aan jouw kant van een server die bij jou intern staat. Je hebt 4 adressen beschikbaar in de range en dan ben je later flexibeler.