Replacement for NetScreen Remote VPN client

... или разделям ли се с Juniper NetScreenRemote VPN client?

От скоро преминах към Windows 7 Ultimate 64-bit и останах разочарован като установих, че Juniper няма да разработват своя IPSec VPN клиент - NetScreenRemote (всъщност е на SafeNet) за 64-bit платформи и изцяло за Windows 7. Продажбата на 32-bit версии също е преустановена. За повече информация тук.
Освен разочарован се чувствам и частично прецакан, защото като добросъвестен клиент имам закупен пакетен лиценз за 100 потребители (разбира се по-стара версия, когато перспективите за 64-bit OS на клиентски машини бяха далечни, но все пак таях скрити надежди за безплатен или неболезнен ъпгрейд към по-нови версии). Но с големите не може да се бориш и затова реших да намеря алтернативно, безплатно и работещо решение на проблема.




Shrew VPN е безплатен IPSec VPN клиент за отдалечен достъп. В зародиш е бил проектиран за осигуряване на IPSec tunnel между windows хост и opensource vpn gateway - OpenSWAN, FreeSWAN или StrongSWAN. Впоследствие поддръжката му е разширена за Linux и BSD, както и за 64-bit. Предлага доста екстри характерни за комерсиалните продукти, което го прави много подходящ и съвместим с продукти на: Cisco, Juniper, Checkpoint, Fortinet, Netgear, Linksys и много други.

Ще разгледам в детайли инсталация върху Windows 7 Ultimate 64-bit и необходимата конфигурация при настройка на ShrewVPN Client v.2.1.5 към Juniper SSG140 firmware 6.2.0r2.0 (тестван и с SSG5 firmware 5.4.0r6)

Juniper SSG140 конфигурация - само CLI config, че не ми се занимава със скриин шотове на WebUI, а и за заинтересуваните от проблема предполагам не е проблем.

1. Създаваме vpn gateway
- тъй като използвам XAuth - първо създавам универсален IKE потребител за пробата - shrew

set user SHREW
set user SHREW type ike
set user SHREW ike-id fqdn shrew.domain.bg
set user SHREW share-limit 10
set user SHREW enable

- създавам Local Key Group и дабавям SHREW user, която после ще закачим към vpn-a

set user-group SHREW_GROUP
set user-group SHREW_GROUP user SHREW

- създавам Auto Key Advanced Gateway

set ike gateway SHREW dialup SHREW_GROUP Aggr local-id shrewvpn.domain.bg outgoing-interface eth0/2 preshare my_password proposal pre-g2-aes128-sha pre-g2-aes128-md5 pre-g2-3des-sha pre-g2-3des-md5
set ike gateway SHREW dpd-liveness interval 30
set ike gateway SHREW nat-traversal keepalive-frequency 5

NOTE: Shared IKE ID dial-up group configurated. Please note XAUTH server must be turned on as well.

set ike gateway SHREW xauth

- създавамe vpn-a:

set vpn SHREW-VPN gateway SHREW no-replay tunnel idletime 0 proposal nopfs-esp-3des-sha nopfs-esp-3des-md5 nopfs-esp-aes128-sha nopfs-esp-aes128-md5

- създавамe XAuth IP Pool, ако не е създаден по-рано, аз използвам съществуващия:

set ippool Dialup_users 192.168.200.xxx 192.168.200.xxx
set xauth default ippool Dialup_users
set xauth default dns1 192.168.xxx.xxx
set xauth default dns2 192.168.xxx.xxx
set xauth default wins1 192.168.xxx.xxx

- създавам IPSec Policy

set policy name SHREW-VPN from Untrust to Trust Dial-Up VPN 192.168.xxx.0/24 ANY tunnel vpn SHREW-VPN

- създавам XAuth user:

set user shrew.test
set user shrew.test type xauth
set user shrew.test remote ippool Dialup_users
set user shrew.test password my_strong_pass

Инсталация и настройка на клиента:

1. Изтегляме продукта от тук - съответно последната ver.2.1.5 (2.57 MB)
2. Инсталираме с последователността - Next > Next > INSTALL ,като за целта е нужно да сме потребител с административни права. За последващо използване на клиента от други потребители това не е нужно.
3. Стартираме ShrewSoft VPN - Access Manager


4. Създаваме нов профил чрез Add.


5. Client - Firewall Options
NAT Traversal е ясно защо конфигурираме, но интересния момент е поддръжката на IKE Fragmentation конкретно в ShrewSoft VPN client. Използвайки IPSec, знаем че пакета се енкапсулира с нов хедър и така MTU може да набъбне, особено използвайки Cerificate Authentication и пиърите обменят сертификати. Тогава именно чрез IKE fragmentation става възможно пренасянето на пакети през NAT-ващи рутери или през такива конфигурирани да режектват по-големи пакети. Затова в по-горната картинка MTU e сетнато на 1380!


6. Name resolution - WINS/DNS


7. Authentication - Local Identity


8. Authentication - Remote Identity


9. Authentication - Credentials


10. Phase 1


11. Phase 2


12. Policy - указваме отсрещната мрежа, която ще достъпваме, така както е зададена в политиката на VPN-a в SSG140.


13. Connect - Въвеждаме име и парола


14. Резултатът / Connection Status


и виждаме виртуалния адаптер с очакваните настройки:



15. Бележки

На пръв поглед прави приятно впечатление ресурсите на паметта, които използва за разлика от NSR.


Много удобна е възможността за import / export на конфигурационния файл. Това улеснява дистрибутиране на настройките на VPN клиента към крайни потребители без излишно усложняване на живота им.
Липсва опция, конфигурацията да бъде заключвана, правейки аналогия с NetScreenRemote, което беше допълнителна екстра за сигурността.
Функция AutoConnect се постига, чрез шорткът на ipsecc.exe със следните command line параметри:

ipsecc -r "name" [-u ][-p ][-a]
-r - Connection name с разширението .vpn в кавички
-u connection user name
-p connection user password
-a auto connect
или в моя случай имам следното в Target line на шорткъта:

"C:\Program Files\ShrewSoft\VPN Client\ipsecc.exe" -r "shrew_test.vpn" -u shrew.test -p shrew.test -a

След което шорткъта отива в StartUp.

Дали създава проблеми при съжителство с други VPN клиенти и по-конкретно с NSR е рано да ви кажа. В последствие ще направя тестове с други версии на Windows преди да го пусна в употреба в корпоративна среда.

IPSec през БТК ADSL

"Вдигане" на site-to-site IPSec VPN през БТК ADSL услуга е общо казано - приключение. Това не означава, че е невъзможно, но е свързано с множество проби, тестове и загуба на време. Но тъй като всички случаи са частни е грешно да се слагат под общ знаменател. Разликите са от вида на модема, версията на фърмуера, рутера зад него, който ще прави VPN-а, адекватни настройки на MTU, NAT Traversal и не на последно място - задклавиатурното устройство, което ги конфигурира.
Ако VPN ви е нужен за корпоративни цели – означава, че бихте могли да си позволите по-качествен и по-евтин интернет от местния кабелар. Разбира се, БТК може да ви предложи гарантирана услуга, но тя не се казва ADSL и не струва толкова пари. Има и случаи, в които ADSL е единствената и/или най-бърза алтернатива по места и затова понякога е нужно да се съобразяваме с наличното.
Всички знаем, че трябва да избягваме double side NAT, т.е. по възможност една от страните да не е зад NAT. Ако не може да се спази това условие, особено при IPSec тунел през ADSL пренос, би ви коствало време и нерви, като резултата никога не е гарантиран!

Да играем ли по правилата?
БТК си „връзва” гащите с едноличния контрол върху ADSL модемите и това е по разбираеми причини - за добро или лошо. Но защо да не избегнем NAT „услугите” на ZXDSL 831. Този „advanced device” работи чудесно в bridge mode – не забива и не чупи сесии. Ефекта е, че модема вече не се интересува от сесиите - той само качва MAC фрейма върху AAL5 и става напълно прозрачен за L3 ( TCP/IP ).
При няколко VPN имплементации с ADSL пренос, проблемите с NAT и със забивите на устройствата съм решавал с bridge mode на наличния модем или с друг ADSL модем/рутер. На нашия пазар съм виждал налични 3Com и D-Link, като приблизителната цена за D-Link беше 90 лв. Друг тестван и работещ вариант е с PCI карта Sangoma S518 и Open Source решение – в случая – Vyatta върху x86 PC.

ZXDSL 831IIV4.0.0f_B09_BG1

Смятам, че не е редно да описвам паролата за достъп до модема. Всеки би се почувствал „некомфортно” ако открие в Интернет парола с упътване за „менажиране” на собствената ви страница или блог. Доста верни и неверни неща са изписани по форумите, но в крайна сметка информацията е налична и процедурата за бриджване е изпълнима. Работи надеждно в няколко мои имплементации, където VPN-а се посреща от Juniper SSG или Linux машина зад ADSL модема.

Тънкия момент е получаване на PPPoE username / password. Приемаме, че разполагаме с име и парола и сме достъпили web-a.

- отворете http://192.168.1.1/constatus.html
- разкачате PPPoE връзката – изписва се username и скрита парола

- разглеждаме сорса на страницата (чрез Ctrl+U за Firefox), където се съдържа търсеното.
Изглежда по следния начин:

pppUserName.value = '4jjhtsE7ENB2jUSD';

pppPassword.value = base64Decode('SsetGlF6R3RGRnRqenPuDO==');

Виждаме, че паролата е кодирана (не е задължително при различните модели и версии на фърмуери) и за да я получим в чист вид (както username) – използвам http://www.motobit.com/util/base64-decoder-encoder.asp

или всеки един онлайн base64-decoder-encoder.

Bridging

Protocol: Bridging

Encapsulation Type: LLC/SNAP

В този режим всички пакети получени от един интерфейс (като АТМ PVC) се предават към другия интерфейс (LAN в случая). Тук можем да укажем IP адрес на LAN интерфейса. По принцип не е нужно да бъде модифицирано.

NEXT >

APPLY > REBOOT

След като рестартирането е приключило – DIAG LED изгасва. Модемът е в бридж режим и конфигурираме PPPoE на устройството зад модема.

3Com WL-542 – ADSL Wireless G Router

Тук използвам 3Com WL542 не по-различно от бтк-модем – единствено с надеждата за по-качествен хардуер. Дали е ценово ефективно? – само ще спомена, че този модем беше изровен от кашон на мой приятел с ИТ „скъпоценности”. Имплементацията е направена от спортна тръпка за пускане на друг ADSL модем, различен от този на БТК.

По-долу виждате видове връзки предлагани от 3Com-a, а използвания от мен режим е PPPoE.

Имам си PPPoE username / password
VPI / VCI = 0 / 35
Encapsulation - LLC



Пускане в bridge mode (For a single PC) е елементарно и следва описаната по-горе идеология. Тогава зад въпросния 3Com-WL542, Juniper SSG5 прави PPPoE и съответно IPSec site-to-site тунел по стандартна конфигурация.

Ето и сета за PPPoE на SSG5:
set pppoe name “adsl”

set pppoe name “adsl” username “4jjhtsE7ENB2jUSD” password “XXXXXXXXX”

set pppoe name “adsl” idle 0

set pppoe name “adsl” interface ethernet0/0

set pppoe name “adsl” auto-connect 60

GUI изглед:

Резултата е налице, връзката е стабилна и зависи предимно от надеждността на PSTN свързаността.

Vyatta 5.0.2 + Sangoma S518 ADSL Data Only Card (Annex A)

Решение с PC x86, Vyatta 5.0.2 Community Edition и Sangoma ADSL card.
Интересна постановка, но след непрекъсваемите забиви дори на сменения от страна на БТК ADSL модем, клиента се принуди да търси друг вариант. Използваната до момента Vyatta 4 беше обновена до 5.0.2, а DSL картата беше закупена през eBay за 45 $ без шипинг (цена за нова карта е около 120-130$). Скъпо удоволствие на фона на "безплатен" БТК модем, но ако се търси надеждност на хардуер при единствена алтернатива - ADSL свързаност - това е едно от решенията.

Sangoma е един от основните спонсори на Vyatta и обещават, че вече има 100% подръжка на техния хардуер. Във версия 4.1.3 – bug tracker-a казва, че PVC AUTO – не винаги детектва правилно VPI/VCI, но с актуалната версия при мен – нещата тръгнаха от първия път. Картата се оказа, че не е „истинска” Sangoma, a е Globespan Semiconductor Inc. Pulsar, но това не беше проблем.

Първо проверяваме мнението на линукса за PCI шините:
lspci

00:08.0 Network controller: Globespan Semiconductor Inc. Pulsar [PCI ADSL Card] (rev 01)

Проверяваме кои kernel модули се зареждат. Wanpipe е важен, за да може Vyatta да открие ADSL картата:
wanec 326456

wanpipe_lip 103300

af_wanpipe 34496

wanpipe 435356

wanpipe_syncppp 27864

wanpipewanrouter 39528
wanec,wanpipe_lip,af_wanpipe,wanpipe,wanpipe_syncpppsdladrv 65152 2 wanpipe,wanrouter

Vyatta CLI – ADSL PPPoE set
set interfaces adsl adsl0 pvc auto pppoe 0 default-route auto

set interfaces adsl adsl0 pvc auto pppoe 0 user-id

set interfaces adsl adsl0 pvc auto pppoe 0 password

set interfaces adsl adsl0 pvc auto pppoe 0 firewall in name FROM-EXTERNAL

set interfaces adsl adsl0 pvc auto pppoe 0 firewall local name TO-ROUTER

Juniper SSG140 to IPCop VPN interconnection

В практиката често се налага създаване на VPN тунели между различни рутери/защитни стени. Един случай, с който се сблъсках преди време е site-to-site IPSec VPN между Juniper SSG140 и IPCop 1.4.15. Реших да разпиша една работеща конфигурация, защото не открих нищо в готов вид из интернет пространството и по-конкретно за VPN свързаност към Juniper firewall устройства. „Натъжи” ме и факта, че повечето примери със „заплетени” VPN връзки на IPCop (или линукс базирани firewall-и) са към Cisco и други марки, а с Juniper устройства не се открива много. Но "който търси - намира" и с помощта на "неволята" се стигна до описаната по-долу конфигурация и до една значително по-интересна - когато IPCop е зад NAT, на не какво да е - а на БТК ADSL модем/рутер - ZXDSL832 (ISDN ver.). Този частен случай ще опиша по-подробно в някоя следваща публикация.

Диаграмата:

LAN (10.1.1.0/24) - SSG140 WAN (1.1.1.1) <–> Internet <–> IPCop RED (2.2.2.1) – GREEN (10.2.2.0/24)

SSG140

Untrust zone eth0/0 IP 1.1.1.1
Trust zone eth0/2 IP 10.1.1.1/24

IPCop 1.4.15
RED IP: 2.2.2.1
GREEN: 10.2.2.1/24

Juniper configuration CLI

Phase 1 Config
set ike gateway "IPCOP" address 2.2.2.1 Main outgoing-interface "ethernet0/0" preshare "secret" proposal "pre-g2-3des-md5"

set ike gateway "IPCOP" dpd interval 30

Phase 2 Config
set vpn "IPCOP-VPN" gateway "IPCOP" no-replay tunnel idletime 0 proposal "nopfs-esp-3des-md5"

Policy setup
set policy id 2 from "Trust" to "Untrust" "10.1.1.0/24" "10.2.2.0/24" "ANY" tunnel vpn "IPCOP-VPN" id 2 pair-policy 3

set policy id 3 from "Untrust" to "Trust" "10.2.2.0/24" "10.1.1.0/24" "ANY" tunnel vpn "IPCOP-VPN" id 3 pair-policy 2

IPCop configuration

ipsec.conf
config setup
interfaces="%defaultroute "
klipsdebug="none"
plutodebug="none"
plutoload=%search
plutostart=%search
uniqueids=yes
nat_traversal=no
virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:!10.2.2.0/255.255.255.0,%v4:!10.1.1.0/255.255.255.0

conn %default
keyingtries=0
disablearrivalcheck=no

conn Juniper #RED
left=2.2.2.1
leftnexthop=%defaultroute
leftsubnet=10.2.2.0/255.255.255.0
right=1.1.1.1
rightsubnet=10.1.1.0/255.255.255.0
rightnexthop=%defaultroute
ike=3des-md5-modp1024
esp=3des-md5
pfsgroup=modp1024
ikelifetime=8h
keylife=1h
dpddelay=30
dpdtimeout=120
dpdaction=restart
pfs=no
authby=secret
auto=start

ipsec.secret.conf
: RSA /var/ipcop/certs/hostkey.pem

2.2.2.1 1.1.1.1 : PSK 'secret'