Category: Azure

Updated: NetScaler Active/Passive HA in Azure with multiple NICs/IPs (DSR/Floating IP)

I wrote a blog post for NetScaler active/passive HA in Azure with multiple NICs two days ago, and I’ve been trying to figure out if this was the best way to do it. In the other post, I was using IPPattern in NetScaler to set the vServers to a /31 – which does work but that’s just because of how the underlying Azure infrastrucuture works (where machines outside of the VM – for example Azure LB – can only access the IP that has been assigned to the VM).

There is another way of doing this, which doesn’t require you to use a /31. The key is in configuring DSR (Direct Server Return) in Azure LB (also known as Floating IP). This will make it possible to use the same VIP on the NetScalers as the Frontend IP of the Azure LB – which saves IP-addresses and is easier to configure. This is the way Citrix has documented it and this is how their HA template does it.



NetScaler Active/Passive HA in Azure with multiple NICs/IPs

Update:

I’ve found out that there’s a much easier way of doing the below in Azure – take a look at the updated blog post:

Updated: NetScaler Active/Passive HA in Azure with multiple NICs/IPs (DSR/Floating IP)

——

There are a lot of information out there about setting up NetScaler HA in Azure. One way is using a single NIC and a single IP for all traffic – which allows for active/passive but causes other limitations. Another way is to use multiple NICs/IPs and use active/active. Both cases uses Azure LB to provide high availability.



Azure AD Conditional Access – säkra upp access till Azure och Office 365

Azure och Office 365 erbjuder det Microsoft kallar mobile-first, cloud-first vilket innebär att användarna kan vara produktiva var de än är, med vilken device de vill och när de vill. Det går dock emot många säkerhetsaspekter att skydda företagets resurser.

Som standard i Office 365 kan en användare logga in varsomhelst ifrån med namn och lösenord men i många organisationer är det inte säkert nog. Azure AD Conditional Access försöker råda bot på det genom att säkra upp accessen till Azure och Office 365 genom att sätta ett villkor och en policy på hur access tillåts. Ett exempel är att man vid vissa villkor ställa krav på MFA (Multi Factor Authentication) eller att den enhet användaren loggar in i från är AD joinad eller till och med godkänd i MDM-lösningen eller alla dessa.



Azure Automation – Running scripts locally on VM through runbooks

I was tasked to create a powershell script to run on a schedule on a Azure VM. Normally this would be running as a scheduled task on the VM but seeing as we’re working with AzureVM and schedule tasks are legacy I wanted to explore the possibilities of running the schedule and script in Azure to keep the VM clean and the configuration scalable.

After some research the best option would be running the powershell script as a CustomScriptExtension on the VM, and the schedule would be handled by a Process Automation Runbook (using Automation Accounts).

What I ended up with is the script below. It’s fairly easy to configure and contains almost all the required configuration in the parameters.



Recursively search Azure Ad group members

When working with on-premise Active Directory an administrator often has to recursively search AD groups, this is easy using the ActiveDirectory module with cmdlet ”Get-AdGroupMember <Group> -Recusive”.
For the AzureAD equivalent this is no longer an option, the cmdlet Get-AzureADGroupMember has three parameters.

PARAMETERS
-All <Boolean>
If true, return all group members. If false, return the number of objects specified by the Top parameter
-ObjectId <String>
Specifies the ID of a group in Azure AD.
-Top <Int32>
Specifies the maximum number of records to return.



(tech preview) Using multiple IPs on one NIC with NetScaler in Azure

Microsoft has released a tech preview to support multiple IPs on the same NIC in Azure. I’ve tried it with NetScaler and seems to be working like expected!

More info about it can be found here: Assign multiple IP addresses to virtual machines using PowerShell

As always, logon and select your subscription using PowerShell:

FYI: This may take a few minutes. Even after registring the features (and seeing them being registered), I received the following error message when trying to assign multiple IP configurations to one NIC: Subscription <ID> is not registered for feature Microsoft.Network/AllowMultipleIpConfigurationsPerNic required to carry out the requested operation.

It started working for me after running Register-AzureRmResourceProvider, but maybe I just didn’t wait long enough.

Verify that they have the state ”Registered”:

You can now go to the portal and assign new IP configurations, or do it from PowerShell. See below for how I added new IPs to an already existing NetScaler:

Now, just add a SNIP and then start working with your VIP or VIPs in NetScaler. Remember, this is still a Tech preview and shouldn’t be used in production – you may not get support from Microsoft or Citrix if something stops working.



Använd Bidirectional Forwarding Detection ihop med BIRD

I mitt senaste inlägg skrev jag lite kort om hur OSPF kan användas för att skapa en dynamisk routing med BIRD. Det finns en ytterligare funktion för att snabba upp feldetektering och förändra routing-tabellen så fort det bara går.

Funktionen kallas Bidirectional Forwarding Detection (BFD) och går snabbt att lägga till.

Första delen är att vi aktiverar funktionen på samtliga noder:

När detta är gjort på samtliga noder kan vi ladda om konfigurationen och sedan verifiera att det fungerar:

Så enkelt var det!



Använd OSPF för routing mellan StrongSwan VTI med BIRD

Jag skrev här om dagen ett inlägg angående att använda OSPF mellan StrongSwan VTIs. Många använder BIRD istället för Quagga för att hantera routing i Linux. I detta inlägg tänkte jag kort visa hur vi kan byta ut det vi gjorde med Quagga och göra det med BIRD istället.

Eftersom vi förra inlägget använde Quagga så tar vi och stänger av det:

Därefter installerar vi BIRD och konfigurerar (tar bara med ett exempel):

Konfigurationen (väldigt enkel, för att reflektera hur jag gjorde med quagga):

Aktivera autostart och starta BIRD:

För att få ut information om routing kan vi använda birdc:

 



Använd OSPF för routing mellan StrongSwan VTI

I mitt tidigare inlägg beskrev jag hur IPSec-tunnlar kan sättas upp med hjälp av CentOS och StrongSwan. För att slutföra det hela vill vi ju så klart skapa en dynamisk routing mellan noderna så vi inte behöver sitta och konfigurera sånt manuellt.

Installation och grundkonfiguration:

Därefter, konfigurera en statisk route till ”Client” nätet för respektive router och konfigurera dem för OSPF.

Nu kan du verifiera att det fungerar genom exempelvis köra följande på en av dem:

Genom att vi kör broadcast kan du testa att stänga av olika vti och se hur trafiken ändrar path. I mitt fall använde jag Windows 10-maskiner på mina ”Client” subnät som kommunicerade med varandra. Värt att tänka på är att inte glömma user defined routes för subnät 01.



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!