Remote Desktop with VPN/Authpoint?
My company is wanting to use RDP so I'm trying to figure out the best way to set it up. I want to make sure it's as safe and secure as possible.
I have a T35 and it's already configured to use IKEv2 VPN with Authpoint. I also have a firewall policy that's enabled for RDP. I'm using my clients local IP address (Alias) for the FROM and SNAT for the TO. I have no problem connecting to the remote desktop when using this policy. The VPN (or Authpoint) aren't being used for the RDP connection.
So, is there a way I could use a VPN or Authpoint to better secure the RDP connection? If not, what is the best practice for using RDP? Is my current setup good enough or should I be concerned?
TIA
0
Sign In to comment.
Comments
Set the RDP policy From: field to be either VPN user IDs or a VPN auth group
It doesn't work when I put VPN auth group in the FROM field. It only works when I put in my local IP (alias).
Should the VPN auth group be the only item in the FROM field?
Use of the VPN auth group, when users are authenticated using a VPN client, works for me and others.
Since it does not seem to work for you, please provide details of the actual test & RDP policy setup.
Thanks for the quick reply.
As I mentioned, I'm using IKEv2 with Authpoint and it's connecting without any issues. I'm using a Radius Group for Authentication. I'm using port 1812. The policy 'Allow IKEvw-Users' uses the Radius Group for the FROM and Any for the TO.
My Remote Desktop policy is configured with the same Radius group as above for the FROM and the TO is configured with (SNAT) publicIP --> local IP:3389. I'm using port 6993/TCP for the policy port/protocol. I have no problem connecting to the remote desktop, when I use my local IP address in the FROM field.
For a client VPN connection, using the auth group or User ID or the VPN virtual IP addr subnet, the To: field needs to be the real internal IP addr of the destination IP addr, not a SNAT.
Thanks! It's working now. And really appreciate the help on a Sunday night.
You are welcome.
That is why we are here...
I am left wondering why the "VPN (or Authpoint) aren't being used for the RDP connection." Wouldn't being connected to the VPN already give one direct RDP to internal computers without a separate firewall policy for RDP?
I am just curious!
Gregg
Gregg Hill
plz specify your solution, cause i have exactly the same problem.
When i choose from "Allow IKEv2-Users(any)) to "my trusted network" everything works perfect. The ikev2 clients can connect to all internal recources.
If i choose anything else (from: auth group or User ID, both Radius of course) i get no connection to my trusted, or optional networks.
With ssl this kind of seperation of my "homies"
I need the same kind of seperation with my ikev2 users.
MFA and login works perfect by the way.
Regards
Udo
Is your RADIUS server returning "IKEv2-Users" in the FilterID to the firewall when the IKEv2-Users group is specified in the "Allow IKEv2-Users" policy?
How RADIUS Server Authentication Works
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/authentication/radius_how_works_c.html
You can turn on diagnostic logging for authentication which may show something to help:
. Policy Manager: Setup -> Logging -> Diagnostic Log Level -> Authentication
or
. Web UI: System -> Diagnostic Log
Set the slider to Information or higher
thanx for your answer.
I will Check the logs monday, or tuesday.
By the way... Filter ID (11) points to my "vpnuser" group. Replication between AD and authpoint works fine.
I named this group in Authpoint and AD the same to avoid problems.
Is that maybe the problem?
And... FYI.. "I" have a M470 Cluster.
And.. It is (should be in the future
Reagards
Udo
To seperate my homies, i created several ad groups and corresponding, several nps rules. In the nps rules i pointed ID 11 to the corresponding ad group.
But... In Authpoint in the Radius Client Config, i choosed under "value sent for Radius attribute 11(filter-id)" Users Authpoint Group". After i choosed " Users AD Groups" everything works fine now.
No margin for mistakes...
Regards
Udo
good news