網際網路安全的演進
首先，安全議題不能停留在討論概念，它必須清楚的被定義如何保護具價值的資源。從網路的演進歷程中來看，要擁有一個屬於自己的私有網路，大多必須建基於專線 (Leaded lines) 或是固接線路 (Dedicated lines) 上，但是有越來越明顯的趨勢，私有網路的需求必須從私有基礎建設跳昇到網際網路平台。
from private network to internet-based VPN
首先，專線或固接線路的成本較高，並且不容易跨越地區或組織；其次是網際網路的無遠弗屆與越來越穩定的連線品質；相較於專線或固接網路，網際網路達到HA (High Availability) 的標準並不困難；跨地區和跨組織的需求日益增多，專線和固接網路的侷限讓選擇透過網際網路來建立私人網路的比例大幅提高。
雖然，越來越多人選擇利用網際網路來建構部分或全部的的私人網路，不管其考量的原因是基於價格、彈性或是覆蓋率，IT管理者必須理解Internet-based VPN在任兩點之間資料傳輸的潛在弱點，即使是電信營運商所提供的專線或固接網路，依然存在著"Man in the middle"的風險。所以，不管是專線、固接網路或是Internet-based VPN，IT 管理者都必須另外建立一套安全管控機制。
Firewall for perimeter protection and IPSec VPN
於是，開始有人在私有網路的每個連接點上安置一個叫做Firewall的保護機制，大約自1994年以來這樣如同用城牆將組織資訊資源環繞保護的概念成為資訊安全保護機制的主流作法。於是許多組織開始採購大大小小的Firewall設備，也開始有廠商推出功能更簡單的小型防護設備，如：NAT。
Firewall在連接點上的閘道口提供了重重的防護警戒，但是針對閘道口之外的，從組織內部流出到公眾網路這一段網路上的資訊安全卻束手無策。專線與固接網路固然解決了一小段，但是透過公眾網際網路來進行私有網路的溝通行為需求愈熾，於是，1997年IPSec VPN 的標準公開，也帶動了這一波數億美元商機的產業蓬勃發展。從他的名字就不難猜到，IPSec是建基於IP通訊協定中大約在Layer 2到Layer 3 之間。IPSec假設連接通訊的兩端都具備 Public IP ，並且在佈建上是屬於變動性不高的架構。IP規劃在IPSec的架構中十分重要，IT管理者需要詳盡的計畫並且在佈建之前就知道需要連結的端點或個人，並且事先就納入計畫中。其中關於安全性的政策更是讓IT管理者覺得龐雜。因為IPSec是屬於比較低階層的通訊協定，所以對於屬於較高階層的應用層能夠處理的部分不多，所以連接通訊的兩端IP計畫與資訊安全政策經常性容易出現不相容的情況，而當連結的是一群龐大的端點互連時，這樣的問題常常讓IT管理者頭痛不已。商旅和行動工作的員工更是經常發現無法順暢連回辦公室的資訊環境，原因出在商旅和行動工作的員工所處環境，如客戶的公司或是飯店，可能有Firewall或NAT設備，執行了他們既有的資訊安全政策而阻斷了IPSec連線。網路管理者發現高階層通訊協定的資訊安全政策要轉換到低階層通訊協定的IPSec將變得非常複雜、冗長並且易於出錯。IPSec通常需要安裝一個客戶端軟體，相關的設定通常也造成了網路管理者額外的工作負擔。
SSL VPN
2001左右出現了SSL VPN這樣的解決方案來處理越來越多的遠端存取需求，他透過被廣為採用的SSL協定來進行傳輸，並且用"Clientless"的Browser外掛來解決客戶端軟體無法大規模部屬的障礙。SSL VPN解決了許多應用層的需求，擴充彈性、認證方式和使用者介面也都做了大幅度的改進，不管是單一組織或是合作夥伴，都能透過這樣的技術將彼此的資源做更好的整合。不過，即便SSL VPN已經相當令人驚艷，他依然停留在補救IPSec VPN的缺失，並且只具備"Client-to-Site"這一類遠端存取方案而已，他還稱不上是"Networked"解決方案。距離我們心目中“Extranet-to-Extranet” 交換方式、或 "Application-to-Application" 的整合介面都還有些距離。
Attempts to integrate IPSec and SSL VPN
UUDynamics試著提出一種新的架構，能夠具備低階層通訊協定的透通性和執行效率，以及高階層通訊協定的應用支援性與友善的使用介面。而這樣的一個新架構，是建構在現有環境的需求上：
|
