![]() ![]() Although we’re still running that box, its days are numbered. ![]() The second problem was with the IPSec VPN (sometimes referred to as a “normal” or “traditional” VPN to distinguish it from Secure Sockets Layer, or SSL, VPN) on our SonicWALL router. The users testing it out had found it faster and more reliable than the SSL VPN, so I really wanted to keep it. To begin with, what’s the problem? The PCI DSS scan reported this: The problem was that solving the scan failure looked horrendously complicated. Synopsis: The remote IKEv1 service supports Aggressive Mode with Pre-Shared key. Impact: The remote Internet Key Exchange (IKE) version 1 service seems to support Aggressive Mode with Pre-Shared key (PSK) authentication. Such configuration could allow an attacker to capture and crack the PSK of a VPN gateway and gain unauthorized access to private networks. – Do not use Pre-Shared key for authentication if possible. – If using Pre-Shared key cannot be avoided, use very strong keys. – If possible, do not allow VPN connections from any IP addresses. I smiled at the advice to “use very strong keys” because the security scan is automated and will fail on this issue no matter how strong the key is. Why does the SonicWALL even allow such a vulnerable configuration? When I logged the problem with SonicWALL, they didn’t answer that question but they did tell me: What didn’t make me smile, however, was the fact that this vulnerability has been known for over 10 years (that’s what the CVE number tells you). “Aggressive Mode” can only be disabled for a site-to-site VPN (which can run in “ Main Mode“).That didn’t help me as I’m not running site-to-site. The only alternative to Pre-Shared Key authentication is to use certificates.They sent me a wonderful out-of-date SonicWALL PDF document on using certificates. I read it and didn’t understand it.īefore expending effort to fix this problem I first wanted to satisfy myself that a “traditional” VPN is still a good choice. Surely SSL VPN is the preferred way these days? USING IPSECURITAS WITH SONICWALL FULLĪfter all, it needs special client software and gives the computers that connect full access to the LAN as if they were right there in the building. Sure enough, articles from Cisco or Barracuda, for example, highlight the advantages of SSL VPN. Our experience with the “portal” concept of SSL VPN has been disappointing (i.e., applications responding very slowly or not working at all). And when your remote office staff tell you that the IPSec VPN works better for them, you need to take notice. Making this work was a three-step process: On balance, therefore, we decided we had to bite the bullet and make our SonicWALL VPN behave. Install our wildcard SSL certificate on the SonicWALL.I enlisted the help of a local IT consultant, who was able to get to grips with SonicWALL’s convoluted documentation to do this. On the SonicWALL router, reconfigure the WAN GroupVPN (under VPN | Settings) to use IKE Using 3 rd Party Certificates instead of IKE Using Preshared Secret (another term for pre-shared key).Install the same certificate on the SonicWALL Global VPN Client (GVC) on each client machine.In this post I’ll describe step 1 in detail. USING IPSECURITAS WITH SONICWALL INSTALLĪ future post will cover the other two steps.USING IPSECURITAS WITH SONICWALL HOW TO.The only caveat to this is that the users can no longer make changes to their extensions with a browser session on the LAN because the SL1100 is now on a different one, unless IT wants to assist with some additional routing for that purpose. The VOIP phones are configured to hit the new IP. The netgear is set up to pass the traffic from the new IP to the NEC and NAT. A second IP from the carrier is either available (most ISPs give a business 5 useable IPs), or purchased, and the second port from the switch goes to a "dumber" less intrusive router like a Best Buy Netgear. ![]() One port goes to the Sonicwall and is essentially transparent. My solution in all cases was to take the internet connection from the carrier to a 5 port switch. The process takes too long and the VOIP packets time out to the SL1100 (wireshark revealed this). The problem seems to be with Sonicwall's packet inspection process. Never got one to work despite tech support involvement with NEC, customer IT departments and all the suggestions (ALG, Ports, etc.). Three installs that had Sonicwalls of various models and ages. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |