[ad]<\/p>\n
Requirement:<\/strong><\/em> To connect to a VPN server in a different country.<\/p>\n Situation:<\/strong><\/em> A country which has proxies at every gateway.<\/p>\n Issues:<\/strong><\/em> VPN based on IPSec is fussy when it comes across networks which are NAT’ted\/ proxied. The Security Parameters Indexes don’t match and clients do not get connected.<\/p>\n Objective:<\/strong><\/em> To connect VPN server in a corporate network using some flexible VPN which I can run on any port\/transport protocol so as to bypass the port\/protocols\/applications restriction.<\/p>\n Using these factors I came to conclusion that I needed SSL VPN solution. The following article explains the SSL VPN nuances and advantages of using them in certain situations.<\/p>\n Contents:<\/p>\n For a very long time, people in information security have thought IPSec is THE VPN and SSL is for secure online banking. While SSL has traditionally been used for Web site security purposes, SSL’s applications reach wider than just web proxying and application security.<\/p>\n Traditional SSL VPN started off with products that were more like SSL gateways instead of true VPNs. These products cannot be really termed as VPN but more like “Secure Remote Application Access”\u009d.<\/p>\n They thrive on a management facade called “Clientless VPN”\u009d. A VPN that can be established with any web browser without installing a software component sure promise less pain for users and administrators alike, but it comes with certain caveats that we will talk about later.<\/p>\n In the past, IPSec has been used as THE technology to create a VPN Site-to-site or site-to-client tunnel. IPSec has since long enjoyed widespread implementation because of its monopoly on function, although it has received its fair share of criticism for being too complex, and tightly coupled with Operating System.<\/p>\n IPSec came out in November 1988 with a series of RFC’s defining the protocols necessary to create VPNs. This RFC (2401-2412) represented a backbone of IPSec technologies. While IPSec does provide for a framework to establish a secure tunnel, it comes with a lot of complexity. Since complexity and security is inversely proportional, there are so many things with IPsec that may go wrong with wrong implementation. Thoroughly understanding everything and grappling with issues like Nat-T is something not everyone would be comfortable with.<\/p>\n Apart from that, IPSec being coupled tightly with Operating System doesn’t induce a sense of security. Any program integrated with kernel is against secure computing architecture. A wrong implementation or a security breach could take down the whole system.<\/p>\n Understanding the fact that IPSec is complex, industry started moving towards SSL based Remote Access solutions which may not be as secured as we want them to be. It’s because of the fact that a lot of these solutions push web browser as the client which can be used at any machine. The issue of ANY machine connecting to central site may not be very desirable as machines in cybercafes or public terminals do not form a part of control domain. Its desirable to run your upper layer protocols over SSL because it’s widely implemented and allowed in majority of packet filters.<\/p>\n Yeah…..but WHY OpenVPN??<\/p>\n <\/p>\n\n
1. What is an SSL VPN<\/h2>\n