Tag: NSX

NSX-T 3.0 już jest!

Trzy dni temu na świat wyszła nowa wersja NSX-t 3.0 w niej jest sporo nowości, tym wpisem rozpocznę je opisywać. Ale teraz ogólna zajawka co znajdziemy w nowej wersji. Już jest u mnie w labie i powoli poznaję nowe funkcje.

  1. NSX Federacja 

    Dzięki temu rozwiązaniu będziemy mogli zarządzań rozproszonym środowisku np. wile Data Center czy chmurą. Rozwiązanie to wprowadza kolejną instancję NSX Managera tzw Global Managera(GM). Rysunek poglądowy poniżej:
    NSX-T 3.0 Federation
    Rozwiązanie to prowadza łatwiejsze rozciąganie warstwy 2 oraz wprowadza routing dla tych sieci. Wracamy trochę do technologi uniwersalnych routerów takie jak było w V-ce ale jest duża różnica. Niebawem szczegóły.

  2. IDS/IPS

    VMware zaczyna wprowadzać więcej rozwiązań bezpieczeństwa na pierwszy ogień jest to IDS w wersji dystrybucyjnej. Na każdym hoście jest uruchamiany silnik IDS który wykrywa podatności. W 3.0 mamy IDS ale VMware mówi że już nie długo będzie to IPS wszystko małymi kroczkami.
    NSX-T 3.0 IDS

  3. Url Filtering

    Tutaj mamy wsparcie do ULR Fiteringu w dostępie do Internetu.  Niebawem więcej

  4. VRF Lilte

    Wraz z nową wersją tak jak tematy bezpieczeństwa pojawiają się tematy które do tej pory bardziej były znane i wymagane dla ISP VRF’y czy eVPN w tej chwili VMware zaczyna wprowadzać je do swoich rozwiązań. Niebawem sprawdzę czy faktycznie wszystko działa tak jak wygląda na prezentacjach.
    NSX-T VRF

  5. NVDS wraca do DVS

    Tutaj jest większa zależność od vSphere 7.0 który wprowadza nową wersję DVS 7.0 który natywnie integruje się z NSX’em już nie będziemy musieli dedykować portów do NVDS’a. Jest to pierwsza opcja którą sprawdziłem w labie i faktycznie działa. Przy wykorzystaniu DVS’a musimy mieć vCenter.
    NSX-T DVS 7.0

  6. Service chaining

    Możliwość budowania chainingu dla ruchu północ-południe z wykorzystaniem 3party PaloAlto, Fortinet
    NSX-T 3.0 Chaining

  7. Windows 2016

    W 3.0 jest zapowiedź, NSX zaczyna wspierać MS Windows 2016 dla Firewalla dystrybucyjnego zobaczmy jak to jest faktycznie.

  8. Więcej na Infografice
    NSX-T 3.0 Infografika
Linki

release notes 3.0 

Download

Dokumentacja 

Maximus NSX-t 3.0

NSX-t IPSec Route base

W dzisiejszym wpisie przedstawię konfigurację NSX-t IPSec Route base, jest to  opis krok po kroku jak skonfigurować IPseca po stronie NSX’a oraz Vyos który będzie uczestnikiem IPseca. 

Założenia

  1. Poniżej rysunek poglądowy jak wygląda topologia połączeń.
  2. Pomiędzy routerem T0 i chmurką już istnieje połączenie oraz jest zestawione sąsiedztwo BGP w celu dostępu do sieci “Internet” na powyższym rysunku chmurki
  3. Parametry połączenia:
IKE  
IKE wersja v2
Encryption Algorithm
Digest Algorithm
Diffie-Hellman
86400
IPSec  
Encryption Algorithm
Digest Algorithm
PFS Group yes
Diffie-Hellman
SA Lifetime (sec) 3600

Konfiguracja NSX-t

Konfiguracja połączenie IPSEC
  1. Logujemy się do NSX Managera
    nsx-t login page
  2. Przechodzimy do Networking następnie VPN
    NSX-t VPN
  3. Skonfigurujemy profile dla IKE,IPSec przechodząc do Profiles 
    nsx-t profiles
  4. wybieramy IKE-Profiles następnie IKE ADD Profile, w nowym oknie podajemy parametry konfiguracyjne które zostały zebrane powyżej w tabelce oraz podajemy nazwę dla profilu. Po zakończeniu wprowadzaniu zapisujemy profil.
    NSXt ike profile
  5. Kolejnym krokiem jest dodanie profilu dla IPSeca, Wybieramy IPSEC Profiles i następnie ADD IPSEC Profile w nowym oknie podajemy nazwę dla niego oraz parametry z tabelki powyżej.
    NSX-t ipsec profile
  6. Ostatnim profilem do utworzenie jest profil DPD, wybieramy DPD Profiles i ADD DPD Profile, w nowym oknie podajemy nazwę oraz zostawiamy 60 secund.
    NSX-t DPD profile
  7. Po skonfigurowaniu profilu dla IKE i IPSec oraz DPD przechodzimy do konfiguracji VPN Service robimy to przechodząc do VPN Services gdzie klikamy na ADD Service i wybieramy IPSEC. W nowym oknie podajemy nazwę oraz wybieramy na który gateway ma zostać uruchomiony serwis odpowiedzialny za IPSeca w naszym przypadku będzie to T0.
    NSX-T VPN Service
  8. W tym kroku przechodzimy do konfiguracji LOCAL EDNPOINTS  klikamy ADD LOCAL ENDPOINT w tym miejscu skonfigurujemy adres z którego oraz do którego będziemy nawiązywać sesję IPSec.
    NSXt vpn local endpoint
  9. Przyszedł na ostatni krok konfiguracji IPSec przechodzimy do IPSEC SESION wybieramy Route Based.
    nsx-t ipsec route based
  10. W nowym okniekonfigurujemy naszą sesję IPSec podajemy dane:
    Nazwa – dowolna nazwa dla sesji.
    VPN Service – wybieramy wcześniej zdefiniowany profil.
    Local Endpoint – podobnie wybieramy profil który wcześniej skonfigurowaliśmy.
    Remote IP – podajemy adres IP partnera z którym będziemy nawiązywać sesję IPSec.
    Authentication Mode – w naszym przypadku wybieramy PSK może kiedyś zrobię opis na certach :-).
    Pre-shared Key – podajemy nasz klucz PSK 
    Tunnel Interface – podajemy ip dla naszego interfejsu tunel w naszym przypadku jest to 100.100.10.1/30 musi być podana maska min 31.
    Remote ID – podajemy zakończenie tunelu po drugiej stronie, zgodnie z założeniami jest to 2.2.2.2
    Do kolejnych ustawień przechodzimy klikając  Advanced Properties gdzie dalej podajemy parametry naszego połączenia:
    IKE Profiles – wybieramy utworzony przez nas profil IKE.
    IPSec Profiles – wybieramy utworzony przez nas profil dla IPSec.
    DPD Profiles – wybieramy utworzony profil dla DPD.
    Connection Initiation – określmy rolę w naszym przypadku zostawiamy bez zmiany.
    Parametry nie wymienione zostawiamy bez zmian.
    NSX-t vpn ipsec sesion
  11. Po wyższych krokach mam skonfigurowane parametry dla IPSeca Rouet Base.
Konfiguracja Routingu w NSX

W tej sekcji dowiesz się jak skonfigurować redystrybucję adres Local Endpoint oraz jak zestawić BGP. 

Konfiguracja redystrybucji

Aby poprawnie zestawić połączenie IPSec przydało by się do naszej chmurki która jest pokazana na rysunku na początku wpisu rozgłosić adres Local Endpoint a robimy to tak:

  1. Przechodzimy do Networking następnie do Tier0 wybieramy nasz router T0 i przechodzimy do jego edycji.
    EDIT T0 router
  2. Przechodzimy do ROUTE RE-DISTRIBUTION klikamy na cyfrę w przy Route Re-Distribution.
    t0
  3. W nowym oknie zaznaczamy IPSec Local IP i klikamy Apply.
    IPSec local IP
  4. Na koniec zapisujemy oraz klikamy close editing i temat ten mamy za sobą. 
Konfiguracja BGP pomiędzy NSX a Vyos

W IPSec route base protokół routingu jest odpowiedzialny za ustalenie pomiędzy jakimi sieciami ma nastąpić szyfrowanie w kanale IPSec. W NSX-t mamy do dyspozycji dwa protokoły routingu jest to statk oraz BGP w tym punkcie skupię się właśnie nad poczciwym BGP’em. 

  1. Aby skonfigurować sesję BGP przechodzimy do Networking następnie do Tier0 wybieramy nasz router T0 i przechodzimy do jego edycji
    EDIT T0 router
  2. Tam przechodzimy do sesji BGP, gdzie jest to pierwsza sesja BGP konfigurujemy:
    Local AS – w labie oraz DC wybieramy coś z puli privet AS 
    resztę parametrów zostawiamy bez zmian w labie, w DC można podkręcić czasy sesji BGP 
    Tutaj już mamy to skonfigurowane bo mamy sesję do mojej chmurki 
    nsx-t bgp
  3. W kolejnym ważnym krokiem jest skonfigurowanie sąsiedztwa BGP aby to zrobić przechodzimy do BGP Neighbors. W tym przypadku dodajemy kolejne sąsiedztwo. 
    bgp sasiedzwto
  4. W nowym oknie dodajemy nowego sąsiada gdzie podajemy parametry do skonfigurowania
    IP Address – podajemy adres ip sąsiada w naszym przypadku jest to 100.100.10.2
    Remote AS – Podajemy numer AS sąsiada w naszym przypadku jest to 65555
    Source Addresses – podajemy nasz adres 100.100.10.1
    bgp add
  5. Klikamy Save i mamy skonfigurowane po stronie NSX’a BGP 

Aby wszystko zadziałało musimy skonfigurować naszego sąsiad czyli przechodzimy do konfiguracji Vyos,

Konfiguracja Vyos

Jak to było w piosence “do tanga trzeba dwojga” w tym przypadku partnerem dla NSX będzie Vyos na którym poniżej przedstawię jak skonfigurować IPSec route Based oraz BGP.  Nie będę pokazywał podstawowej konfiguracji tylko skupię się na omawianych zagadnieniach. Cała konfiguracja jest wykonywana z poziomy SSH. W tym labie wykorzystuję wersję trochę starą bo jest to 1.3 

Konfiguracja połączenie IPSEC w Vyos
  1. Logujemy się do naszego Vyos po ssh
  2. Przechodzimy do konfiguracji i konfigurujemy nasz profil dla fazy 1 zgodnie z założeniami

    czysta konfiguracja same komendy

  3. Następnie profil dla fazy 2 
  4. Profil dla DPD

    same komendy 

  5. Tworzymy interfejs tunelowy oraz nadajemy jemu adres ip zgodnie z założeniami
  6. Konfiguracja IPSeca
    same komendy które zostały użyte powyżej 
  7. Na koniec wykonujemy commit

     

Konfiguracja BGP w Vyos

Po skonfigurowaniu IPSeca przechodzimy do konfiguracji sesji BGP, poniżej bardzo szybki config.

same komendy:

 

Weryfikacja

Po czasie konfiguracji NSXa i jak Vyos przyszedł czas na weryfikację naszej pracy.

Sprawdzenie po stronie NSX 

IPSEC
  1. logujemy się po SSH do Edga na którym jest nasze T0
  2. sprawdzamy sesję ike wykonując komendę get ipsecvpn ikesa active 

     

  3. Weryfikujemy całego IPSeca wykonując komendę get ipsecvpn session

     

  4. Weryfikujemy jak wyglądają statystyki czy zmieniają się wykonując komendę get ipsecvpn tunnel stats 
BGP

Podobnie jak wyżej wykorzystujemy połączenie ssh do EDGE

  1. sprawdzamy jaki id VRF ma nasz router T0 moduł serwisowy wykonując komendę 
  2. przechodzimy do vrfu 2 
  3. Sprawdzamy siąsietzdwa BGP wykonując komendę get bgp neighbor summary
  4. sprawdzamy tablicę routingu wykonując polecenie get route bgp
Weryfikacja Vyos

Wszystkie sprawdzenie po stronie również wykonujemy z poziomu CLI poprzez SSH

Sprawdzenie IPSEC
  1. sprawdzamy sesję IKE
  2. Sprawdzamy sesję IPSec
Weryfikacja BGP
  1. weryfikacja statusu BGP
  2. Sprawdzenie tablicy routingu 

     

Na koniec test puszczenie ping z Vyosa to NSX’a dokładnie na ip 10.11.1.1 który potwierdzi nam działanie transmisji w IPSecu

 

Jak widać proces weryfikacji wyszedł pozytywnie i możemy cieszyć się skonfigurowanym IPSeciem typu route base. Jak Macie pytania to zapraszam do kontaktu. 

NSX 6.4 – trochę nowości

Wczoraj to jest 16.01.2017 w godzinach wieczornych Polskiego czasu została udostępniona nowa wersja NSX 6.4. Dziś od rana skupiłem się na podniesieniu wersji w labie, poniżej przedstawię trochę nowości wraz ze zmienionym podejściem do wykonywania Upgrade.

Nowości

Jakie nowości które widzę po pierwszym zalogowaniu do nowej wersji.

  1. nowy interfejs pluginu w vCenter, przebudowane menu oraz Dashboard
  2. rozpoczęcie wsparcia dla interfejsu HTML5 ale jeszcze dużo funkcji nie ma
  3. Firewall warstwy 7, ale nie możemy tego porównać z dostawcami jak Palo czy Forti, jedynie sprawdza poprawność protokołu
  4. Jak dla mnie najfajniejsza nowa funkcja, graficzny interfejs dla packet capture, który opisałem we wcześniejszym wpisie jak używać go z CLI

  5. Więcej znajdziemy w dokumentacji oraz Release Notes
Upgrade

Sam proces wykonywania upgrade został bardziej zautomatyzowany, nie musimy już ręcznie wykonywać aktualizacji ręcznie każdego z modułów. Jedno z ważnych punktów jest posiadanie włączonej funkcji DRS, jak nie będziemy jej mieli włączonej to będziemy musieli ręcznie wprowadzać hosty w maintenance mode oraz wykonanie restartu hostów ESX, ze względu na odinstalowanie modułów VXLAN.

Przechodzimy do pracy.

  1. ściągamy plik z vmware.com do wykonania upgrade do wersji 6.4
  2. Logujemy się do konsoli NSX Managera gdzie, wykonamy upload ściągnięty plik.
  3. Po ponownym uruchomieniu NSX Managera logujemy się do naszego vCenter przechodzimy do Networking & Security –> Installation –> zakładka Upgrade, jest to jedna z nowości, klikamy na PLAN UPGRADE,
  4. Uruchomi się kreator, w którym zdefiniujemy jak ma wyglądać upgrade naszego środowiska, lub możemy wybrać plan automatyczny, Ja wybrałem automatyczny “One Click Upgrade” klikamy Next.
  5. w nowym oknie dostaniemy podsumowanie co zostanie zaktualizowane
  6. Po naciśnięciu START UPGRADE rozpocznie się proces aktualizacji
  7. W każdej chwili możemy sprawdzić status aktualizacji klikając na View details
  8. Po zakończeniu procesu dostaniemy w pełni zaktualizowane środowisko.

NSX Manager packet capture

Dziś pokaże jak wykonać packet capture z poziomu NSX Managera. Dzięki temu rozwiązaniu nie musimy logować się na hosta tylko wykonujemy operację z jednego miejsca. Jedyne co potrzebujemy to dostęp SSH do NSX Managera, oraz znać hasło do trybu enable.

Topologia na której będziemy pracować:

dla przykładu będziemy zbierać ruch z maszyny Win7-02.

Musimy zalogować się po SSH do Managera gdzie pozyskamy informacje o Vnic Id.

wyświetlamy klastry które widzimy z poziomu NSX a następnie hosty które należą do danego klastra.

wyświetlamy wirtualne maszyny które są uruchomione na danych hoście – szukamy id wirtualnej maszyny

wyświetlamy informacje o wirtualnej maszynie – potrzebujemy informacji Vnic Id

przechodzimy do trybu enable – podajemy hasło które zdefiniowaliśmy podczas instalacji NSX Mangera

następnie wykonujemy polecenie do załapania ruchu w danym kierunku my będziemy łapać ruch wychodzący ruch z danej maszyny.

Jak widzimy poniżej musimy podać w poleceniu host na którym uruchomiona wirtualna maszyna, Vnic ID oraz kierunek ruchu w naszym przypadku jest to input (ruch wychodzący).

aby wyświetlić co złapaliśmy możemy wyświetlić dopiero po zatrzymaniu procesu danej sesji. Aby to wykonać musimy znać ID Session, w danej chwili może być uruchomiono klika sesji.

następnie możemy wyświetlić

dodając parametr na końcu polecenia -e dostajemy więcej informacji

a na koniec możemy przenieść plik w inne miejsce i otworzyć np. w wiresharku

i otwieramy plik zgrany z naszego NSX Managera.

Na koniec zapraszam do obejrzenia nagrania z webinar na którym pokazuję jakie narzędzia mamy aby sprawnie wykonać Troubleshooting na platformie NSX. Link do nagrania znajdziesz na tej stronie

Vmware NSX Service Composer

We wcześniejszym wpisie zrobiłem wprowadzenie do mikrosegmentacji. Dziś natomiast skupię się na service composer (temat ten będzie rozwinięciem poprzedniego wpisu).
Zapraszam.

Co to jest Service Composer?

Service Composer jest to narzędzie, które dostajemy w NSX’ie, pozwalające na automatyczne przypisywanie zdefiniowanych przez nas polityk fw do grup maszyn. Grupy te tworzymy na podstawie jakiegoś wzorca. Można powiedzieć, że jest to automat pozwalający nam uprościć pracę przy politykach firewall w NSX’ie.

Trochę praktyki

Pracę nad service composer możemy podzielić na następujące etapy:

  • utworzenie security tag
  • Security Groups
  • Security Polices
  • przypisanie security polices do security groups
  • przypisanie security tag do wirtualnej maszyny
  • weryfikacja

Schemat poglądowy architektury, na jakiej będziemy pracować:

Security tag

Jednym z głównych kroków jest utworzenie security tagów, które będziemy przypisywać do wirtualnej maszyny. Na tej podstawie będzie definiowana polityka FW.

Po zalogowaniu się do naszego vcenter przechodzimy do Networking & Secuirty, a następnie do NSX Managers –> nasz NSX Manager –> Manage –> Security Tags

gdzie klikamy na zaznaczoną ikonę w celu dodania security tag.  Definiujemy go w nowym oknie:

Powyższy krok powtarzamy dla każdego nowego security tagu.

Security Groups

Kolejnym krokiem będzie zdefiniowanie Security groups – w tym miejscu będziemy tworzyć automat, który na podstawie wskazanych elementów będzie tworzył grupę.

Przechodzimy do Networking & Secuirty –> Service Composer –> Secuirity Groups, klikamy na zaznaczoną poniżej ikonę.

W nowym oknie otworzy nam się kreator – tworzenie security group; w pierwszym kroku nadajemy nazwę grupy:

W kolejnym kroku wybieramy opcję, która ma za zadanie dynamicznie przypisać do grupy. Mamy do wyboru:

  • Computer OS Name
  • Computer Name
  • VM Name
  • Security TAG
  • Entity

Nasza polityka będzie wyglądała jak poniżej:

W kolejnym kroku możemy ręcznie przypisać jakieś elementy vCenter

Następnie możemy wykluczyć przynależność do grupy jakiegoś elementu

W ostatnim oknie kreatora dostajemy podsumowanie

Security Polices

W tym kroku zdefiniujemy zestawy polityk firewall, które będziemy przypisywać do Security groups

przechodzimy tak jak wcześniej, ale tym razem do zakładki Security Policies.

klikamy na zaznaczoną poniżej ikonę i przechodzimy do kreatora

w pierwszym kroku nazywamy naszą Security Policy

w kroku 2 pomijamy, ponieważ nie mamy integracji np. z antywirusem.

krok trzeci będzie nas najbardziej interesował, bo tu będziemy tworzyć nasze polityki firewall. Klikamy zielony plusik i dodajemy reguły.

W naszym przypadku będą to 2 reguły:

  1. pozwalająca na dostęp po SSH z wykluczeniem maszyn należących do security groupy –
  2. blokująca ruch w Security Groupie

Po utworzeniu reguł przechodzimy dalej; w tym miejscu możemy utworzyć reguły dla ruchu, który chcemy poddać do dalszej inspekcji w innych rozwiązaniach np. jak mamy integrację z PaloAlto. My natomiast krok ten pomijamy, gdyż nie posiadamy integracji.

W kolejnym kroku mamy podsumowanie i na tym kończymy pracę z kreatorem.

Przypisanie security polices do securit groups

W tym miejscu przypniemy utworzoną politykę do grupy przez zaznaczenie naszej security polices, a następnie przez kliknięcie na zaznaczoną ikonę

w nowym oknie wybieramy naszą Secuirty groups i klikamy ok

w tej chwili mamy utworzone polityki przypięte do grupy, która jest dynamiczna. Każda maszyna z przypisanym secuirty tagiem “Web_SRV_app01” dostanie zdefiniowany zestaw reguł firewall.

Przypisanie secuity tag do wirtualnej maszyny

W tym kroku przypiszemy secuirty tag do dwóch wirtualnych maszyn. Poniżej prezentuję najszybszy sposób przypisania tagów do wirtualnych maszyn. Istnieje też drugi sposób, ale bardzo wolny polegający na wejściu do każdej wirtualnej maszyny i przypisaniu tam security tag.

Przechodzimy do Networking & Secuirty, następnie NSX Managers –> nasz NSX Manager –> Manage –> Security Tags

Wybieramy nasz tag i klikamy na zaznaczoną ikonę

w nowym oknie wyszukujemy nasze wirtualne maszyny

po kliknięciu ok rozpocznie się proces przypisywania polityk do tych wirtualnych maszyn.

Weryfikacja

z pomocą przychodzi nam zakładka Canvans w Service Composer, gdzie widzimy ilość wirtualnych maszyn przypisanych do security groups.

W oknie reguł Firewall doszła nam nowa grupa reguł, które zdefiniowaliśmy w Security Polices

Testujemy SSH

 

PING

 

Syslog

wyszukujemy wszystkie hinty, które należą do reguły 1007 i 1008 używając filtru jak poniżej:

Jaki widać powyżej reguły działają zgodnie z założeniem.