As users of Azure RemoteApp I was tasked with finding a replacement due to the product being retired.

We used the service primarily as a remote access solution, allowing users to RDP to their desktops (assuming they were turned on).

The preferred solution recommended by Azure is Citrix Xenapp Express, a cloud only version of XenApp. This was trialed internally and vetoed almost straight away after deployment as it lacked two factor authentication – this is a huge oversight in my opinion. While views on this will vary company to company, I personally feel that ALL external applications should be protected by two factor authentication. It’s simply not good enough to rely on a username and password.

I decided to take a look at the Netscaler VPX appliance. It is available in the Azure Microsoft and can be deployed to any ARM environments.

Pros

  • Clientless access (although you need to have the Microsoft terminal services client installed – native in Windows, you need to install it on MacOSX, Android etc)
  • Works on every device I’ve tried – Includes iPhone, Android Tablets, MacOSX etc
  • Much cheaper than RemoteApp. A Netscaler VPX enterprise license (which you need for RDP Proxy) and 200mb throughput will be ~£8000 per year + Azure VM costs. We were spending circa £15,000 for 200 or so users.
  • Good user experience – web portal is fairly straight forward.
  • Performant – test users report their desktops are much more responsive than publishing RDP over Remote App.
  • Feature Rich – supports web bookmarks, load balancing, DDoS protection

Cons

  • I wouldn’t say Netscaler VPX is very intuitive to administer/configure. I think it’s more than just a lack of familiarity with the system.
  • IaaS – you need to maintain the system, patch it, and make sure it’s configured correctly
  • Supports any authentication methods you can think of. We are using radius in conjunction with the Microsoft multi factor authentication server.

The system is being trialed by our I.T department but it’s so far proved to be really good.

 

 

 

The Azure Application Gateway

Azure have released an application gateway with some WAF functionality which “protects web applications from common web-based attacks like SQL injection, cross-site scripting attacks, and session hijacks”. I deployed Barracuda WAF’s in our Azure architecture several years ago but subsequently got rid of them – they are expensive solution if you don’t have a lot of applications behind them. We were paying somewhere in the region of £10,000 per year per device. The costs add up when you need 2 for a high availability set and then another set in a different geo-region. £40,000 to protect a handful of websites. The application gateway is attractive from a cost perspective, although the WAF pricing itself hasn’t been confirmed as it’s still in preview.

the pricing is very attractive, although the WAF functionality is to 'TBC'

The pricing is very attractive, although the WAF functionality is to ‘TBC’

Evaluation

I’m keen to evaluate this service and would like to find out:

  • How much watering and feeding will they require? WAF’s like most security devices have an administrative overhead.
  • How granular are the WAF rules – can the rules be tweaked? Will entering Irish names trigger SQL injection rules which can’t be altered?
  • Would we be better off using Cloudflare in front of our websites?
  • Does it play nice with authentication? (namely ADFS / Azure AD Authentication)
  • What is it’s logging capability like, can we export it to syslog server?

I’ll do another post when I have had a good look around the product. It’s feature set overlaps rather confusingly with the ‘Azure AD Proxy’ apart from the WAF features – I’m not sure if there is a use case for both of the products still.

A while ago Azure announced a new feature allowing you to connect VNets together without express route or VPN.

VNet peering is a mechanism that connects two virtual networks (VNets) in the same region through the Azure backbone network. Once peered, the two virtual networks appear as one for all connectivity purposes. They are still managed as separate resources, but virtual machines in these virtual networks can communicate with each other directly by using private IP addresses.

The product page can be found here.

The Existing Architecture

Originally, your architecture may have consisted of several VNets and all of these would have had a gateway (a billable item) and a form of connectivity between them – either express route or VPN. There are some inefficiencies here as all traffic between VNets needs to be routed via your express route circuit. Bandwidth and the actual location of your express route termination points may be problems here. A 1000mb/s link may be plenty between your on-prem networks and Azure, but is it enough for your traffic between all of your VNets? With the below architecture we have 4 gateways for 4 VNets.

Legacy Azure Architecture - A gateway in each VNET

Legacy Azure Architecture – A gateway in each VNet

The New Architecture

VNet peering does away with the requirement to have a gateway on every VNet. We can create a VNet which serves as the link between your on-prem networks and have the rest connected via VNet peering. This is even supported between VNets that are in different subscriptions. To use the same reference architecture but changed to adopt VNet peering, we will have something like the below.

VNet Peering Azure Architecture - One more VNet but 3 fewer gateways. Profit!

VNet Peering Azure Architecture – One more VNet but 3 fewer gateways. Profit!

So we have one extra VNet, but 3 fewer gateways. The gateways are what cost money in this setup, so this will not only be a cheaper setup, but a more efficient one. All traffic between VNets will be via the (blazing fast!!!) azure backbone and not your express route link. At the moment VNet peering traffic is free of charge, so you will save some money on your ingress/egress express route charges.

As with everything Azure, please do your own research as pricing and features change regularily.

If you have provisioned an application gateway through the azure portal it’s not actually that easy to remove some components that get created automatically. As part of my testing, I ended up with a few Listeners that were surplus to requirement.

application gateway listeners - at the moment they cannot be deleted through the portal

application gateway listeners – at the moment they cannot be deleted through the portal

As a new service, the documentation isn’t that great yet. The following can be used to delete a listener from application gateway using powershell:

Remove Listeners

$AppGw = Get-AzureRmApplicationGateway -Name “application-gateway-name” -ResourceGroupName “application-gateway-resource”
Remove-AzureRmApplicationGatewayHttpListener -ApplicationGateway $AppGw -Name “name-of-listener-to-delete”
Set-AzureRmApplicationGateway -ApplicationGateway $AppGw

The process takes a wee while but will remove the listener. And for the following:

Remove HTTP Settings

$AppGw = Get-AzureRmApplicationGateway -Name “application-gateway-name” -ResourceGroupName “application-gateway-resource”
Remove-AzureRmApplicationGatewayBackendHttpSettings -ApplicationGateway $AppGw -Name “name-of-http-settings-to-delete”
Set-AzureRmApplicationGateway -ApplicationGateway $AppGw

Remove Back End Pools

$AppGw = Get-AzureRmApplicationGateway -Name “application-gateway-name” -ResourceGroupName “application-gateway-resource”
Remove-AzureRmApplicationGatewayBackendAddressPool -ApplicationGateway $AppGw -Name “name-of-back-end-pool-to-delete”
Set-AzureRmApplicationGateway -ApplicationGateway $AppGw

I’ll do a write up of the service once I have fully evaluated it. At this stage I’m not 100% sure what the difference is between this and Azure AD Application Proxy as the feature set overlaps a lot.

2960 Memory Leaks

Cisco 2960’s and their memory leaks have on more than one occasional left me without SSH/Telnet access, but still responding to SNMP requests. No matter which code base we have tried, the same pattern of memory usage over time can be seen. To be fair we ask a lot of these switches – we’re heavy uses of 802.1x, insist on using SSH rather than telnet, and have loads of smaller services such as DHCP snooping, RSTP, aaa accounting, ntp etc  – each one uses a little memory.

Cisco 2960 memory usage over time - leaking slowly we lose SSH access at around about 90%

Cisco 2960 memory usage over time – leaking slowly we lose SSH access at around about 90%

Time to Reload

A handy feature is a SNMP oid which, if you have the read/write community, allows you to reboot a switch remotely if it is still responding to SNMP (which they usually do – even when telnet/ssh/console access isn’t working).

Most Linux distributions will have snmpset installed, but there are Windows equivalents of course.

snmpset -v1 -c your-rw-community-her 1.1.1.1 .1.3.6.1.4.1.9.2.9.9.0 i 2

Change your community string, and the IP address and run this sucker. I suggest keeping a ping running to the device so you can see if this has had the desired result, and so you can see when it’s back up and running again.

Long term Solution

We are in the process of looking to replace these switches which are fully EOL July 2017. I’m tempted to script up something to reload these out of hours when the memory usage is approaching that lose-ssh-access threshold.