Dva hlavní problémy: IPSEC VPN se neobnovují a dálkové restartování způsobují restart jádra

Pozadí: Nedávno jsme aktualizovali náš zastaralý hlavní směrovač NSA 4600 a pobočkové směrovače TZ300 na NSa 4700 a 26 směrovačů TZ370 pro pobočky. Každá pobočka a sídlo mají různé internetové připojení - AT&T DIA Fiber nebo Broadband fiber, Spectrum DIA Fiber atd. Každý pobočkový směrovač má VPN IPsec z pobočky do sídla (kde je naše datové centrum), čtyři pobočky (každá pro “okres”) mají sekundární VPN IPsec k jejich okresním pobočkám a mezi sebou, takže vše může komunikovat, pokud hlavní sídlo selže. To fungovalo docela dobře v době v6. Bohužel máme dva hlavní (a jeden méně hlavní) problémy s novější firmware.

Firmware: Když byli první dodáni, měli verzi 7.0.1-5111. Skoro okamžitě jsme je aktualizovali na 7.1.1-7047, která byla vydána v době nasazení. Po zjištění níže uvedených chyb jsem se pokusil aktualizovat na 7.1.1-7058, bez změny. Nyní jsou všechny na verzi 7.1.2-7019 a stále máme tyto problémy. Jakékoliv tipy, rady, stopy atd. by byly vítány. Momentálně používáme RIPv2 napříč celým systémem, ale plánujeme přejít na OSPF, jakmile se to naučím.

Problém 1: Někdy, po přerušení spojení pomocí bagru nebo jiného výpadku, VPN IPsec se znovu neobnoví, pokud ji nevypnu a nezapnu, většinou na straně 4700. Poté hned zase funguje. Není to pokaždé, ale když ano, nezdá se, že by se to samo opravilo časem - musí to být manuální zásah.

Problém 2: Mnohem vážnější. Při restartu jednoho z pobočkových směrovačů (například po upgrade firmware) se někdy - a to byl mnohem vážnější problém při prvním nasazení, protože to bylo během pracovní doby - 4700 spontánně restartuje sám, odpojuje všechny a hází náš HQ do chaosu (nena mluvě o odpojení spojení všech ostatních poboček s HQ). Nyní, když jsou všechny nové směrovače nasazeny, není to tak velký problém, protože aktualizace firmware mohu dělat během údržbových oken a restart hlavního směrovače není tak zásadní, ale stále to prodlužuje celý proces.

Problém 3: Tento nás momentálně neovlivňuje, protože si myslím, že jsem část problému odhalil a deaktivoval ho. Koupili jsme předplatné NSM Essential pro všechny tyto zařízení. Plánoval jsem ho používat pro aktualizace firmware, bílé seznamy, konfiguraci uživatelů, filtrování obsahu, věci, které jsou většinou stejné napříč všemi lokalitami. Ale všiml jsem si, že se velmi vzácně ztratí spojení - a když jsem se dostal do pobočky, abych zjistil, co je špatně, sakra, TZ370 se resetovalo na tovární nastavení. Naštěstí mohu stáhnout zálohy konfigurace z mysonicwall. Deaktivoval jsem cloudové řízení na všem a zatím se to neopakovalo. Přemýšlím, jestli cloudové řízení náhodou neposílalo prázdné konfigurace těmto směrovačům. Má někdo další dobrou zkušenost s řízením NSM?

Někdo mi, prosím, řekněte, že nejsem sám. Viděl jsem spoustu příspěvků komentujících problémy s verzí 7, jen se ptám, jestli jsou tyto známy.

Všechny tyto problémy by měly být nahlášeny podpoře SNWL.

Jen čtení těchto mi ukazuje, že potřebuji mnohem víc informací, trasovací logy (aktuální + všechny) a událostní logy z bodů, kdy tyto události nastanou.

Nemám ponětí, jestli jste sám nebo jestli to mají i ostatní.

Musíte začít u 1. kroku a dále, řešte tyto problémy s SNWL. Čekat cokoli jiného odtud nebo z jiných veřejných fór je jako mlátit hlavou o zeď.

Pro konfiguraci hub a věží by měly být povoleny udržovací signály na straně jádra, kde má NSA je vypnutá. Dále je třeba potvrdit vaše síťové objekty na obou stranách tunelu. Buďte konkrétní, protože je to hloupé. Geo filtrování by mělo být povoleno, pokud je nějaká správa dostupná zvenčí, známý problém.

Pro výrobní jednotky je verze 7.1.2 hlavní a nikoli vedlejší větve firmware.

Mám pouze jednu v nasazení s tímto firmware, byla to kompletní sestava, takže jsem nekonfiguroval žádný soubor. Což může být i vaše problém, starý firmware ghost bug.

Prohlédněte si logy, abyste našli selhání. Hodně štěstí.

NSA jsou firewall. Ne směrovače. Nepoužívejte je jako jádro. Pořiďte si Cisco 9000 nebo dokonce 3850 a tyto zařízení použijte na RIP a OSPF. Také doufám, že máte hlavní a záložní jednotku NSA v režimu HA.

Také nejlepší způsob pro generaci 7 je nainstalovat 7.1.2, provést tovární reset a nakonfigurovat ručně (ano, vážně). Podívejte se na mou historii a uvidíte problémy, které jsem měl s přesně TZ370, když jsem importoval konfiguraci z generace 6 a zkoušel stejnou cestu upgradu, kterou máte vy. Ukázalo se, že SonicWall má známý problém s importem konfigurací.

Ne, přestaňte, vezměte všechny logy a trasování, které můžete, včetně TSR formuláře, a tyto problémy nahlaste podpoře SNWL.

Zajímalo by mě, proč byste chtěli mít udržovací signál vypnutý na straně HQ tunelů. Je to osvědčená metoda nebo něco?

TOHLE! To, co říká tento člověk, by mělo být vaším evangelium v této situaci.

Provozoval jsem NSAs v prostředí s téměř 100% dostupností po dobu téměř 15 let a TZ všude jinde. Obvykle jsou bezchybné. Ano, mohou fungovat jako směrovače. To je staré myšlení. Respektuji váš názor, ale nesouhlasím.

Ano, tunel s nejmenším zatížením (satelitní) by měl mít udržovací signál povolen.

Je ten počet sedmi devítek, no, obrazně?

+1, ale rozměry jsou nesmírně důležité.

Ano, mohou. Ale neměli by. Nechci vás unavovat detaily o tom, jak je routing na hardwaru lepší než routing na softwaru (což SonicWall dělá). u/nccon1, ty a všichni vaši SonicWall zastánci, si s tím můžete hádat, kolik chcete, používám SonicWall přes 20 let, živím se jako síťový inženýr a mohu vás ujistit, že jste na omylu. Také označuji za nesmysl vaše tvrzení o 99,99999% dostupnosti NSA. To je zcela nepravdivé.

Je to jen troll zde. Nedávno šířil nesmysly i v jiném příspěvku o nastavení Failover/LB, takže pochybuji, že vůbec ví, co je to firewall nebo router.

Určitě jsem… prosím, žádné žaloby :melting_face:

Vím, co mohou a nemohou dělat. Mohou to dělat a většinou to dělají dobře. Jistě, jsou prostředí, kde je lepší použít účelově stavěný router. SonicWall je však velmi stabilní a zvládne práci, podle mých zkušeností (které sahají více let, než bych si přál počítat).