Azure IPsec Tunnel - Ik begrijp er niets meer van

[EricNL]

Hi All,

Nou dacht ik inmiddels net verstand te hebben van IPsec tunnels etc, tot ik nu voor het eerst e.e.a. op Azure moet gaan doen.

Ik heb verschillende guides van Microsoft en anderen gelezen, maar wat maken zij het ingewikkeld zeg. Als je het eenmaal snapt zal het vast logisch zijn, maar goed. Het doel is vrij simpel: IPsec tunnel tussen Azure en een Cisco ASA.

1. Je begint met het definiëren van een "Virtual Network". Ik zie dit als: het totale subnet wat je eventueel verder wilt gaan subnetten. Laten we zeggen: 10.10.0.0/16
2. Dan moet je vervolgens binnen dat VNet een Subnet gaan maken wat je daadwerkelijk wilt gaan gebruiken. Laten we zeggen een "LAN" voor virtuele machines: 10.10.1.0/24
3. Als je nu een IPsec tunnel wilt gaan maken moet je een "Gateway Subnet" gaan maken. Hier vind ik de benaming wat vaag worden. Wat is in dit geval nou precies een "Gateway Subnet" en wat is het verschil met een gewoon Subnet?. In ieder geval, laten we zeggen: 10.10.255.0/24
4. Vervolgens moet je een "Local Network Gateway" aanmaken. Ik zie dit als m'n "on-premise Gateway". In dit geval dus de Cisco ASA. De "Address Spaces" die je hier configureert zie ik vanuit Azure-oogpunt als de "remote subnets" (die je dus door de tunnel heen gaat benaderen). Of vanuit on-premise perspectief zijn dit de "local subnets".
5. Vervolgens kies je in het menu Connections voor een nieuwe Site-to-Site IPsec verbinding en kies je de Virtual Network Gateway en de Local Network Gateway en stel je de PSK in.

Nu ik het zo zit op te sommen wordt het al een stukje duidelijker. Het enige wat ik gewoon niet begrijp is hoe je nu door de tunnel een VM zou kunnen bereiken binnen Azure in het 10.10.1.0/24 subnet, aangezien het Gateway Subnet 10.10.255.0/24 is en dat is de gene die je kan/moet selecteren . Met andere woorden: ik zou denken dat ik dus m'n VM's binnen Azure een NIC in het Gateway Subnet moet geven, maar dat gaat dus niet.

Ik mis een stap, ik kijk ergens over heen, of ik snap het niet, maar dat laatste stukje blijft mij nu onduidelijk. Dat je 2 Peers hebt met een WAN IP is logisch (Local Network Gateway en Virtual Network Gateway).

Ik heb dit in ieder geval als referentie gebruikt: https://blogs.technet.mic...een-azure-and-on-premise/

Daar wordt in eerste instantie een VNet met het subnet 10.7.0.0/24 gemaakt, en vervolgens een Gateway Subnet met 10.7.1.0./24. Dat is volgens mij al direct onmogelijk, want als ik dat probeer krijg ik direct de melding dat 10.7.1.0/24 niet binnen de range van je VNet (10.7.0.0/24) valt en dat klopt natuurlijk ook. Dus wellicht is er intussen al weer iets veranderd, of het wordt voor mij alleen maar vager.

Opheldering is erg welkom!

[VHware]

Je kunt aan de Cisco-kant gewoon zeggen dat het hele 10.10.0.0/16 subnet (je Virtual Network in Azure) over de IPSec tunnel moet. Ik heb meerdere IPSec tunnels naar verschillende Virtual Networks in Azure en dat ging allemaal op Virtual Network-niveau en niet eventuele losse subnets in Azure.

[EricNL]

VHware schreef op dinsdag 7 augustus 2018 @ 18:21:
Je kunt aan de Cisco-kant gewoon zeggen dat het hele 10.10.0.0/16 subnet (je Virtual Network in Azure) over de IPSec tunnel moet. Ik heb meerdere IPSec tunnels naar verschillende Virtual Networks in Azure en dat ging allemaal op Virtual Network-niveau en niet eventuele losse subnets in Azure.

De Cisco kant is in dit geval ook niet m'n probleem. M'n probleem is om even de logica te begrijpen tussen een gewoon "Subnet" en een "GatewaySubnet". Het staat 100% vast dat je voor een IPsec tunnel op Azure een "GatewaySubnet" hebt en de VM's binnen Azure kunnen/mogen geen IP in dat betreffende subnet hebben. Dan mis ik dus ergens de logica tussen de samenwerking van het GatewaySubnet en het gewone Subnet. Is dit iets: "gewoon omdat het zo is". Oftewel: Azure zorgt er zelf wel voor dat het werkt?

Ik probeer namelijk graag te begrijpen wat ik doe, en de local en remote virtual gateway configuratie is duidelijk, dat is niet heel veel anders dan andere situatie's. Alleen begrijp ik gewoon niet hoe m'n GatewaySubnet (en dus de complete tunnel) nou weet dat ik iets in het "LAN" subnet wil benaderen, want dat netwerkje definiëer je dus nergens.

EDIT:
Even snel een simpel tekeningetje gemaakt hoe ik het nu zie:

[ Voor 4% gewijzigd door EricNL op 07-08-2018 18:34 ]

[VHware]

EricNL schreef op dinsdag 7 augustus 2018 @ 18:26:
[...]


De Cisco kant is in dit geval ook niet m'n probleem. M'n probleem is om even de logica te begrijpen tussen een gewoon "Subnet" en een "GatewaySubnet". Het staat 100% vast dat je voor een IPsec tunnel op Azure een "GatewaySubnet" hebt en de VM's binnen Azure kunnen/mogen geen IP in dat betreffende subnet hebben. Dan mis ik dus ergens de logica tussen de samenwerking van het GatewaySubnet en het gewone Subnet. Is dit iets: "gewoon omdat het zo is". Oftewel: Azure zorgt er zelf wel voor dat het werkt?

Ik probeer namelijk graag te begrijpen wat ik doe, en de local en remote virtual gateway configuratie is duidelijk, dat is niet heel veel anders dan andere situatie's. Alleen begrijp ik gewoon niet hoe m'n GatewaySubnet (en dus de complete tunnel) nou weet dat ik iets in het "LAN" subnet wil benaderen, want dat netwerkje definiëer je dus nergens.

Van wat ik er van heb begrepen is het dat het zo werkt vanwege dat de Azure gateway dit zelf allemaal regelt. Hoe dat exact zit/werkt durf ik niet te zeggen, is wat dat betreft een beetje een black box.

[CAPSLOCK2000]

Niet gehinderd door enige kennis van of ervaring met Azure noch Cisco zal ik toch proberen een duit in het zakje te doen.

Volgens mij moet je het Gateway Subnet in je plaatje verplaatsen naar het lijntje tussen de routers (aka gateways), ASA en AZURE_GW. Het is de "binnenkant" van je tunnel.

In een tunnel stop je IP-pakketjes in IP-pakketjes. De buitenste laag gebruikt de WAN-IP-adressen, maar in de tunnel zijn ook adressen nodig.

Je clients weten immers niet dat er een tunnel tussen zit. Die zien gewoon een eenvoudig netwerk en hebben geen idee van WAN-IP-adressen. Er moet dus een netwerk zijn dat je lokale netwerk verbindt met Azure netwerk.

[EricNL]

CAPSLOCK2000 schreef op dinsdag 7 augustus 2018 @ 18:59:
Niet gehinderd door enige kennis van of ervaring met Azure noch Cisco zal ik toch proberen een duit in het zakje te doen.

Volgens mij moet je het Gateway Subnet in je plaatje verplaatsen naar het lijntje tussen de routers (aka gateways), ASA en AZURE_GW. Het is de "binnenkant" van je tunnel.

In een tunnel stop je IP-pakketjes in IP-pakketjes. De buitenste laag gebruikt de WAN-IP-adressen, maar in de tunnel zijn ook adressen nodig.

Je clients weten immers niet dat er een tunnel tussen zit. Die zien gewoon een eenvoudig netwerk en hebben geen idee van WAN-IP-adressen. Er moet dus een netwerk zijn dat je lokale netwerk verbindt met Azure netwerk.

Nee, dat is niet correct. De tunnel zelf is geen apart netwerk, De 2 gateways vinden elkaar over het internet. Daarover wordt een tunnel gebouwd. Binnen die tunnel geef je aan 2 kanten "interesting" traffic aan, oftewel: verkeer wat ge-enrypt/decrypt moet worden.

Ik gok dus dat het zoiets is als wat VHare zegt: dit is gewoon hoe de Azure omgeving werkt met IPsec tunnels. Alleen als je Cisco etc. gewend ben dat is de bewoording van Azure wel vaag en daarom maak ik het mijzelf denk ik moeilijk.

Ik ga morgen de tunnel gewoon aan knallen en kijken of ik dus het 10.10.1.0/24 subnet kan bereiken door de tunnel.

[Turdie]

Wat ik meestal doe, is uit de /24 (in jouw geval 10.10.1.0/24), een /28 subnetten. Ik denk dat je gateway subnet in de 10.10.1.* range moet blijven.

Wij gebruiken wel een andere range, maar onderstaand screenshotje geeft misschien een beetje een voorbeeld:

[ Voor 63% gewijzigd door Turdie op 07-08-2018 21:30 ]

[Verwijderd]

Ha, leuk topic. Tijdje geleden dit ook geregeld (alleen dan met een SRX in plaats van een ASA).

Azure doet zelf security scans op publieke endpoints en volgens mij is dat de reden voor de setup (https://docs.microsoft.co...teway/vpn-gateway-vpn-faq). Maar 100% zeker weet ik het niet.

Zou je er gewoon bij neerleggen inderdaad.

[ Voor 3% gewijzigd door Verwijderd op 08-08-2018 10:55 ]