Generate RDP file feature doesnt fit with CAF Model - User Defined Routes Addition.

Avatar
Samuel Alabi

User Defined Routes/Ability to use Generate RDP file nerdio feature. 

With us following the CAF framework and enforcing all traffic to go via the fw, this breaks the generate rdp feature. This is because Nerdio only adds an NSG rule and public IP currently. We have had to work around this for a while but as we are now scaling + Microsoft are changing the rules around explicit default outbound access, we need a resolution. 

The ideal resolution is:

Currently the "Generate RDP" button adds a JIT NSG rule as well as ensuring the VM has a public IP address. Could we add another action please. The logic should check if the subnet has an existing route table, if not, ignore it. If it has an existing route table, add new route with the inbound public IP address and the next hop as internet. After the duration, it will also need to clean this up. 

The alternative is for nerdio to create a new DNAT rule and also add public IP address to a FW. However, we think this is more complex but it also costs the customer more money as we are adding IPs. It also takes 5-10 mins for firewall rules to complete which is simply not fast enough for when you want to use this feature. 

Happy to chat about this further if required 

 

0

Comments (3 comments)

Sort by
1
Avatar
Dave Stephenson

Great suggestions, Samuel!

Currently, like you said, we create a public IP and manually assign the Just-in-Time NSG rule, when you click the “Generate RDP” button (see Generate an RDP File – Nerdio Help Center).

From what I know of Azure Networking, your solution could work, however it might be a bit complicated to figure out with the API. Especially once the Default Outbound Internet change this fall. If you have a NAT Gateway in place, applying a Public IP as well might not behave like you would expect (in my testing it would sometimes use the NAT Gateway IP, but others use the static Public IP).

I'm not saying it's “impossible”, but that it could take significant development hours to accomplish it.
Do you think Console Connect could work as an alternative to the “on-demand RDP” solution?

0
Avatar
Samuel Alabi

Ahh yes, you make a good point, do you see lots of people utilising the NAT Gateway over a Firewall? We tend to use both but the NAT Gateway is typically for LOB servers that required static IPs so they can be whitelisted on the vendors side. If it was looking at the route table though, this should only impact fw bound traffic?

Console Connect can indeed replace this. It would be good to understand how console connect works under the hood. Also, what is nerdios stance on this, does this replace generate RDP file long term? Can we use it on gold images? Forgive me if this is all documented somewhere, I can't find it! Our use case is giving nerdio to customers and they currently use the generate RDP across the platform it would be amazing is console connect could replace this. The only thing i can forsee right now is the logs. For more security concious clients, they might want an audit trail of which of their engineers are logging in and making changes.

Again, happy to have a chat on this. For context, this is our biggest challenge atm as an MSP as we are *not compliant* in our current access methods!

0
Avatar
Dave Stephenson

Thanks, Samuel!

We're seeing that using a NAT Gateway is pretty popular with our partners because it's a more cost-effective solution because it has such little cost and administrative overhead compared to a FireWall solution.
Whitelisting the session hosts is a common ask we get for partners/customers, and a NAT Gateway is a great solution for that because as the hosts are reimaged/replaced, the public IP remains the same.

You're correct on the Route Table though. It would only impact FireWall traffic.

As far as Console Connect goes, it's provided to our partners at no additional cost, but we don't require you to use it. At a high-level, each partner gets a secure “Console Connect Tenant” (not the official terminology, but it's just how I like to think of it 🙂) and an agent is deployed to the device that you can use to securely connect to the device (either interactively or in the background with Console Connect Toolbox). If you'd like, you can reach out to your Partner Success Manager (PSM) and they can arrange a demo of the tool for your team and go in-depth on any question you have.

Right now, we're not making any changes to sunset the “Generate RDP” feature, but Console Connect is definitely a more cost-effective solution because it doesn't require your customers to pay for any any Public IPs, even temporarily.

I'm also working to get a call arranged with our Product team so you can discuss your ideas/problems/pain points with them. Many times, like you mentioned, that is more efficient, but please continue to add your ideas here in the meantime. 😎

 

 

 

Please sign in to leave a comment.