Is there a way to hide or make the public VPN portal more secure?
lostbackups Newbie ✭
edited February 2022 in VPN Client
I currently have our SSLVPN set up with MFA TOTP code for remote user access.
See attachment - basically if you go to my company's public IP on that port, you can see the sign in page along with our internal AD domain name. This seems like more information than I would want to give out to the world. I can see scans and potential brute force and other attacks eventually occurring.
Category: VPN Client
Hey! You will be signed out in 60 seconds due to inactivity. Click here to continue using the site.
@lostbackups, you don't need to use your actual domain name for the Domain section, you could have just left as LocalDomain or something else.
I actually tried that but got an error (I forget what it was), then when setting it to our correct domain name, I was able to get in. I can try it again just to be sure though.. To be clear, user's are signing in with their AD credentials with Sonicwall MFA.
@lostbackups, if using the UTM Appliance which it looks like you are ( unless you are using authentication partitioning ) then the Server entry in the SSL VPN Server Settings page can be left as LocalDomain (this can be anything but is case sensitive), this entry doesn't actually link to your AD/LDAP and doesn't actually do anything it is just used as Server name that is needed for the SSL VPN Portal to work.
the LDAP part is only for the Users Authentication and access rules, not for the actual SSL VPN connection, otherwise locally created users on the firewall wouldn't be able to connect as they are not part of the AD Domain.
Yes, I am using a UTM appliance (NSA 3600) and domain users are connecting via NetExtender with their domain credentials (not local Sonicwall user accounts). I don't know what authentication partitioning is but I'm using LDAP + Local Users for User Authentication settings.
See my new screenshot for details showing that changing the User Domain to "LocalDomain" to change what shows in the Virtual Office Domain also affects domain users from authenticating into the VPN via NetExtender.
Hi lostbackups, It should work (nothing wrong with the SSL VPN settings as far as I can see), I notice though you are using SSO make sure that the SSL VPN IP pool (the address object you re using for the SSL VPN client) or the service SSL VPN (4433) is excluded from the SSO under SSO/enforcement tab
I'm a little confused about the SSO bit. Can you elaborate? I have the Sonicwall configuration tool installed which I believe is related to the SSO agent. That doesn't have to do with SSLVPN I don't think...
It's best practice not to use your internal domain name as the SSLVPN User Domain (Im pretty sure even the KB article says this).
Don't use the Self-signed certificate for SSLVPN. Purchase one from a trusted CA to use for this (it can be a wildcard cert).
Geo-IP filtering DOES apply to inbound connections to the SSLVPN portal. Either use the global settings, or configure it with a custom list to restrict access.
HI @lostbackups, if you have set up the SSL VPN as per the guide below you shouldn't have any issues, I mentioned the SSO as it can interfere with remote connections unless excluded from the SSO in the Exceptions tab, trust me this is from years of experience using SonicWalls with SSO so I would recommend excluding the SSL VPN network, even if it say's it is not enforced on a Zone level on the Top menu on the Enforcement Tab