Site to Site VPN zonder RFC1918 IP range's

[Nano2009]

Beste mede Tweakers,

Wij krijgen de vraag vanuit een klant om een site to site vpn op te zetten. Dit is normaliter geen probleem maar in dit specifiek geval wel, de klant vraagt namelijk om geen gebruik te maken van ip adressen die gespecificeerd staan in RFC 1918. Oftewel onderstaande ip ranges;

10.0.0.0 - 10.255.255.255 (10/8)
172.16.0.0 - 172.31.255.255 (172.16/12)
192.168.0.0 - 192.168.255.255 (192.168/16)

Wij gebruiken een SonicWALL als VPN gateway en ik heb eerlijk gezegd geen idee hoe ik als "internal network" en als "peer adres" publieke ip adressen in kan instellen die vervolgens gerouteerd worden naar een intern subnet.

Heeft iemand hier enig idee hoe ik dit zou kunnen/moeten configureren?

Alvast bedankt!

[Equator]

Voor een Site-2-Site VPN heb je natuurlijk maar twee (effectief 4, Network, broadcast, site1 en site2) IP adressen nodig. Ik zou daar inderdaad geen publieke IP adressen voor gebruiken. Kunnen ze niet een klein subnet ergens vanaf snoepen voor de VPN?

[monstertje.xyz]

Je vult gewoon bij "IPsec Primary Gateway Name or Address:" het adres van je remote peer in, en je maakt een address object aan met de nonprivate range en die geef je op als destination subnet. volgens mij moet dat gewoon werken.

[CyBeR]

Je kunt 192.0.2.0/24 gebruiken.

[Nano2009]

monstertje.xyz schreef op woensdag 15 mei 2013 @ 12:56:
Je vult gewoon bij "IPsec Primary Gateway Name or Address:" het adres van je remote peer in, en je maakt een address object aan met de nonprivate range en die geef je op als destination subnet. volgens mij moet dat gewoon werken.

Equator schreef op woensdag 15 mei 2013 @ 12:08:
Voor een Site-2-Site VPN heb je natuurlijk maar twee (effectief 4, Network, broadcast, site1 en site2) IP adressen nodig. Ik zou daar inderdaad geen publieke IP adressen voor gebruiken. Kunnen ze niet een klein subnet ergens vanaf snoepen voor de VPN?

Klopt, naar alle andere klanten is het ook op deze manier ingericht en daar hebben wij ook nooit problemen mee gehad. Alleen geeft deze klant aan geen private ip's te accepteren op het vpn netwerk.

Een quote van een email van de it manager aan hun kant;

I have no problem giving access from all the computer in the network. It still needs be on public subnets. They should be able to NAT to public IP space.

Wat ik van zijn verhaal begrijp is dat er met een no-nat oplossing gewerkt dient te worden maar ik kan me bijna niet voorstellen dat dit gecombineerd kan worden met een site to site vpn verbinding

[ Voor 14% gewijzigd door Nano2009 op 15-05-2013 16:35 ]

[base_]

Het maakt voor de routerfunctie niets uit of het rfc1918 adressen zijn (intern of extern): alles wat niet binnen lokaal subnet past gaat naar gateway op WAN of IPSEC (of aparte route). Het hangt alleen van de router af of die niet-rfc1918 adressen accepteert als lan subnet/adres.

They should be able to NAT to public IP space.

Dat kan maar dan behalve voor de onofficieel gebruikte eigen adressen (officieel moet je dus eigenlijk adressen op een eigen publieke ip range gebruiken).
Ik vind het verzoek overigens wel heel vaag en het zou me niks verbazen als je hier nog heel wat gedoe krijgt voordat eea werkt.

[Fish]

I have no problem giving access from all the computer in the network. It still needs be on public subnets. They should be able to NAT to public IP space.

allemaal een publiek ip adres (public subnet) en nat dus een 2e addres voor de nat
Volgens mij moet je nog een keer met die manager praten

zowiezo, "giving acces from" ? moet dat niet zijn "giving acces to"


But serious

het kan gewoon, je geeft alle pc's een publiek ip. Dat ze daar niet direct op te berken zijn (firewall), swa who cares. De gateway kun je een of ander nat iets op laten draaien die de zooi nat. (met dus weer een ander ip adres.

De ander locatie zet je in een ander subnet

je voegt een route toe op je gateway die voor de range van de 2e lokatie wijst naar de gateway van de 2e lokatie (het tunneladres natuurlijk)

dan kun je wanneer het moet een gat in je firewall maken wanneer een client direct benaderbaar moet zijn vanaf het internet (liever niet natuurlijk maar swa, je legt de risico's uit aan de manager en laat hem de tyfus krijgen voor de rest)

Ik zou wel vragen of dit nu echt is wat die wil. en ook even uitleggen wat een ip adres per jaar kost.

[AK47]

CyBeR schreef op woensdag 15 mei 2013 @ 13:20:
Je kunt 192.0.2.0/24 gebruiken.

Of 100.64.0.0/10 gebruiken (subnet welke eigenlijk bedoeld is voor carier-grade-nat)

[Ascension]

Waarom denk jij dat je voor een site to site perse RFC1918-adressen moet gebruiken? ;-)

IPsec of welke VPN oplossing dan ook zal het worst wezen welke IP-adressen jij gebruikt.

[pablo_p]

Als je intern RFC1918 adressen gebruikt, maar in een VPN tunnel naar een andere partij jezelf zichtbaar moeten maken achter achter geregisteerde adressen, dan heb je NAT nodig. En indien je VPN router ook je Internet firewall/gateway is, dan heb je policy-based NAT nodig om verkeer richting een betreffende VPN anders te NATten dan verkeer naar andere VPNs of naar Internet.(Of je moet route-based VPNs hebben, maar effectief komt het op hetzelfde neer)

Een aantal opmerkingen:
- Indien je alleen uitgaande sessies hebt, kan je je NAT-ten achter je enkel externe IP adres. Dit is echter niet aan te raden, want het kan ertoe leiden dat je bv de web of mail server bij de andere partij niet meer kan benaderen, omdat verkeer heen naar dat bedrijf dan over Internet gaat en terug gerouteerd wordt door dat bedrijf door de VPN.
- Het gebruik van de 192.0.2.0/24 vind ik een handige suggestie. Die zal ik ook zelf onthouden
- Deze constructies zijn een stuk ingewikkelder als je een alles-in-1 device hebt voor Firewall/NAT/VPN. Bij de grotere omgevingen die ik heb gezien is dat bijna altijd losgetrokken (firewall/nat op 1 device, VPN op een andere, kan je tenminste sniffen er tussenin)
- Bij het 'bedrijfje' waar ik voor werk is recentelijk de range publieke NAT adressen voor VPN uitgebreid, de pool van 512 adressen was op en is uitgebreid naar 1024. Wij vereisen trouwens zelf niet dat de andere kant publieke adressen gebruikt, maar doen dat wel aan onze eigen kant. Bedrijven als Oracle en IBM vereisten dat van ons in VPN connecties.
-