Kategorie: Azure

Create a policy based VPN connection between Azure Virtual Network Gateway and a Cisco ASA

I recently had to setup a VPN site-to-site connection for a client between Azure and an on-premises environment, where a Cisco ASA 5525 was used.

By default I setup such connections as a route based connection but we could not make this work (the ASA admins didn’t have any experience with connection into the Cloud and especially with Azure).

After opening a ticket with Microsoft, we could see in the logs, that phase 1 and 2 were successful, but the following showed up as well (1.2.3.4 = on-prem public IP, 5.6.7.8 = Azure VPN gateway public IP, 172.16.106.226 = destination host on the on-prem side):

SESSION_ID :{1cc0a60b-d971-4b49-bfac-bace75c44c83} Remote 1.2.3.4:500: Local 5.6.7.8:500: Proposed(send) Traffic Selector payload will be- [Tsid 0x34c  ]Number of TSIs 1: StartAddress 0.0.0.0 EndAddress 255.255.255.255 PortStart 0 PortEnd 65535 Protocol 0 Number of TSRs 1:StartAddress 0.0.0.0 EndAddress 255.255.255.255 PortStart 0 PortEnd 65535 Protocol 0

So the Azure side propagated the complete available address range to route and as the ASA did not answer it followed up to propagate the VNet address range, where its gateway subnet was located in:

SESSION_ID :{e7070311-bf5b-46bb-af4e-1e514ab5fc18} Remote 1.2.3.4:500: Local 5.6.7.8:500: Proposed(send) Traffic Selector payload will be- [Tsid 0x34b  ]Number of TSIs 1: StartAddress 10.221.240.0 EndAddress 10.221.240.255 PortStart 0 PortEnd 65535 Protocol 0 Number of TSRs 1:StartAddress 172.16.106.226 EndAddress 172.16.106.226 PortStart 0 PortEnd 65535 Protocol 0

So we needed to show a way to propagate the right source address range (10.220.8.32/29) on the Azure side. Therefore, we had to update the connection to Use policy based traffic selector and a custom traffic selector to tell the ASA which address ranges we were offering and expecting to connect to.

The final connection configuration looks like this:

Final configuration in Azure portal.

Problems accessing Azure AD joined Windows 10 VM with RDP

I recently setup a lab environment with a Windows VM in Azure.

I connected with RDP via VPN and as a local admin.

After joining it to a Azure AD I tried to connect with the corresponding Office 365 UPN and credentials but did not succeed.

After hours of investigation and opening a support ticket with Microsoft I found this solution:

  • to connect via mstsc you’ll need to adjust the RDP config file adding the parameter enablecredsspsupport:i:0
  • Now you’re able to connect with RDP via mstac with the O365 user in the form of AzureAD\ (example: AzureAD\someuser@yourdomain.onmicrosoft.com)

If you prefer another RDP client (as I do with Remote Desktop Connection Manager), you’ll have to change a registry setting, as Microsoft changed the RDP defaults in Windows 10. They modified the default for “SecurityLayer” from 0 to 2. Even if you go into the user interface and disable: “Allow connections only from computers running Remote Desktop with Network Level Authentication (recommended)” Still doesn’t change that value to a 2.

  • Open RegEdit
  • Navigate to this Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp (Thanks to Renato Brito from Microsoft for this!)
  • Change “SecurityLayer” to a zero
  • Reboot and done!

Azure Site to Site VPN und Telekom Speedport Hybrid

Da arbeitet man nun seit Jahren in der IT. VPN ist eher aussterbend aber manchmal hätte man es gerne. Zum Beispiel auf die Labor- und Testumgebung in Azure. Da spart man sich mit VPN die Kosten für die public IPs und natürlich den Aufwand mit dem Firewalling und allgemein ‚rund um die Sicherheit. Und da ich mir vor ein paar Tagen ein neue Firewall für mein HomeOffice gegönnt habe, lege ich also auch gleich mit der IPSec-Einrichtung für eine Site2Site-Anbindung nach Azure los.

Klappt aber nicht. Der Tunnel will um’s Verrecken nicht hochkommen. Bin ich zu doof? Beherrsche ich meine Firewall nicht. Funktioniert in Azure etwas nicht wie gewünscht?

Nun, ich habe mir vor einem Jahr mehr Bandbreite gewünscht, 6 MBit bei meinem seit Jahrzehnten wohl gelittenen Provider TNG waren mir nicht mehr genug, es sollte die einzige Alternative ‚Hybrid-DSL‘ vom Magenta-Riesen sein, immerhin kann ich damit bis zu 20 MBit erreichen … Ach, hätte ich mir das vorher genauer angesehen. TNG, wie vermisse ich Eure Qualität und Euren Service! Das Übel kam in Form des Speedport Hybrid Routers ins Haus. Nach ein paar Tagen hat man dann ‚raus, dass man da so ziemlich alles ausschalten muss, was vom Provider gesteuert werden kann. Für die Sicherheit nutzt man eh seine eigene Infrastruktur. VPN brauchte ich bis dato nicht, also fiel mir auch erst jetzt auf, daß dieser Pseudo-Router noch nicht ‚mal IPSec Passthrough kann, weil ESP einfach nicht vorhanden ist/geht. Wenn man die diversen Postings auf der Telekom Community Seite zu diesem Produkt liest, fragt man sich, warum man das nicht vorher gelesen hat. Umsetzung des Produkts Hybrid-DSL und insbesondere der dazu ausgelieferte Router sind nichts für Leute, die professionell mit IT arbeiten müssen|wollen|können … Nach mehreren Tagen und Nächten muss ich feststellen: nix Site2Site VPN zu Azure. Lediglich Point2Site funktioniert … Also ‚mal bei Zeiten den Vertrag mit der Telekom kündigen und (wieder ‚mal) eine Alternative mit Bandbreite suchen …