Skapa IPSec VPN med StrongSwan mellan Azure VM

Jag inledde min tidigare post med att förklara hur jag satte upp ett CentOS VM i Azure med flera NIC, detta för att kunna ta hand om exempelvis IPSec-tunnlar mellan olika Azure-siter men även mellan Azure och on-premises. Varför inte använda Azure Virtual Network Gateway? Den fungerar ju fantastiskt bra, men i större miljöer vill du köra route based VPN och blir väldigt lätt problem om många parter är inblandade med olika märken (Cisco ASA, Fortinet, CheckPoint, Juniper, Palo Alto Networks och så vidare). Många gånger går det att lösa, men många gånger är det bara enklare att sätta upp en enhet i Azure som hanterar det så som en Cisco CSR eller Palo Alto Networks VM-series för att underlätta konfiguration och felsökning – när många är inblandade och har olika krav på hur det skall hanteras.

Jag fick för mig att det kan vara roligt att göra något liknande med Linux, för att lära mig lite mer om StrongSwan men även Quagga och mer specifikt OSPF i Linux – men kanske mer om det en annan gång.

Jag satte upp en miljö i Azure uppdelat på tre regioner:

  • UK South
    • 1 virtual network med 3 subnät
      • 10.18.0.0/16 – address space
      • 10.18.0.0/24 – subnet 01 (”clients”)
      • 10.18.16.0/28 – subnet 02 (”router inside”)
      • 10.18.16.16/28 – subnet 03 (”router outside”)
    • 2 virtuella maskiner
      • rtr01 – 1 NIC på subnet 02 och ett NIC på subnet 03
      • win10 – 1 NIC på subnet 01
    • User defined route
      • Applicerad på subnet 01 och pekar ut de andra regionerna via rtr01 på subnet 02
  • West Europe
    • 1 virtual network med 3 subnät
      • 10.17.0.0/16 – address space
      • 10.17.0.0/24 – subnet 01 (”clients”)
      • 10.17.16.0/28 – subnet 02 (”router inside”)
      • 10.17.16.16/28 – subnet 03 (”router outside”)
    • 2 virtuella maskiner
      • rtr01 – 1 NIC på subnet 02 och ett NIC på subnet 03
      • win10 – 1 NIC på subnet 01
    • User defined route
      • Applicerad på subnet 01 och pekar ut de andra regionerna via rtr01 på subnet 02
  • West US
    • 1 virtual network med 3 subnät
      • 10.16.0.0/16 – address space
      • 10.16.0.0/24 – subnet 01 (”clients”)
      • 10.16.16.0/28 – subnet 02 (”router inside”)
      • 10.16.16.16/28 – subnet 03 (”router outside”)
    • 2 virtuella maskiner
      • rtr01 – 1 NIC på subnet 02 och ett NIC på subnet 03
      • win10 – 1 NIC på subnet 01
    • User defined route
      • Applicerad på subnet 01 och pekar ut de andra regionerna via rtr01 på subnet 02

Jag utgick i stort sett helt och hållet utifrån denna sida för att konfigurera StrongSwan. Utan att gå in på var enda detalj kan det vara värt att nämna att jag satte SELinux till permissive för att få StrongSwan att köra updown-skriptet, installerade en senare kernel än den som följde med mitt Azure VM (4.9.0 från elrepo – notera att jag fick manuellt tvinga den nya till att vara den aktiva med ”grub2-set-default 0”).

Själva installationen på samtliga maskiner är lika enkel som vanligt:

Därefter stängde jag av att routes samt virtuella ip skall installeras när tunnlar sätts upp:

Därefter konfigurerade jag up/down-skriptet på respektive nod:

Notering: Glöm inte att sätta ipsec-vti.sh till exekverbar. (chmod +x /etc/strongswan/ipsec-vti.sh)

Nästa steg är att sätta upp spelreglerna för hur tunnlarna skall förhandlas:

Och till sist behöver våra pre-shared keys konfigureras:

Därefter skall det bara vara att starta strongswan (systemctl start strongswan) och börja routa via de olika vti (virtual tunnel interface). Glöm inte att uppdatera eventuella network security groups för att tillåta UDP\500 och UDP\4500!

IP forwarding kan behövas i detta steg:

Det blev en del konfiguraiton, så eventuellt att jag missat något steg. Men tror inte det! Tänk på att använda swanctl för felsökning, hjälper helt klart när man missar ett ”i” i leftid!

 

Disclaimer: All information on this blog is offered "as is" with no warranty. It is strongly recommended that you verify all information and validate all scripts in isolated test environments before using them in production environments.