NetScreen i SonicWall traktują swoje systemy VPN z dolnej półki jak klienty sprzętowe. Muszą być one konfigurowane przy użyciu techniki innej niż zdalny dostęp. Stosuje się technikę push - podsyłania reguł z centralnego serwera - która nawet w małych instalacjach nie skaluje się dobrze, jeżeli klient sprzętowy ma dynamiczny adres IP spoza zakresu NAPT (Network Address and Port Translator), jak w rozwiązaniach zdalnego dostępu opartych na modemach lub DSL.

Innym aspektem zarządzania klientami zdalnego dostępu jest uzyskanie pewnego zakresu kontroli nad zintegrowanymi rozwiązaniami, zwłaszcza zaporami ogniowymi strony klienckiej. W rozwiązaniach Check Point opcjonalna zapora ogniowa strony klienckiej jest konfigurowana za pomocą interfejsu przypominającego tworzenie reguł dla zapór ogniowych przedsiębiorstwa. Miniaturowa wersja motoru inspekcji pakietów zapory ogniowej jest instalowana na kliencie, a konfiguracje VPN i zapory ogniowej są pakowane w jeden blok reguł, którym centralny zarządca reguł steruje i które automatycznie uaktualnia.

Cisco i NetScreen zapewniają zarządzanie zaporami ogniowymi strony klienckiej. Interfejs Cisco nie jest tak elegancki jak Check Point, ale pozwala na ustawienie prostych filtrów pakietów dla zapory klienckiej i pewnych powiązań z innymi centralnie zarządzanymi produktami, np. pochodzącymi od Zone Labs i Internet Security System.

Cisco i NetScreen oferują także mechanizm pozwalający blokować połączenia VPN, jeżeli zapora ogniowa nie jest aktywna.

Większość innych dostawców pakuje osobistą zaporę ogniową z klientem VPN (Avaya jest tu wyjątkiem), ale nie zapewnia obsługi centralnego zarządzania regułami i uaktualnieniami w połączeniu z zarządzaniem VPN.

Konieczne odstępstwa

Standardy IPSec są w rzeczywistości głównym źródłem problemów zdalnego dostępu VPN. W celu zrekompensowania ich niedostatków większość dostawców VPN rozszerzyła je na wiele różnych sposobów. Chociaż odstępstwo od standardu nie jest zazwyczaj szczęśliwym posunięciem, to jednak nie widać realnej możliwości zbudowania dobrego IPSec zdalnego dostępu VPN bez ryzyka wyjścia poza specyfikację. Zmniejsza to w sposób oczywisty możliwość współdziałania, a także wiąże użytkownika z jednym dostawcą. Zmniejsza też swobodę wyboru platformy klienta VPN. Praktycznie do każdej platformy są klienty IPSec niezawierające specyficznych rozszerzeń dostawców, ale wdrożenie więcej niż kilku klientów tego typu może się okazać rozwiązaniem niezarządzalnym.

Jednym z obszarów, gdzie zdalny dostęp i IPSec kolidują bezpośrednio, jest obsługa NAT i NAPT. NAT i NAPT to techniki używane przez IPSec, zwłaszcza w środowisku szerokopasmowym, do radzenia sobie z niedoborem adresów IP metodą współdzielenia przez wielu użytkowników pojedynczego adresu IP lub puli adresów IP do przesyłania ich pakietów przez Internet. NAPT i inne rodzaje dynamicznego adresowania, takie jak klient DHCP (Dynamic Host Configuration Protocol) czy Point-to-Point Protocol via Ethernet, są w prawie wszystkich wdrożeniach sieci szerokopasmowych.

Wewnętrzna adresacja jest kolejnym niestandardowym rozszerzeniem w zdalnym dostępie. Wspomaga wewnętrzny ruting w bardziej złożonych sieciach, ponieważ pakiety przybywające via VPN wychodzą tą samą drogą. Ponadto wewnętrzne zapory ogniowe mogą identyfikować użytkowników VPN na podstawie ich adresu, co upraszcza kontrolę dostępu i wymuszanie reguł polityki ochrony.

SonicWall nie zapewnia obsługi wewnętrznej adresacji. NetScreen obsługuje wewnętrzną adresację, ale jedynie w wypadku stosowania protokołu L2PT jako protokołu tunelowania. Najprostszym przypadkiem jest przyporządkowanie puli adresów do koncentratora VPN i zapewnienie możliwości ich przydziału.