Azure SQL and outbound firewall lock downs
What is the best way to handle a situation where I have the RDM Database hosted in Azure (with IP lockdowns, MFA, etc) and I trying to access computers on a client's network from a jumpbox?
I can VPN into the network and I have full control of the Jumpbox. I had RDM installed there but for security reasons they closed outbound SQL. There are some severs on other subnets that I cannot access directly from the VPN tunnel.
I think my options are as follows;
- Configure Azure SQL to accept incoming connections to port 443 and route them to 1433 on the instance. (Not sure if this can be done or how difficult it would be)
- Use the RDM Agent on the Jumpbox (which sort of seems to work, but gets weird with OTP connections AND when RDM launches it whines about not connecting to the DB asking about a VPN connection). I may have to connect to multiple systems. This might work but gets peculiar as I have an RDM session in an RDM sesssion which can't really connect. Perhaps I don't fully understand how the agent works? This might also be an interesting conflict because connecting to target machines requires DOMAIN\USERNAME-$OTP$ for the username.
Are there any other options or recommendations?
Thank you.
To say can't is to fail before you begin
All Comments (3)
Hi,
Can you tell me which type of connection entries you would need from the jump boxes? Devolutions Gateway would likely be a better solution to your problem. If RDM Agent is like a lightweight RDM running inside an RDP session, Devolutions Gateway acts as a network gateway to let the RDM client connect through it.
Devolutions Gateway requires Devolutions Server, you can find more information here:
https://blog.devolutions.net/2022/04/a-closer-look-at-devolutions-gateway/
RDM Agent is more general-purpose, but isn't actively developed. Devolutions Gateway currently supports RDP and SSH, and the 2022.2 release coming in June will add VNC, ARD, SCP, SFTP, PowerShell (WinRM, SSH) and website entries using chrome embedded. Let me know if you would need to connect through the Devolutions Gateway using a protocol not in the above list, as we keep adding more.
Best regards,
Marc-André Moreau
The entries I would connect to are RDP, maybe web, possibly SSH.
Devolutions Gateway is not an option unless it is free. This is a client I work with sometimes, and I'm not the only engineer. My use of RDM within my company is not exactly frowned upon, but certainly is not supported on scale. I pay for it out of my own pocket because it is that helpful. There may be other clients I work with that use high levels of security (A state prison is one example). I'm finding it more and more where they only allow outbound HTTPS, and even that is tightly controlled.
To say can't is to fail before you begin
Jump should work. Keep in mind Jump is essentially an automated way of doing session-within-session via RDM. RDP-within-RDP is the best example. If you can do it manually, Jump should be able to automate it.
The RDM instance on the Jump Host is controlled via the RDM that initiated the Jump so it never needs to connect to the SQL backend. This eliminates the need to expose your SQL server to the web for example.
As for OTP as part of the username. I haven't tested but in theory all should be OK since we resolve all credentials on the client RDM then repackage it and send it to the Jump Host (RDM) which simply launches and session and then sends the logs back to the local client so that it can be logged to the backend SQL.
More information available here: https://help.remotedesktopmanager.com/overview_whatisrdmjump.html
Stéfane Lavergne