2011-05-08

Reguláris kifejezések a különféle network OS-ekben (1.)

Az előző posztban említett kézi hálózatfelderítés során többször is alkalmaztam IOS alatt reguláris kifejezéseket a különféle parancsok kimenetének szűrésére, nem kell bonyolult dolgokra gondolni, csak nagyjából ilyesféle szűrésekre:

DEVICE#sh mac-address-table | include Gi1/0/1
   1    0001.e674.baa6    DYNAMIC     Gi1/0/13
   1    0001.e674.bab8    DYNAMIC     Gi1/0/1
   1    0001.e6a2.02b6    DYNAMIC     Gi1/0/13
   1    0002.e33c.5203    DYNAMIC     Gi1/0/13
   1    0002.e33c.5316    DYNAMIC     Gi1/0/15
   1    0002.e34f.08fd    DYNAMIC     Gi1/0/13
   1    0002.e34f.0a42    DYNAMIC     Gi1/0/13
   1    0002.e352.8dbb    DYNAMIC     Gi1/0/13
   1    000f.fe02.3f48    DYNAMIC     Gi1/0/13
   1    000f.fe30.880e    DYNAMIC     Gi1/0/13
   1    000f.fe31.920d    DYNAMIC     Gi1/0/15

DEVICE#sh mac-address-table | include Gi1/0/1$
   1    0001.e674.bab8    DYNAMIC     Gi1/0/1


Nyilván egyértelmű a különbség azok számára is, akik nem ismerik a regexpeket. A $ kifejezés a keresendő minta végéhez illeszkedik, tehát az az megelőző szöveges mintának a sorvégeken kell szerepelnie, ezért nem jelenik meg egy olyan sor sem a második példában, amelynek a végén nem pontosan a "Gi1/0/1" karaktersor áll. Ez persze az egyik legegyszerűbb példa, számtalan egyéb dolgot bevethetünk még, a regexpek használatának lehetősége átszövi az IOS-t, legtöbbször persze a különféle show kimeneteket szűrjük meg velük, de vannak más alkalmazási lehetőségek is, többek közt ilyen a BGP AS-path szűrés. Vajon mi a helyzet az egyéb OS-ekben?

A márciusban kiadott legújabb FortiOS-ben (4.0MR3) a CLI referencia kézikönyv szerint az alábbi területeken nyílik lehetőségünk regexp használatra:
  • Data Leakage Prvention (DLP) szabályok definiálásakor
  • BGP AS-path szűrésre
  • Különféle e-mail szűrésekhez (e-mail cím alapú levélszűrésre, spamszűrőkben, MIME header szűrésre)
  • Weboldalak tartalom- illetve URL alapú szűrésére
  • CLI-ben a get, show és diagnose parancsok kimenetének szűrésére (a szokásosnak mondható include, exclude parancsok helyett itt egyszerűen csak grep a szűrő parancs)
A H3C/3Com örökséget tovább vivő HP Networking termékekben szintén megtalálható a regexp támogatás, hogy pontosan mire is használható, arról a  "Reguláris kifejezések a különféle network OS-ekben" következő részében lesz szó.

2011-04-13

Network discovery módszerek

Mit tehetünk akkor, ha a feladatunk a világ másik végén lévő telephely LAN-jának minél alaposabb feltérképezése, és nincs semmiféle dokumentáció, amivel neki lehetne kezdeni a feladatnak? A helyi IT-s munkaerő nem ismeri igazán a hálózati eszközöket, ha kell, néhány alapvető dolgot -- hostname, IP, default gateway, admin jelszó -- be tud állítani webes felületen, de itt nagyjából kimerül a szakértelem.

Ilyenkor az lenne a legjobb, ha az ember csak ráeresztene valami okos szoftvert a megfelelő subnetre, az meg minden kis információmorzsát felcsipegetne, benézne ide is, oda is, HTTP-n, HTTPS-en, telneten, SSH-n, SNMP-n, amelyiken éppen lehet, végül kiadna egy részletes layer 2-es topológia ábrát hostnevekkel, IP-kkel, portszámokkal, az eszközök típusával, meg minden. A valóság ezzel szemben az, hogy nem véletlenül jut el a világnak erre a felére a probléma, az adott telephelyen a LAN eszközök nincsenek egységesen konfigurálva, különböző felhasználónevek és jelszavak vannak rajtuk beállítva (ha egyáltalán be van állítva valami), több különböző gyártótól valóak, vicces hurkokat kötöttek rájuk, némelyiknek még IP-je sincs.

A tipikusan ilyesmire használt gyártóspecifikus szoftverek, mint amilyen régi kedvencem, a 3Com Network Director (3ND) vagy újabban az azt felváltó HP Intelligent Management Center - IMC (bár szerintem ez kissé nehézkesre sikeredett) vagy a Nortel Enterprise Switch Manager vagy a Cisco Network Assistant nem igazán rúgnak labdába ilyen helyzetben, és soha nem lesz pontos az, amit kiköpnek magukból egy discovery után, de azért kiindulási alapként nem feltétlenül rossz az. Jelenleg épp a 3ND és a Cisco Network Assistant volt kéznél, gondoltam kipróbálom, mire mennek.

A menedzsment szoftverek alternatívájaként pedig ott a CLI-s buherálás, első körben nmap-pel kiszűrhetők az adott subnetben lévő gyanús hostok: a már említett protokollok portjai közül legalább egy nyitva van, szerencsésebb esetben több is (TCP-80, TCP-22, TCP-23, TCP-443, UDP-161), ezekről listát készít az ember, összeszedi a helyi IT-től előzetesen begyűjtött jelszavakat, majd jöhet a favágás: megpróbálni belépkedni mindenhova. A sikeres műveletekről táblázat készül, hogy egy adott IP adott portján mivel lehetett belépni. Ha a subnet elfogyott, akkor jó eséllyel a legtöbb távolról adminisztrálható eszközt sikerült azonosítani, így már csak a köztük lévő kapcsolatokat kell feltérképezni. A kapcsolatok feltérképezésében óriási segítség a CDP, NDP vagy egyéb hasonló protokoll által begyűjtött információ, ám nem mindig elegendő. A végső megoldás annak megállapítására, hogy mely portra van kötve egy-egy eszköz, a CAM tábla nézegetése. Ha sikerült bejutni már akár csak egyetlen eszköz parancssorába, onnantól a subnet összes hostjának MAC címét meg tudjuk keresni, egy ping után ott lesz az ARP táblánkban. Az ARP táblából kikeresett MAC címet utána már megleljük a CAM táblában is, és ha kell, switchről switchre, CAM tábláról CAM táblára végig lehet követni addig a portig, ahová az adott eszköz ténylegesen be van dugva. A CAM tábla további előnye, hogy megmutatja az összes csatolt switchet, hubot: ha azt látjuk a CAM táblában, hogy mondjuk az Fa0/8-as porton 13 MAC címet tanult be az eszközünk, akkor biztosak lehetünk benne, hogy a 8-as porton lóg még valamilyen hálózati eszköz, akár mutatja a CDP neighbor-ök közt a switchünk, akár nem (leszámítva az olyan extrém eseteket, mint például a virtual hostok, ahol virtuális a switch is). Végül a CLI-ben elérhető STP, LACP információk alapján pontosíthatjuk a topológiát, bejelölve a redundáns linkeket is. Hát, ez a kézi módszer, sziszifuszi meló, az biztos.

No, de hogy valami érdekes is jusson végére, az említett telephely feltérképezését megcsináltam 3ND-vel, Cisco Network Assistant-tal és kézzel is. Amint az utólag kiderült, a telephelyen az eszközök többsége Cisco volt, szóval a 3ND-nek eleve nem voltak nagy esélyei. Gondoltam érdemes az eredményeket számszerűsíteni is, ha a layer2-es topológia gráfjának minden megtalált éle és csúcsa egy-egy pontnak számít (az élek estén szükségesek a portok információi is a ponthoz, pl. egyik eszköz Gi1/0/2-ről megy a másik Gi0/1-re), akkor a következő eredmények születtek:

A kézi módszerrel 41 pontot sikerült elérni, 21 csúcs és 20 él került fel a topológia ábrájára (semmi redundancia), ez összesen 16 Cisco eszközt jelent, egy 3Com eszközt és négy közelebbről nem azonosítható, feltehetően unmanaged switchet. Természetesen messze ez a módszer igényli a legtöbb időt, a management szoftverek néhány vagy néhány tíz perces discovery idejéhez képest itt több óráról van szó.

A Cisco Network Assistant 20 pontot gyűjtött, a 16 Cisco eszközből 11-et megtalált, köztük egy olyat is, mely csak a CDP neighbor-ök közt volt megtalálható, egyébként nem volt IP cím beállítva rajta. A többi Cisco eszközre különféle okokból nem tudott bejelentkezni, az egyik például szolgáltatói eszköz volt az ötből, amelyhez nincs jelszavunk, a maradék négy Cisco eszközökhöz pedig csak Telnet hozzáférés volt, amit nem tudott használni, míg az egyéb (nem Cisco) eszközöket pedig hivatalból ignorálta. De legyünk méltányosak a programhoz, az általa megrajzolt topológia pontos volt, nem húzott be téves éleket a gráf csúcsai közé, minden teljesen egybevágott az eszközökből kinyerhető CDP információkkal, így sokat segített a kézi módszer felgyorsításában, ellenőrzésében.

A 3Com Network Director meglepetésre 21 pontot ért el, összesen 16 eszközt talált meg (ugye emlékszünk: a maradék 5 eszköznek nincs IP címe!), ám csak 5 kapcsolatot fedezett fel az eszközök közt helyesen, a többi eszköz fura felhőkön keresztül csatlakozott vagy csak úgy lógott a levegőben. Vitathatatlanul ez volt a legzajosabb módszer, számos nyomtató és egyéb SNMP-képes eszköz bukkant fel a topológiában, igaz ezeket nem volt nehéz kiszűrni.

A végső találati arányokat még sajnos nem tudom, ugyanis nemrég küldtem el a helyi IT-snek ellenőrzésre a kézi módszerrel összeállított topológiáról a Visio ábrát, amit ki fog egészíteni/javítani a tényleges állapotoknak megfelelően. Remélhetőleg a 41 pont nem lesz messze a valós értéktől...

2011-03-30

A tűzfalazás magasiskolája

A mostanában -- illetve már egy éve -- futó WAN átszervezős projektünk keretein belül belefutottam egy újabb szánalmas problémába. A projektben soron következő néhány telephelyhez igen sok tűzfalszabály kapcsolódik az egyik legfontosabb site-unk  tűzfalában, ami azért gond, mert ezeket a szabályokat a WAN migrációval párhuzamosan kell megváltoztatni, más zónákba kell majd kerülniük ezeknek a szabályoknak, zónákból is elég sok van, az említett telephelyekhez kapcsolódó szabályokból még több, szóval gyanús, hogy nem lesz a dologból sikertörténet.

Még annyit érdemes tudni, hogy a tűzfal többek közt a fontos site-on is ki van szervezve, és nincs közös irányelvek alapján dolgozó belső csapatunk a tűzfalas kérdésekre, ráadásul az ezzel foglalkozó emberek is jönnek-mennek. Van persze egy alapvető biztonsági szűrés a tűzfalas kérésekre, de itt nagyjából meg is áll minden egységesítési törekvés. Ha ezt még megfűszerezzük azzal, hogy a tűzfal szolgáltatást nyújtó cég sem ugyanazokra az emberekre delegálja a kéréseinket (értelemszerűen), akkor azért nagyjából el lehet képzelni, hogy hogyan néz ki egy-egy ilyen kiszervezett tűzfal. A legkisebb bajom az, hogy nincs egységes megközelítés, hogy mikor használjunk pl. a szabályok SRC és DST mezőiben sima IP-t, IP-t netmaskkal, szimbolikus, külön definiált neveket vagy a belső DNS-eken feloldott domainneveket, szóval ez teljesen ötletszerű, és ember legyen a talpán, aki egy-egy szabályról ránézésre megállapítja, hogy honnan hová tilt vagy engedélyez bizonyos forgalmat.

Épp azon lamentáltam a tűzfalszabályokat böngészgetve, hogy hogyan lenne érdemes ezt megközelíteni, amikor megpillantottam a GUI-n a "Column settings" opciót... és igen, volt benne "Count" mező is, bekapcsoltam, majd jött a döbbenet. A már említett fontos telephely tűzfalszabályainak 76 százaléka szemét. Nem volt azokon a szabályokon semmilyen forgalom a tűzfal utolsó firmware frissítése óta, ami azért nem két napja történt (148). Jó, ebből a 76%-ból lejön valamennyi, például bizonyos VPN tunnelekhez kapcsolódó szabályok, amely tunnelek csak akkor kezdenek el érdemben forgalmazni, ha szakad a bérelt vonal itt vagy ott, de azért a 76 százalék az 76 százalék. Tiszta sor: nincs gazdája a rendszernek, a szabályok csak bekerülnek, olykor többször is, és valójában sem a cégünk, sem a tűzfalat szolgáltató cég nem törődik a rendszerrel.

Szóval megkérdeztem a főnököt, hogy mit szólna, ha azt a jó néhány száz szabályt, ahol 0 bájt volt a forgalom, töröltetnénk, utána már könnyebb lesz a WAN migráció. Meglátjuk, mit szól hozzá.

2011-03-15

Firmware frissítés 3ComOS-t futtató XRN (IRF) switch stacken

Korábban már érintőlegesen volt szó a 3ComOS-ről, ami tavaly ugye mindenestül a HP kezébe került, de gyakorlatilag ugyanez a szoftver fut a Huawei és a H3C eszközökön is. Ma ismét előszedhettem a 3ComOS ismereteimet, a nemzeti ünnep ugyanis kiváló alkalom a szoftverfrissítések terítésére. Aki ismeri valamennyire a korábbi 3Com, illetve a jelenlegi HP, H3C, Huawei vonalat, az tudja, hogy egészen élhető stack technológia van ezekben a vasakban, viszont a stack a szoftverfrissítés során nem nagy előny. Az XRN vagy újabban IRF stackek nem állnak ugyanis össze, csak akkor, ha pontosan azonos a szoftververzió a stack unitjain. Innentől viszont érdemes észnél lenni, hogy mikor, mit csinál az ember, és bizony a hivatalos dokumentumok sem viszik túlzásba a stack-es szoftverfrissítési folyamat ismertetését. Vannak persze ezekhez a dolgokhoz is management eszközök (3Com Network Director, HP Intelligent Management Center), amivel GUI-n összekattintgatja az ember a frissítést, viszont ha elég sok stackünk van, akkor ilyen vagy olyan okból mindig akad egy-kettő, ahol elhasal a GUI és jöhet a mindenható CLI-s bütykölgetés.

Az első lépés a hely felszabadítás a beépített flash modulokon, nem mindegyik típusnál fér ugyanis el két különböző szoftververzió egymás mellett, nyilván a nagyobb, drágább eszközökön ez nem gond, de ha access stackekről van szó, akkor a helyhiány mindennapos probléma lehet a frissítéskor. A dir /all /fabric paranccsal egyszerre ki tudjuk listázni az összes uniton a fájlokat unitonkénti bontásban:
<HOSTNAME>dir /all /fabric              
Directory of unit1>flash:/


   1 (*)   -rw-     10199  Mar 10 2011 08:43:52   3comoscfg.cfg
   2       -rwh       293  Mar 02 2011 01:56:03   private-data.txt
   3       -rw-      9705  Feb 29 2008 12:00:00   3comoscfg.def
   4 (*)   -rw-   4171170  Mar 15 2011 15:56:51   s3n03_03_02s168p06.app
   5 (*)   -rw-    981062  Mar 15 2011 16:00:08   s3p04_03.web


7239 KB total (2055 KB free)


Directory of unit2>flash:/
... a többi unit adatai...
A listából láthatjuk, hogy mennyi szabad hely van még unitonként, illetve azt, hogy mely fájlokat futtatja aktuálisan a rendszer. A fenti példában látható, hogy az s3n03_03_02s168p06.app a bootloadernek megadott rendszer image, a webGUI-hoz pedig az s3p04_03.web fájlból veszi az adatokat az OS, hely viszont még egyszer ugyanennyihez nincs (általában a többi uniton is ugyanez a helyzet). Ilyenkor le kell egyenként törölgetni a fájlokat minden unitról a delete paranccsal (delete unit1>flash:/s3n03_03_02s168p06.app), majd ugyanez a unit2-vel, unit3-mal... illetve a műveletet érdemes megismételni a web package-ekre (*.web) is. Valami ilyesmit fogunk kapni eredményül:
<HOSTNAME>dir /all /fabric               
Directory of unit1>flash:/


   1 (*)   -rw-     10199  Mar 10 2011 08:43:52   3comoscfg.cfg
   2       -rwh       293  Apr 02 2008 01:56:03   private-data.txt
   3       -rw-      9705  Feb 29 2008 12:00:00   3comoscfg.def
   4       -rw-   4171170  Mar 15 2011 15:56:51   [s3n03_03_02s168p06.app]
   5       -rw-    981062  Mar 15 2011 16:00:08   [s3p04_03.web]


7239 KB total (2055 KB free)


Directory of unit2>flash:/
... a többi unit adatai...


<HOSTNAME>reset recycle-bin /fabric
Squeeze the recycle bins in fabric ? [Y/N]:y
 Unit1 reset success!
 Unit2 reset success!
 Unit3 reset success!
 Unit4 reset success!
 Unit5 reset success!
 Unit6 reset success!
A hely csak a recycle-bin ürítés után szabadul fel ténylegesen, amit egyetlen paranccsal meg tudunk tenni minden unitra a reset recicle-bin /fabric kapcsolójával. Ebben az állapotban nem jó, ha újraindulnak eszközök, mert nem fognak tudni bebootolni (természetesen konzolról vissza lehet küzdeni magunkat, de jobb az ilyesmit elkerülni, ha van rá mód), így mihamarabb másoljuk fel minden unitra a friss szoftvert:
tftp 10.10.10.10 get s3n03_03_02s168p11.app unit1>flash:/s3n03_03_02s168p11.app
tftp 10.10.10.10 get s3n03_03_02s168p11.app unit2>flash:/s3n03_03_02s168p11.app
stb.


tftp 10.10.10.10 get s3p04_04.web unit1>flash:/s3p04_04.web
tftp 10.10.10.10 get s3p04_04.web unit2>flash:/s3p04_04.web
stb.
A fájlokat egyébként elegendő egyszer letölteni a stackre, és onnantól lehet a unitok közt is másolgatni a copy paranccsal. Bizonyos frissítésekhez új bootloader (*.btm) is jár, ilyenkor ezt is le kell töltenünk minden unitra:
tftp 10.10.10.10 get s3o04_04.btm unit1>flash:/s3o04_04.btm
tftp 10.10.10.10 get s3o04_04.btm unit2>flash:/s3o04_04.btm
stb.
Ha felmásoltuk a szoftvereket, jöhet a használatba vétel, be kell állítanunk (még a régi) bootloaderhez az új szoftver image-t -- természetesen minden egyes uniton:
<HOSTNAME>boot boot-loader unit1>flash:/s3n03_03_02s168p11.app 
 The specified file will be booted next time on unit 1!
<
HOSTNAME>boot boot-loader unit2>flash:/s3n03_03_02s168p11.app 
 The specified file will be booted next time on unit 2!
stb.
Ha van bootloader frissítés, akkor azt is minden uniton be kell állítani (a beállítás után egyébként a *.btm fájlok törölhetők, de ha ott maradnak, az sem számít):
<HOSTNAME>boot bootrom unit1>flash:/s3o04_04.btm
 This will update Bootrom on unit 1.  Continue? [Y/N] y
 Upgrading Bootrom, please wait...
 Upgrade Bootrom succeeded!
<
HOSTNAME>boot bootrom unit2>flash:/s3o04_04.btm
 This will update Bootrom on unit 2.  Continue? [Y/N] y
 Upgrading Bootrom, please wait...
 Upgrade Bootrom succeeded!
stb.
Végül a friss web package beállítása következik, már ahol szükség van egyáltalán ilyesmire. Ezt nem kell unitonként állítani, egyszer kell kiadni a következő parancsot:
<HOSTNAME>boot web-package s3p04_04.web m
Ha mindennel elkészültünk, akkor jöhet a stack újraindítása a reboot paranccsal.

2011-03-14

A Babel routing protokoll

Épp az OpenWRT oldalán böngésztem a híreket (egyre türelmetlenebbül várom a tavalyi 10.3-as verzió frissítését), amikor olvasom, hogy holnapután Barcelona mellett lesz a "Wireless Battle Mesh v4". Hát az meg mi? No, nem mintha elmennék vagy ilyesmi, de sosem hallottam még csak hasonlóról sem, ezek meg már a negyediket rendezik...

Némi kutakodás után, bár sokkal okosabb nem lettem, arra jutottam, hogy ez valamiféle perverz geek találkozó, ahol tényleg foglalkoznak wifivel, de a hangsúly nem ezen van, hanem a routingon. Egy-egy ilyen esemény alkalmával összedobnak egy mesh hálózatot, amelyben minden egyes eszközön (a mesh gráf csúcsai) routeolás folyik és valamilyen irányító protokoll fut.

Itt jön a lényeg, hogy milyen protokollt érdemes választani? A rádiós hálózatok ugyanis a vezetékesekkel szemben számos meglepetést tartogathatnak. Változhat például a topológia az eszközök mozgatása, ki-be kapcsolása nélkül is, az épp aktuális rádiós viszonyok függvényében, és a vezetékes világban megszokott, gyakorlatilag kétállapotú összeköttetések (a mesh gráf élei) -- amelyek ugye vagy működnek vagy nem -- helyett előfordulhatnak olyan "működő" kapcsolatok, amelyek érdemi információtovábbításra nem alkalmasak, mert igen jelentős rajtuk a csomagvesztés.

A legizgalmasabb az egészben, hogy új irányító protokollokat tesztelnek és hasonlítanak össze egymással ezen a mesh hálózaton. Részt lehet venni bármilyen nyílt forrású implementációval, ami működőképes OpenWRT alatt. Az külön poén, hogy ilyenek tényleg vannak, a felhívás szerint ezen a negyedik mesh találkozón a Babel, a B.A.T.M.A.N., a BMX (B.A.T.M.A.N. Experimental) és az OLSR protokollok biztosan szerepelnek. Egy picit utánaolvastam mindnek, és találtam egy összehasonlító elemzést is, amely szerint a Babel a nyerő.

Ezek után a Babel doksit végig is nyálaztam, kiderült, hogy ez egy új távolságvektor-alapú protokoll, az említettek közül ez a legfiatalabb, kifejezetten mesh wifihez készült, de állítólag vezetékes környezetben is megállja a helyét. A  teljesség igénye nélkül a protokoll néhány fontosabb jellemzője:

  • A Babel által használt metrika a prokollt futtató szomszédos eszközök közötti kommunikációra épül, az eszközök Hello üzeneteket küldenek szomszédaiknak, amelyekre azok az "I Heard You" (IHU) választ kapják. Az üzenetváltások sikeressége alapján a babeles eszköz költséget számol minden egyes szomszédjához, értelemszerűen a költség annál kisebb, minél kevesebb a sikertelen üzenetváltás.
  • A protokoll alapvetően a Bellman-Ford algoritmusra épít (periodikus frissítések minden szomszédtól és ezen frissítések alapján a legalacsonyabb költségű útvonal kiválasztása, illetve a végtelenig számlálás), bizonyos megszorításokkal.
  • Ilyen megszorítás, hogy egy adott router nem vesz tudomást egy másikhoz vezető  frissítésekről, amíg azok kisebb költségűek, mint a rajta nyilvántartott eddigi legkisebb költség az adott célhoz (a nagyobb költségűeket pedig épp azért hagyja figyelmen kívül, mert ott nagyobb a költség, így nem éri meg átváltani rájuk).
  • Az előző pont, bár megakadályozza a hurkok kialakulását, a topológia módosulásakor route-ok használhatatlanná válásához vezet, ezért a Babel által küldött frissítésekben szekvenciaszámok is szerepelnek, és egy frissítés átmegy a szűrőn, ha a szekvenciaszám nagyobb, mint az eddig látott szekvenciaszám.
  • A szekvenciaszám növelését kérhetik is a routerek egymástól, minden routernek saját szekvenciaszáma van. A szekvenciaszám-növelési kérelmek jelentősen felgyorsítják a konvergenciát.
  • Ha azonos prefixet meghirdet több eszköz is, akkor azokat a prefixeket a Babel külön entitásként kezeli, vagyis mindenki a hozzá "közelebbi" forrást fogja használni.
  • Támogatja az IPv4-et és az IPv6-ot is.

Gyaníthatóan ez a kis összegzés több kérdést vet fel, mint amennyit megválaszol, a végső válaszok a protokoll dokumentációjában érhetők el.

2011-03-02

DHCP relay agent NAT-olt hálózatban: esélytelen

Adott egy telephelyünkön egy több subnetre osztott LAN, minden subnetben a LAN router a DHCP relay agent, ez így eddig tiszta sor, semmi meglepő nincs benne. Na most vannak persze olyan subnetek is ezen a telephelyen, amelyek nincsenek Layer 3 összeköttetésben a telephely egyéb részeivel, ezer oka lehet, a legtöbb persze nem szakmai, mindenesetre ilyesmi dolgot kell elképzelni:


A gondok természetesen akkor kezdődnek, amikor a 192.168.1.0/24-ben mégiscsak akadnak hostok amelyek a többi subnettel kommunikálnának. Persze ilyenkor a network admin kaján vigyorral közli, hogy látjátok-látjátok, nem kellett volna azt a subnetetet így oda tenni, megmondtuk mi annak idején, hogy olyan hálózatot válasszatok, ami illeszkedik a globális címzési rendszerünkbe és a telephelyen használt supernetben benne van.

Aztán a vigyor, meg a címzési tervek gyorsan eltűnnek, amikor kiderül, hogy itt most nem "légből kapott", "ködös" elvekhez kell ragaszkodni, hanem a felmerülő üzleti igényeket kell gyorsan, pontosan kiszolgálni, és nincs apelláta: a 192.168.1.0/24-nek tudnia kell kommunikálni, most, nincs sem idő, sem erőforrás, sem hajlandóság az utált subneten belüli 150+ statikus IP-s hoston címváltásra (vagyis nem lehet belőle semmilyen körülmények közt sem pl. 10.10.15.0), és igazából csak a VLAN99-ből kell elérni egy-két külső dolgot, "hát már ennyit sem lehet rátok bízni?" stb.

Száz szónak is egy a vége, meg kell patkolni, egy végzetes napon a VLAN99 NAT-olva rácsatlakozik a VLAN10-re. Aztán jönnek az újabb és újabb problémák, amelyek fel sem merülnének ugye, ha a VLAN99 rendes subnet lenne, olyanok például, hogy egyik-másik adatbázis szervert a VLAN99-ben mégiscsak el kellene érni kívülről, legyen port forward, ezt ide, azt oda, akkor persze jön a kérdés, hogy miért nem lehet a belső adatbázis-szervereket kívülről pingelni, aztán újabb és újabb port forwardok, persze az egész rögtön biztonsági kérdéseket is felvet, mert természetesen a VLAN99-ben nincs szabványos kliensvédelem, hiszen az úgyis "szeparált", szóval egy-két év alatt ebből egy teljesen dokumentálatlan össze-vissza rugdosott rendszert lehet felépíteni, amihez senki nem nyúl szívesen, akik meg használják, elégedetlenek.

Na, most ott tart a dolog, hogy a VLAN99-ben be kellene vezetni a központi DHCP szolgáltatást, és persze sikerült ráfutni a DHCP relay agent beüzemelése közben egy elég alapvető problémára: NAT-olt hálózat felé nem fog menni a relayezés, hiszen a relay agent még csak kiküldi a VLAN99-ből a DHCP üzeneteket a DHCP szerver felé, azonban a relay agent és a DHCP szerver közt már unicast forgalom zajlik, amely kommunikációban a relay agent a belső, a DHCP szervertől távolabbi lábának az IP-jével vesz részt (pl. 192.168.1.1), így a DHCP szerver hiába küldené vissza a választ a default gatewayen... Persze így vagy úgy folytatódni fog a hályogkovácsolás, át lehet azt a DHCP-t küldeni ezer más módon.

Az egészben a legbosszantóbb, hogy az üzleti oldal még mindig, sok év után sem látja, hogy itt az alapkoncepció hibás, ugyanakkor újabb és újabb dolgokat építene az ingatag alapokra. Erős IT-t szeretnék, ahol nem engedik ki az IT kezéből az IT-ra tartozó döntéseket.

2011-02-15

Radia Perlman az STP-ről és sok minden másról

Elképesztő, hogy micsoda könnyedséggel tud beszélni Radia Perlman mindenféle hálózati  protokollokról, és hogy mennyire meg tudja ragadni a lényeget egy-egy szinte ovis szinten felvázolt ábrával. Bájos az is, hogy nem hagyja magát zavartatni csip-csup részletekkel (pl. a TRILL részleteinek tágyalásánál a per-ingress tree melleti érvelés a 36-37. percnél). Szóval szinte tátott szájjal néztem végig a TRILL protokollról (Transparent Interconnection of Lots of Links) szóló előadásáról készült videót, amelyben felvázolja az általa gyakorlatilag egyetlen este kitalált STP protokollhoz vezető lépéseket (hatalmas a sztori az első bridge-ről, amibe beletették az STP-t, kb. 15:30-tól), illetve részletesen beszél a felvétel készítése óta (2008) nem túl nagy karriert befutott TRILL-ről.

2011-02-11

GRE tunnel IPSec-ben Cisco és Vyatta eszközök közt

A nem azonos gyártótól származó eszközök közötti korábbi egyszerű IPSec tunneles posztok után gondoltam, kipróbálom az IPSec-be ágyazott GRE tunnelt Cisco és Vyatta eszközök közt. Bár a GRE alapvetően Cisco technológia, más gyártók is támogatják használatát, többek közt a Vyatta rendszerek is.

A GRE/IP tunnelek nagy előnye az egyszerű IPSec tunnelekhez képest, hogy külön virtuális tunnel interfészünk van, ami az unicast IP forgalmon kívül (amit az egyszerű IPSec tunnel is tud) ismeri a multicastot és a broadcastot is, így akár egy olyan irányító protokoll is működhet GRE-n keresztül, mint az OSPF. Ugyanakkor a GRE/IP semmilyen biztonságot nem nyújt, nem titkosított a payload benne, ezért is gondolták a Cisco-nál, hogy jó ötlet lesz az IPSec-kel házasítani, így született meg a GRE/IPSec, amit egy Cisco routeren körülbelül így kell konfigurálni (az IPSec beállítások megegyeznek a korábbi táblázatban leírtakkal):
crypto isakmp policy 10
  encr aes 256
  hash sha
  authentication pre-share
  group 5

  exit
 

crypto isakmp key TITOK address <peer IP>
 

crypto ipsec transform-set TESZTSET esp-aes 128 esp-md5-hmac
exit                                                 
 

crypto ipsec security-association lifetime seconds 3600
 

crypto ipsec profile TESZTPROFIL
  set transform-set TESZTSET
exit
 

interface Tunnel 0
  ip address <tunnel IP-je> <netmask>
  tunnel source <saját külső IP>

  tunnel destination <peer IP>
  tunnel protection ipsec profile TESZTPROFIL
exit

Látható, hogy nincs szükség GRE/IPSec esetén crypto map-re, tehát crypto ACL-re sem (amivel egyébként egy kis figyelmetlenséggel pillanatok alatt ki tudjuk zárni magunkat a távoli routeről), így nem kell megadnunk azt sem, hogy milyen subnetből milyen subnetbe megy az IPSec-kel védett forgalom, hiszen az a GRE tunnelben fog utazni, az IPSec fölött, így az IPSec-nek elég azt tudnia, hogy mi a két IP a GRE tunnel két végén (tunnel source, tunnel destination), e két IP közt pedig elég a GRE forgalmat titkosítani, minden más már a GRE-n belül fog utazni. Na, ez az, amit nem lehet összehozni Vyatta alatt, legalábbis most (VC-6.1) még nem, de talán már a következő kiadásban benne lesz.

Megjegyzés (2011-08-26): a Vyatta 6.3-as verziójától kezdve elérhető a kérdéses lehetőség, amit egy külön posztban meg is vizsgáltam.

Létezik azonban más megközelítés is: ha közbeiktatunk egy loopback interfészt, és mi magunk drótozgatunk össze egy GRE/IPSec-like megoldást. A lényeg változatlan marad, a GRE alatt IPSec lesz, viszont ezt a Vyatta is támogatja. Az ötlet alapvetően annyi, hogy a GRE tunnelt fizikai interfészek helyett loopback interfészek IP-i közt húzzuk ki, és ezeket a loopback IP-ket engedjük át az IPSec tunnelen, az IPSec pedig ugye már a rendes külső IP-nken fog átmenni a peerhez. A túloldalon ugyanúgy él a két router közti IP kapcsolat, ott is rátesszük az IPSec-et, abba is beletesszük a loopbackek közti GRE-t, amibe végül önthetjük mindazt, amit meg ezen az oldalon szeretnénk látni. Konfiguráció szempontjából persze kényelmetlenebb ez a fenti megoldásnál mind a Cisco mind a Vyatta oldalán, de a végén lehet egy olyan GRE tunnelünk IPSec felett, amelyben szépen dolgozgat az OSPF, és bármilyen egyéb hálózatot átrouteolhatunk rajta, függetlenül attól, hogy mi van beállítva a crypto ACL-ben. Simán megéri. A tesztkörnyezet topológiája a következő:




Konfiguráció az R1-Cisco eszközön:
hostname R1-Cisco

interface Loopback1
  ip address 10.10.127.1 255.255.255.255
  exit
interface Tunnel1
  ip address 10.10.47.1 255.255.255.252
  tunnel source 10.10.127.1
  tunnel destination 10.10.127.2
  exit
interface FastEthernet0/1
  ip address 10.1.1.1 255.255.255.0
  duplex auto
  speed auto
  exit

crypto isakmp policy 10
  encr aes 256
  hash sha
  authentication pre-share
  group 5
  lifetime 28800
  exit

crypto isakmp key TITOK address 192.168.12.2

crypto ipsec transform-set TESZTSET esp-aes esp-md5-hmac
  exit

access-list 100 permit ip host 10.10.127.1 host 10.10.127.2

crypto map TESZTMAP 10 ipsec-isakmp
  set peer 192.168.12.2
  set transform-set TESZTSET
  set pfs group5
  match address 100

interface FastEthernet0/0
  ip address 192.168.11.2 255.255.255.252
  crypto map TESZTMAP
  exit

router ospf 1
  network 10.1.1.0 0.0.0.255 area 0
  network 10.10.47.0 0.0.0.3 area 0
  exit

ip route 0.0.0.0 0.0.0.0 192.168.11.1
Konfiguráció az R2-Vyatta eszközön:
set system host-name R2-Vyatta

set interfaces ethernet eth0 address 192.168.12.2/24
set interfaces ethernet eth1 address 10.2.2.1/24
set interfaces loopback lo address 10.10.127.2/32
set interfaces tunnel tun1 address 10.10.47.2/30
set interfaces tunnel tun1 encapsulation gre
set interfaces tunnel tun1 local-ip 10.10.127.2
set interfaces tunnel tun1 remote-ip 10.10.127.1

set vpn ipsec ike-group TESZT-IKE-GROUP
set vpn ipsec ike-group TESZT-IKE-GROUP lifetime 28800
set vpn ipsec ike-group TESZT-IKE-GROUP proposal 10
set vpn ipsec ike-group TESZT-IKE-GROUP proposal 10 dh-group 5
set vpn ipsec ike-group TESZT-IKE-GROUP proposal 10 encryption aes256
set vpn ipsec ike-group TESZT-IKE-GROUP proposal 10 hash sha1

set vpn ipsec esp-group TESZT-ESP-GROUP
set vpn ipsec esp-group TESZT-ESP-GROUP proposal 10 encryption aes128
set vpn ipsec esp-group TESZT-ESP-GROUP proposal 10 hash md5
set vpn ipsec esp-group TESZT-ESP-GROUP pfs enable
set vpn ipsec esp-group TESZT-ESP-GROUP lifetime 3600

set vpn ipsec site-to-site peer 192.168.11.2
set vpn ipsec site-to-site peer 192.168.11.2 authentication mode pre-shared-secret
set vpn ipsec site-to-site peer 192.168.11.2 authentication pre-shared-secret TITOK
set vpn ipsec site-to-site peer 192.168.11.2 ike-group TESZT-IKE-GROUP
set vpn ipsec site-to-site peer 192.168.11.2 local-ip 192.168.12.2
set vpn ipsec site-to-site peer 192.168.11.2 tunnel 1
set vpn ipsec site-to-site peer 192.168.11.2 tunnel 1 local-subnet 10.10.127.2/32
set vpn ipsec site-to-site peer 192.168.11.2 tunnel 1 remote-subnet 10.10.127.1/32
set vpn ipsec site-to-site peer 192.168.11.2 tunnel 1 esp-group TESZT-ESP-GROUP

set system gateway-address 192.168.12.1
set protocols ospf area 0 network 10.10.47.0/30
set protocols ospf area 0 network 10.2.2.0/24

2011-02-05

IPSec site-to-site VPN Cisco és Fortigate eszközökkel

A korábbi Cisco-Cisco majd Cisco-Vyatta felállás után jöjjön most ismét ugyanaz, ám Cisco-Fortinet variációban. A teszteszköz egy Fortigate 60-as, még a régebbi, 3-as FortiOS-szel, de ugyanezek a CLI parancsok használhatók a legfrissebb 4-es verziójú FortiOS-ekben is. A korábbi topológia változatlan:


Az IPSec beállításokat összegző táblázat szintén változatlan, a Cisco-Cisco posztban megtalálható. A vyattás felállással ellentétben a FortiOS parancsokat nem próbálom megfeleltetni az IOS-es parancsoknak, alapvető szemléletbeli különbségek vannak a Fortigate tűzfalak és a Cisco routerek közt, túl sok lenne a különbség, így az IOS-t futtató R1 eszköz beállításai itt nem is szerepelnek, pontról pontra ugyanazt a konfigurációt használtam, amit korábban is.

A korábbi versenyzőkkel ellentétben a Fortigate viszonylag terjedelmes gyári beállításokkal érkezik, NAT/route üzemmódban (ez az alapértelmezett) a következő IP-k vannak a fizikai interfészeken beállítva:
  • Internal: 192.168.1.99
  • WAN1: 192.168.100.99
  • WAN2: 192.168.101.99
  • DMZ: 10.10.10.1
Az alapértelmezett user/jelszó páros: admin/nincs jelszó, ha nem tudjuk a jelszót, állítsuk vissza az eszközt a gyári beállításokra. A bejelentkezés után kezdhetünk az interfészekkel, a WAN1 porton lesz a WAN kapcsolatunk (10.1.1.0/24), az internalon pedig a belső háló (10.3.3.0/24), a többit le lehet lőni:
config system interface
    edit "internal"
        set ip 10.3.3.1 255.255.255.0
    next
    edit "dmz"
        set status down
    next
    edit "wan1"
        set ip 10.1.1.2 255.255.255.0
    next
    edit "wan2"
        set status down
end
A következő lépés a Phase1 adatok megadása, minden további beállítás esetén az itt létrehozott néven (TESZT-PH1) tudunk erre a VPN kapcsolatra hivatkozni.
config vpn ipsec phase1-interface
    edit "TESZT-PH1"
        set interface "wan1"
        set proposal aes256-sha1
        set keylife 28800
        set remote-gw 10.1.1.1
        set psksecret TITOK
end
Szükségünk lesz természetesen Phase2 beállításokra is, amelyek a már létrehozott Phase1 beállításokra fognak épülni:
config vpn ipsec phase2-interface
    edit "TESZT-PH2"
        set pfs enable
        set phase1name "TESZT-PH1"
        set proposal aes128-md5
        set dst-subnet 10.2.2.0 255.255.255.0
        set keylifeseconds 3600
        set src-subnet 10.3.3.0 255.255.255.0
end
Ezzel maga az IPSec konfiguráció ugyan készen van, de ne feledjük, hogy a Fortigate-ek alapvetően UTM eszközök, magától szinte semmi sem működik, ha csak nem kreálunk hozzá tűzfalszabályokat. Mielőtt azonban ténylegesen a tűzfal policy-khez nyúlnánk, definiálnunk kell a subneteket, amelyekkel dolgozgatni szeretnénk a későbbiekben:
config firewall address
    edit "R2-belso-subnet"
        set associated-interface "internal"
        set subnet 10.3.3.0 255.255.255.0
    next
    edit "R1-belso-subnet"
        set associated-interface "TESZT-PH1"
        set subnet 10.2.2.0 255.255.255.0
end
Miután készen vannak a subnetek, jöhet a tűzfal policy. Ha az alapértelmezett beállításról indulunk, akkor észrevehetjük, hogy egy szabály már létezik a tűzfalon, ami az R2 belső subnet hostjai számára hozzáférést engedélyez a WAN1 interfészen keresztül elérhető dolgokhoz. Ezt a szabályt megtarthatjuk, vagy akár törölhetjük, letilthatjuk (set status disable), attól függően, mire van épp szükségünk, ezért nem eggyel kezdődik a tűzfalszabályok számozása:
config firewall policy
    edit 2
        set srcintf "internal"
        set dstintf "TESZT-PH1"
        set srcaddr "
R2-belso-subnet"           
        set dstaddr "
R1-belso-subnet"           
        set action accept
        set schedule "always"
        set service "ANY"           
    next
    edit 3
        set srcintf "TESZT-PH1"
        set dstintf "internal"
        set srcaddr "
R1-belso-subnet"           
        set dstaddr "
R2-belso-subnet"           
        set action accept
        set schedule "always"
        set service "ANY"
end
A végére maradt a statikus route a távoli subnet felé:
config router static
    edit 1
        set device "TESZT-PH1"
        set dst 10.2.2.0 255.255.255.0
end

A FortiOS-ben külön nem szükséges menteni, amint kilépünk az end paranccsal valamilyen objektum konfigurációs módjából, a beállított értékeket a rendszer elmenti, illetve természetesen a futó konfigurációban érvényre juttatja.

A figyelmesebbeknek szemet szúrhat, hogy történt egy kis csalás ebben a Fortigate beállításban. A korábbiakban sehol sem használtam az IPSec-hez bármilyen módon köthető virtuális interfészt, VTI-t, loopback interfészt, a Cisco routeren és a Vyattán is egyszerű tunnel módban hoztam létre a kapcsolatot, nem hajtottuk át az adatokat semmilyen egyéb interfészen, csak azon, ahol kiléptek a routerből. A Fortigate esetén is elérhető ez a tunnel mód, policy-based VPN-nek hívják, config vpn ipsec phase1-interface helyett a config vpn ipsec phase1 paranccsal kell létrehozni. Phase2-ben szintén a megfelelő parancs interface nélküli változatát kell választanunk, majd egy tűzfalszabályt kell még hozzárendelnünk, ahol ACCEPT vagy DENY helyett az IPSEC műveletet kell a szabályban műveletként megadni (egy tunnelhez csak egy szabály tartozhat). Eddig egyébként még sosem sikerült értelmes módon beállítanom a policy-based VPN-t, például a távoli site-ról kezdeményezett forgalom során nem áll fel magától az IPSec kapcsolat, bármilyen tűzfal policy-vel is próbálkoztam, míg a Fortigate mögötti subnetből meginduló forgalom hatására mindig azonnal létrejött az IPSec összeköttetés.

A másik, a posztban részletesen is bemutatott módszerrel létrehozott, virtuális IPSec interfésszel operáló beállítást a Fortigate rendszerekben route-based VPN-nek nevezik. A virtuális interfész segítségével kezelhetőbbé válnak a IPSec-en keresztül kimenő vagy beérkező csomagok, átláthatóbbak a rájuk vonatkozó tűzfalszabályok, és mivel ekkor önálló interfészként jelenik meg az IPSec tunnel Fortigate-en lévő vége, bármennyi szabály vonatkozhat rá, kedvünk szerint finomhangolhatjuk.

2011-02-01

IPSec site-to-site VPN Cisco és Vyatta VPN routerek közt

A korábbi IPSec site-to-site VPN konfigurációban kicseréltem az R2 routert, és a Cisco eszköz helyett egy Vyatta VC6.1-es OS-szel ellátott x86-os gép került a helyére (lehetett volna akár virtuális gép is). A korábbi topológia változatlan:


A korábbi, IPSec beállításokat összegző táblázat szintén változatlan, nem is másolom be, megtalálható a hivatkozott posztban. Érdekesebb dolog viszont a Cisco IOS és a Vyatta parancsok összevetése, hogy pontosan melyik minek felel meg a másik OS-ben.

Az első lépés az interfészek felkonfigurálása, a Cisco routerben két FastEthernet port van, a Vyattát futtató rendszeren Fa0/0 helyett eth0 lesz az első ethernet interfész Fa0/1 helyett pedig eth1 a másik:

R1 - Cisco IOS
interface FastEthernet0/0
ip address 10.1.1.1 255.255.255.0
no shutdown
exit

interface FastEthernet0/1
ip address 10.2.2.1 255.255.255.0
no shutdown
exit

R2 - Vyatta

set interfaces ethernet eth0 address 10.1.1.2/24
set interfaces ethernet eth1 address 10.3.3.1/24

Mivel egyik oldalon sincs dinamikus routeolás, ezért be kell jegyeznünk a túloldalon lévő subnetet. Ez a lépés a Vyatta rendszeren egyébként elhagyható, ha ugyanis nincs a későbbi IPSec peer beállításoknak megfelelő bejegyzés a route táblában, akkor a tunnel felépülésekor ezt a rendszer automatikusan létrehozza. A teljesség kedvéért azonban itt szerepel az IOS-ben kiadott parancs vyattás megfelelője:

R1 - Cisco IOS
ip route 10.3.3.0 255.255.255.0 10.1.1.2

R2 - Vyatta
set protocols static route 10.2.2.0/24 next-hop 10.1.1.1

A következő lépés a 10-es prioritású IKE policy létrehozása IOS-en (természetesen más számot is válaszhatunk 10 helyett). Vyatta esetén ennek nagyjából az IKE group létrehozása felel meg, a példában ez a TESZT-IKE-GROUP nevet viseli:

R1 - Cisco IOS
crypto isakmp policy 10
encr aes 256
hash sha
authentication pre-share
group 5
lifetime 28800
exit

R2 - Vyatta
set vpn ipsec ike-group TESZT-IKE-GROUP
set vpn ipsec ike-group TESZT-IKE-GROUP lifetime 28800
set vpn ipsec ike-group TESZT-IKE-GROUP proposal 10
set vpn ipsec ike-group TESZT-IKE-GROUP proposal 10 dh-group 5
set vpn ipsec ike-group TESZT-IKE-GROUP proposal 10 encryption aes256
set vpn ipsec ike-group TESZT-IKE-GROUP proposal 10 hash sha1

A Cisco IOS-ben az isakmp beállítások közt kell megadnunk minden IPSec peerhez a PSK-t, ez a Vyattában csak később, a peer egyéb beállításaival együtt szerepel. Ugyanez érvényes a crypto ACL szabályra, IOS-ben egy extended ACL-t kell létrehoznunk, és azt majd alkalmazni a megfelelő interfészen, ami a Vyattán ugyancsak a peer beállítások közt szerepel:

R1 - Cisco IOS
crypto isakmp key TITOK address 10.1.1.2
access-list 100 permit ip 10.2.2.0 0.0.0.255 10.3.3.0 0.0.0.255

R2 - Vyatta
A peer beállításai közt kell megadni.

A következő sorok a Phase 2-re vonatkoznak, nem feleltethetők meg egymásnak a parancsok egy az egyben, IOS esetén transform set és security assiciation lifetime néven futnak a beállítások, Vyatta esetén pedig ESP group néven, de alapvetően mindkét OS-ben ugyanazt a beállítást végzik el. Vegyük észre azonban, hogy a Vyatta esetén a Perfect Forward Secrecy szintén itt kerül beállításra:

R1 - Cisco IOS
crypto ipsec transform-set TESZTSET esp-aes 128 esp-md5-hmac
crypto ipsec security-association lifetime seconds 3600

R2 - Vyatta
set vpn ipsec esp-group TESZT-ESP-GROUP
set vpn ipsec esp-group TESZT-ESP-GROUP proposal 10 encryption aes128
set vpn ipsec esp-group TESZT-ESP-GROUP proposal 10 hash md5
set vpn ipsec esp-group TESZT-ESP-GROUP pfs enable
set vpn ipsec esp-group TESZT-ESP-GROUP lifetime 3600

Következhet a crypto map az IOS-ben, ami nagyjából az ipsec site-to-site peer beállításoknak feleltethető meg Vyatta alatt. Ugye még emlékszünk arra, hogy a Vyattának két dolgot is pótolnia kell, a PSK és a crypto ACL megfelelőit itt fogjuk megadni, míg az IOS a PFS beállításokkal maradt eddig adós:

R1 - Cisco IOS
crypto map TESZTMAP 50 ipsec-isakmp
set peer 10.1.1.2
set pfs group5
set transform-set TESZTSET
match address 100
exit

R2 - Vyatta
set vpn ipsec site-to-site peer 10.1.1.1
set vpn ipsec site-to-site peer 10.1.1.1 authentication mode pre-shared-secret
set vpn ipsec site-to-site peer 10.1.1.1 authentication pre-shared-secret TITOK
set vpn ipsec site-to-site peer 10.1.1.1 ike-group TESZT-IKE-GROUP
set vpn ipsec site-to-site peer 10.1.1.1 local-ip 10.1.1.2
set vpn ipsec site-to-site peer 10.1.1.1 tunnel 0
set vpn ipsec site-to-site peer 10.1.1.1 tunnel 0 local-subnet 10.3.3.0/24
set vpn ipsec site-to-site peer 10.1.1.1 tunnel 0 remote-subnet 10.2.2.0/24
set vpn ipsec site-to-site peer 10.1.1.1 tunnel 0 esp-group TESZT-ESP-GROUP

Utolsó lépésként a mindkét eszköz külső interfészén engedélyeznünk kell az IPSec-et:

R1 - Cisco IOS
interface FastEthernet0/0
crypto map TESZTMAP
exit

R2 - Vyatta
set vpn ipsec ipsec-interfaces interface eth0

Jelentős különbség a két rendszer közt, hogy az IOS-ben a parancsok a kiadásuk után azonnal érvényre jutnak, míg a Vyattában addig, amíg ki nem lépünk konfigurációs módból, csak gyűjti a rendszer a változtatásokat, és át tudjuk nézni az összes változást mielőtt érvényesítenénk (commit) őket.

R1 - Cisco IOS
end
copy run start

R2 - Vyatta
commit
save
exit

IPSec hibakereséshez használhatók a következő parancsok:

R1 - Cisco IOS
show crypto isakmp sa
show crypto ipsec sa

R2 - Vyatta
show vpn ike sa
show vpn ipsec sa