SSL VPNs best IPSec rivals
Neoteris and Netilla prove SSL isn’t just for browsers anymore
The third type of access, the closest to an IPSec VPN, is called NC Access (Network Connect Access). This option downloads automatically as a small applet and provides support for TCP, UDP (User Datagram Protocol), ICMP (Internet Control Message Protocol), and all types of traffic over an SSL tunnel. You receive an IP address assigned by the Access Series 3000, and you can specify the destination addresses and ports users can connect to. I tested all three types of access and had no trouble connecting to resources both behind and outside of the Neoteris appliance. The native Windows file browsing worked like a charm.
Access Series 3000 also keeps your system secure by employing the Neoteris Host Checker API and Cache Cleaner. Host Checker performs an “are you there” call to each authenticated user to ensure they are using predefined client security software granting them access. Cache Cleaner purges your users’ browser cache on a preset schedule to remove traces of confidential material.
Overall, the Access Series 3000 provides all of the necessary pieces to solve the secure remote access puzzle. I really like the level of detail you can provide for each policy definition, and the appliance worked well no matter what type of traffic or application I threw at it. But I would like to see the default setting for file and Web resource access to be “deny all” out of the box.
NetillaSecurity Platform Release 4.0
The NSP is deceptively simple in its ability to securely allow trusted users access network resources. Like Access Series 3000, you get Web, thin-client, and thick-client access through the NSP.
The Web-based administration console is clean and easier to navigate than that of the Neoteris appliance. Though similar to the Neoteris in functionality, the NSP doesn’t have the same far reaching security options as the Access Series 3000. It does come with a stateful inspection firewall for even greater security and built-in fail-over support (with a second unit) for redundancy and maximum uptime.
When setting up the NSP, you first create a security realm (a way of grouping users, policies and authentication servers) and associate an authentication server to it. You authenticate against Active Directory or Windows domains, Radius, ACE, and Kerberos authentication server and also make use of a local user database. The NSP can have multiple realms to fit your user access requirements. Missing is LDAP, but that support is due early 2004. You can define browser, address, and URL restrictions as well, but there is no support for client-side certificates.
Creating policy definition is a little more cumbersome in the NSP, but it’s not too difficult to master. It also could stand to implement wizards-based policy deployment. An administrator associates applications to an authentication scheme and can set application properties such as cookie-support, forward browser variables or Web server version information. Enabling the policy entails creating a rule that either allows or denies traffic to the specific resource. I like that these multiple layers of policy definition, though a bit repetitious, leave the appliance in a “deny all” mode until you expressly allow the specified traffic.
In the NSP, you have the same three access methods as you do with the Access 3000 Series. The NSP handles thin-client access differently, however. Instead of passing traffic through to the application server, you start the apps from the portal page. Using the built-in Tarantella server, they’re then launched against your server.