Защищенные виртуальные каналы могут быть сформированы и на сеансовом уровне модели OSI. Для этого применяются так называемые "посредники каналов" (circuit proxy). Посредник функционирует над транспортным уровнем, шифрует и ретранслирует трафик из защищенной сети в общедоступную сеть Internet для каждого сокета в отдельности. При приеме выполняется обратная процедура. Сокет IP идентифицируется комбинацией TCP-соединения и конкретного порта или заданным портом UDP.
Для шифрования информации на сеансовом уровне наибольшую популярность получил протокол SSL/TLS (Secure Sockets Layer/ Transport Layer Security), разработанный компанией Netscape Communications. Этот протокол создает защищенный туннель между конечными точками виртуальной сети, обеспечивая взаимную аутентификацию абонентов, а также конфиденциальность, подлинность и целостность циркулирующих по туннелю данных. Ядром протокола SSL/TLS является технология комплексного использования асимметричных и симметричных криптосистем компании RSA Data Security. Для аутентификации взаимодействующих сторон и криптозащиты ключа симметричного шифрования используются цифровые сертификаты открытых ключей пользователей (клиента и сервера), заверенные цифровыми подписями специальных Сертификационных Центров. Поддерживаются цифровые сертификаты, соответствующие общепринятому стандарту Х.509. С целью стандартизации процедуры взаимодействия клиент-серверных приложений TCP/IP через сервер-посредник (брандмауэр) комитет IETF утвердил протокол под названием SOCKS, и в настоящее время пятая версия данного протокола (SOCKS 5) применяется для стандартизованной реализации посредников каналов. SOCKS поддерживает приложения, требующие контроля над направлениями информационных потоков и настройки условий доступа в зависимости от атрибутов пользователя и/или информации. В соответствии с SOCKS 5 клиентский компьютер устанавливает аутентифицированный сеанс с сервером, исполняющим роль посредника (proxy). Использование этого посредника является единственным способом связи через брандмауэр. Посредник, в свою очередь, проводит любые операции, запрашиваемые клиентом. Поскольку посреднику известно о трафике на уровне сеанса (сокета), он может осуществлять тщательный контроль, например, блокировать конкретные приложения пользователей, если они не имеют необходимых полномочий.
В отличие от виртуальных сетей, защищенных на сеансовом уровне модели OSI, виртуальные сети, защищенные на канальном или сетевом уровне, обычно просто открывают или закрывают канал для всего трафика по аутентифицированному туннелю. Это может представлять проблему, если локальная сеть на другом конце туннеля является неблагонадежной. Кроме того, созданные туннели канального и сетевого уровня функционируют одинаково в обоих направлениях, а виртуальные сети, защищенные на сеансовом уровне, допускают независимое управление передачей в каждом направлении. Виртуальные сети с посредником канала типа IPSec ориентированы на протокол IP. Если IPSec, по существу, разграничивает защищенные виртуальные каналы между разными парами взаимодействующих сторон, то протокол SOCKS 5 обеспечивает создание защищенных туннелей для каждого приложения и сеанса в отдельности. Аналогично протоколу IPSec и протоколам туннелирования канального уровня, виртуальные сети сеансового уровня можно использовать с другими типами виртуальных частных сетей, поскольку данные технологии не являются взаимоисключающими. Следует отметить, что имеются протоколы для реализации защищенного взаимодействия и на прикладном уровне модели OSI. Эти протоколы, как правило, являются дополнениями к различным протоколам прикладного уровня. Например, протокол Secure HTTP (SHTTP) является дополнением по функциям защиты к протоколу передачи гипертекста HTTP, а протокол Secure MIME (S/MIME) — дополнением по защитным функциям к протоколу электронной почты MIME. Прикладные протоколы защиты информационного взаимодействия не относят к протоколам построения защищенных виртуальных сетей, так как они полностью зависят от используемых сервисов и приложений. Протоколы формирования защищенных виртуальных каналов прозрачны для прикладных протоколов защиты. Соответственно применение приложений, реализующих, например, SHTTP или S/MIME, наряду с криптографической защитой на более низком уровне, нисколько не уменьшает, а только увеличивает уровень безопасности.