Sonicwall NSA 250m - how to block attempts to connect to L2TP VPN from intruders
The Sonicwall OS is 5.x. This is just the base router, no extra licenses for IPS, malware etc... I recently setup L2TP VPN for a couple users - using long and complex Pre-shared secret and each have a very long and complex password... I have been blocking obvious attempts from just IP addresses trying to access a webcam port using the info I found on how to do that - but blocking an IP address from WAN - doesn't seem to affect efforts of a couple outsiders trying to access via L2TP - I see the failed messages from the different stages... but they keep trying - and added their IPs to my 'Blocked IPs' address object group has no effect.
I want to be able to deny them access to even try to authenticate and get them out of the logs - like blocking IP addresses.
Anyone savvy on the SonicWALL as to how to prevent attempted L2TP connections from undesired sources? Is there a way to create access rules to block from L2TP to ANY or LAN, we have the network on the X0 interface.
My understanding is there is a VPN access list on the SonicWALL - but it does not apply to L2TP.
Thank you!
I want to be able to deny them access to even try to authenticate and get them out of the logs - like blocking IP addresses.
Anyone savvy on the SonicWALL as to how to prevent attempted L2TP connections from undesired sources? Is there a way to create access rules to block from L2TP to ANY or LAN, we have the network on the X0 interface.
My understanding is there is a VPN access list on the SonicWALL - but it does not apply to L2TP.
Thank you!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks for advice - yes I believe I could setup certificate based IPsec tunnel in L2TP but I have SSL VPN working now using NetExtender, NO Radius or Virtual whatever... It seems to me the setup of the SSL Server and the certificate choice which there is only one 'self signed certificate' as a choice, which I believe is by default available on the NSA, is also not so secure in that anybody using any username and password will get prompted to accept or trust that cert.
So shouldn't that be a concern?
Then its just a matter of them finding a username and password that matches one of the local users configured on the NSA... so its back to just cracking username and password. Am I wrong? Would it make a difference to import a purchased SSL cert and select that in SSL VPN server settings? Or would it too just be offered for trust. I am going to change port 4433 to an unused port and if the only barrier I have against entry to the network is username and password - I will as I did with L2TP use some pretty hard to crack usernames and passwords, then I trust the client when going to access resources on the remote network will be prompted for their Windows credentials... I am wide open to any clarification, suggestions or slaps upside the head...
Thanks Again!
So shouldn't that be a concern?
Then its just a matter of them finding a username and password that matches one of the local users configured on the NSA... so its back to just cracking username and password. Am I wrong? Would it make a difference to import a purchased SSL cert and select that in SSL VPN server settings? Or would it too just be offered for trust. I am going to change port 4433 to an unused port and if the only barrier I have against entry to the network is username and password - I will as I did with L2TP use some pretty hard to crack usernames and passwords, then I trust the client when going to access resources on the remote network will be prompted for their Windows credentials... I am wide open to any clarification, suggestions or slaps upside the head...
Thanks Again!
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
All good info Arnold... I will keep and check it out. I think I will be ok with the NetExtender as I also enabled the OTP - one time password in the local user profiles - where it sends a random password to their email address each time they go to connect. That should discourage anyone that isn't desired.
I hear you on the ports and how ISPs and apps are watching closer activity on uncommon ports... in my case, luckily, I am setting up access for just a couple people, owner and manager... versus a large group.
So I am trusting I will be ok with the built in self-signed cert, and uncommon port and OTP... all tested.
Thanks to you both for the help!
I hear you on the ports and how ISPs and apps are watching closer activity on uncommon ports... in my case, luckily, I am setting up access for just a couple people, owner and manager... versus a large group.
So I am trusting I will be ok with the built in self-signed cert, and uncommon port and OTP... all tested.
Thanks to you both for the help!
oh, two-factor authentication.. like mechanism. in this case, you may see remote requests make sure the response is the same whether the local user exists or not.
i.e. send me my code, prompt for username: someuser, the response should always be the key has been sent to your email.
If you have, no such user here, this will expose your side to be tested to discover the listed users..........
i.e. send to someuser, no such user,
send to anotheruser, your password has been emailed.....
i.e. send me my code, prompt for username: someuser, the response should always be the key has been sent to your email.
If you have, no such user here, this will expose your side to be tested to discover the listed users..........
i.e. send to someuser, no such user,
send to anotheruser, your password has been emailed.....
ASKER
I'll watch for that. Each local user has their email address added to their user setup.... Is this something that is true with the SonicWALL? Or are you theorizing this might be a possibility? I'll have to test that. Thanks!
Theorizing
If the option exists to generate the same response without regard whether an email was actually sent,
Some similar implementations have, the message an email was sent to your ab.....@.......org email address to assist the user to identify where the code should be looked for,
it seems you found a better alternative than trying to block intruders on an individual case by case basis.
If the option exists to generate the same response without regard whether an email was actually sent,
Some similar implementations have, the message an email was sent to your ab.....@.......org email address to assist the user to identify where the code should be looked for,
it seems you found a better alternative than trying to block intruders on an individual case by case basis.
ASKER
There is no notification of email sent etc.... user simply goes to connect - gets a very simple box to enter password... nothing else... I will test what happens when wrong or no password is entered and then to proceed with connect.
ASKER
And if password is wrong.... it will just state that the password is no good.... nothing else - no matter how many times tried, there should be a way to lock out the one attempting after so many failures.... I think I'm good here...
What happens if a wrong username provided?
ASKER
Again - there are no opportunities to go any further than 'wrong'... See attached file for pics of the OTP dialog and response to wrong info as well as initial connection via NetExtender if wrong user/pw entered.
What I want to find on this unit is a limit as to attempts like '5' before a lock in enforced - that applies to SSL VPN user login.
Logins-Failed.pdf
What I want to find on this unit is a limit as to attempts like '5' before a lock in enforced - that applies to SSL VPN user login.
Logins-Failed.pdf
See if the following helps,
https://www.sonicwall.com/en-us/support/knowledge-base/170503647039811
https://www.sonicwall.com/en-us/support/knowledge-base/170503647039811
It seems to me the setup of the SSL Server and the certificate choice which there is only one 'self signed certificate' as a choice, which I believe is by default available on the NSA, is also not so secure in that anybody using any username and password will get prompted to accept or trust that cert.
So shouldn't that be a concern?
I missed all the conversation somehow..maybe due to the holiday bustle...IDK. Anyway, I'd like to add that with SSL-VPN it is, always, recommended to use a proper SSL Certificate opposed to self-signed cert. Buy it at GoDaddy or the like and install it on the SonicWALL then select it to be used in the SSL config section.
Then its just a matter of them finding a username and password that matches one of the local users configured on the NSA... so its back to just cracking username and password. Am I wrong? Would it make a difference to import a purchased SSL cert and select that in SSL VPN server settings? Or would it too just be offered for trust. I am going to change port 4433 to an unused port and if the only barrier I have against entry to the network is username and password - I will as I did with L2TP use some pretty hard to crack usernames and passwords, then I trust the client when going to access resources on the remote network will be prompted for their Windows credentials... I am wide open to any clarification, suggestions or slaps upside the head...Obfuscation is never security so changing ports will do nothing. An adversary will simply scan your network for open/listening ports and discover them all then attempt to exploit vulnerabilities therein. I'd leave it at 4433; it is the default and recommended port to use. With SSL-VPN an adversary would have to known the port and domain name on top of the username/password. If you want to thwart that you can setup RADIUS and tie in authorization and authentication policies so now, as an example, a user would have to belong to a security group within the domain and additionally meet some security requirements before being allowed to authenticate. This could include blocking the user access as in Windows lockout or blocking the connecting IP address, etc. Certification would be on the NPS server so that clients could gain access from their smartphones and laptops (form-factor agnostic)! Cert-based authentication on the client side increases management significantly since smartphone OS's vary and are inconstantly increasing based on mfg; at least from what we have seen in the field.
2FA and UFA are always Best Security Practices!
@arnold has guided you well (as always :) )!
ASKER
Thanks BST, you got me started on the SSL VPN, so I went that route... and it does seem to me I would feel more 'secure' is I had a true SSL cert.... so I will look into that. There will be those scanning for a way in - and if setting the port to an uncommon port (and hope the ISP allows uncommon port traffic) makes these people take another step - as little as it is - then so be it. Its not going to be just sitting there on the common port. This really helps me with the whole SSL VPN idea and I appreciate you both for really guiding me here. This particular setup will not require any mobile device access... its pretty simple - a nice first time SSL VPN setup to get acquainted. Instead of going the Radius route, I used the OTP choice for users...one time password. And in talking with Arnold - want to see if I can setup a max # of login attempts before logout. It looks pretty unbeatable as each time the user connects the password changes...
I have this working as it is now with OTP option. I will be busy for a few days and then will post the findings as to max # user login attempts lockout...
I have this working as it is now with OTP option. I will be busy for a few days and then will post the findings as to max # user login attempts lockout...
OK, terrific! Post another question if you need help configuring the cert or with the lockout timers...I'm hear and ready! DM me when you post your question so I'll be sure to see it.
Just to clarify,
I'm glad we could help. Thanks for the points and see you next time!
Just to clarify,
...if setting the port to an uncommon port (and hope the ISP allows uncommon port traffic) makes these people take another step - as little as it is - then so be it.I understand that you want to change the default port but please understand there are no "extra" step, but literally one and only one step...command: scan for ALL open ports.
I'm glad we could help. Thanks for the points and see you next time!
ASKER
Thank you for the input. I have been using the L2TP solution - yes over IPsec... some years ago it was an obvious move - to have a more secure VPN then the old PPTP... I have this setup on other SonicWALL routers where they have the added software layers of protection - the subscribed Intrusion protection etc... and I understand the wackamole syndrome with IP addresses... I get it. I don't seem to have that problem - just occasionally on this base router.... Anyway, out of interest I will research the L2TP faults... and I think I will take your suggestion and go with the SSL variety... I have wanted to do that anyway.
Arnold, for lack of better term at the moment - intruders means those making efforts to connect that are foreign. We have the preshared key, we use a username and password - which in the past I have also made complex for both, so as Blue Street Tech has advised - I will look at the security issues with the L2TP, I know there are choices to be made in securing it.
Thank you both!
I will let you know how it goes - going for the SSL.... and maybe the GVC, but I had a lot of trouble over ten years ago with GVC - and that sticks with me - I am sure improvements have been made... we'll see.