The new issue of Network Magazine has a cover story that may be worth a look: "SSL VPNs: Remote Access for the Masses," by Andrew Conry-Murray, which makes a pretty convincing case for the use of SSL VPNs instead of IPSec. A lot of this is still-emerging stuff and the author, to his credit, doesn't pull any punches saying so. But it does make the point that, although IPSec has many admirable design ideas, deployment is sticky. http://www.networkmagazine.com/shared/article/showArticle.jhtml?articleId15201419&classroom In a similar vein is Lisa Phifer's "VPNs: Tunnel Visions, How do SSL VPNs match up with their older IPSec cousins?" in the August issue of Information Security: http://infosecuritymag.techtarget.com/ss/0,295796,sid6_iss21_art83,00.html Naturally, given the audience, she focuses much more on the security specifics. Of particular interest: IPSec prevents packet modification to thwart man-in-the-middle attacks. However, this strong security feature also generates operational problems. NAT frequently breaks IPSec because it modifies packets by substituting public IP addresses for private ones. Many IPSec products implement NAT traversal extensions, but support for this feature isn't universal, and interoperability is still an issue. SSL is almost as tough against man-in-the-middle attacks, without IPSec's NAT conflict. SSL rides on TCP, so it's insulated from IP and port modifications, and thus passes easily through NAT. SSL carries sequence numbers inside encrypted packets to prevent packet injection, and TLS uses message authentication to detect payload changes. And Phifer notes later that one of the critical issues with SSL VPNs is whether you want to "Webify" everything. For all of us (I hope), the net is much more than just port 80. fred