limit SSLVPN to approved computers
It would be nice of SSLVPN client functionality could somehow be limited to known/approved/company computers. One problem with the current SSLVPN system is that the software can be installed on nearly any computer, including personal systems that could be infected with any type of unknown malware. Then, by way of the SSLVPN an approved user could put that infected computer on the corporate network with nearly no restrictions (by default).
In my opinion, this is a big security problem. Even if the client software download page was disabled on the firewall (which it currently can't), it's not difficult for anyone that can use google to download the software directly from WatchGuard. There should be some behind the scenes mechanism built into the SSLVPN software to only allow previously approved (aka company managed) systems to connect by SSLVPN even with the right user credentials. Essentially, 2 factor authentication for SSLVPN - 1st the computer, then 2nd the user.
Comments
So the SSLVPN software isn't specific to your firewall or company. You are using the same software that we are (and every WG SSLVPN user out there is). Limiting the software isn't feasible.
A better mitigation strategy would be to require MFA for user authentication and setup ACL's for the VPN network traffic.
I'm not sure how ACL's could be used to prevent a legitimate SSLVPN user from using his personal computer. And what I'm suggesting is MFA with the approved computer being one of those factors.
ACL's won't stop an authorized user from using their personal computer. Besides Policy, i'm not aware of any current technical means of preventing that. Maybe 802.1x requiring Computer and User authentication over the vpn?
Note that one can use the OpenVPN client too, although one does need the SSLVPN config info, which one can easily download from the firewall
I agree, there is no current technical means of preventing this. That's why I've posted this in the Product Enhancement forum - as an enhancement suggestion.
Another simpler solution that WG could implement: Require Client side Certificate (where the CA cert needs to be loaded on the Firebox).
I would like to see this too.
We have had a few people connect personal devices to the SSL client, I’m currently finding the IP addresses of people who are logged in twice then running Advanced IP Scanner on the IP range of our VPN clients. This then confirms to me what host name they are using if it doesn't link up with our naming convention they are then sent an email to explain why they are using a personal device however this isn't always 100% accurate on the host names it pulls through when looking at the IP addresses showing. The only way I can see on how to limit access is in the link below but not convinced this is the best way
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/networksetup/restrict_by_mac_c.html
Checkout the 12.5.4 Beta. It has a feature that may help.
See the "Client Downloads" section here, which describes the possible solution. It does not help for existing users who have installed the client on their personal device(s).
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/mvpn/ssl/configure_fb_for_mpvpn_ssl_c_before.html
Also, MAC addr restrictions only work for local devices not behind some sort of routing device.
For Internet devices, the MAC addr of incoming packets is from the previous routing device interface - such as the ISP router which is forwards packets to the firewall.
+1 for client side certificates - we already deploy computer authentication certificates for WiFi/RADIUS internally, so it would be lovely to use the same certs with the VPN client.
This is now a feature with the newer firmwares, but it also requires enforcing the TDR Agent which is on Total Security firewalls.
We have set it up and it works, the only issue is that it authenticates onto the VPN .... but it does black the machine from doing anything without the TDR Agent (My guess is there currently isn't away to have the SSL VPN Client check for TDR BEFORE connecting to VPN)
Check this link for directions:
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/services/tdr/tdr_host_sensor_enforcement_configure.html#
(Must have 12.5.4 or higher)
You could switch to IpSec VPN. This way only computers with the IPSec Passkey could establish a VPN connection to your firewall. Much more secure than SSL.
Agree it'd be nice to have this as an option for SSLVPN, which is why in the last setup I did I had to implement IKEv2 and then change the certificate to one signed by the client's internal CA to limit who has access to it.
It doesn't use user certificates unfortunately (I have an open enhancement request for that) but combining this with an MFA-enabled RADIUS setup could help in that regard too (which I can't do for an AlwaysOn VPN unfortunately - which is where the user certificates come in).
So is this the only option with the TDR enforcement? It would be good to be able to include an Active Directory Computer Group. With TDR I have a slight issue in that a few laptops are running Ubuntu and there seems to be issues with TDR on Ubuntu and these users are very fussy with performance. I guess I could exempt those in some other way. Anyway this is still a feature that is really required now that most people around the globe will continue to WFH.
Hi @svitadmin
If you're using AD, by default the user will need to be in the SSLVPN-Users group (unless you set up/use a different group.)
The only way around the users not being in that group is to go through them one-by-one in the SSLVPN configuration and allow them there (which basically just manually puts them in the SSLVPN-Users group.)
-James Carson
WatchGuard Customer Support
I am hoping that soon they are going to enable "WatchGuard EndPoint" enforcement (which has agents that work fine on Linux!)
> I am hoping that soon they are going to enable "WatchGuard EndPoint" enforcement (which has agents that work fine on Linux!)
Note that they did end up making it so that you can enforce users to use the right VPN settings and such via EPDR as of a few months ago.
That’s the main solution I’m aware of to make sure that only company computers have access to your environment as it will use whether or not the computer HAS EPDR as a metric for allowing access.
I don’t think the SSL vpn client (or even IKEv2) provide enough logs to the firewall on host info about the client so I would imagine it being a challenge to program without using something like an agent to do without restructuring what logs they gather from these technologies (or if that info is even allowed to be grabbed)