www.SAMURAJ-cz.com 

03.08.2021 Miluše Translate to English by Google     VÍTEJTE V MÉM SVĚTĚ

Články

FortiGate 6.2.3 bugy, debug a podpora

Upraveno 02.05.2021 14:50 | vytvořeno 04.09.2020 14:37 | Samuraj - Petr Bouška |
Článek postupně doplňuji a také různé věci testuji na novější verzích. Takže se netýká pouze FortiOS 6.2.3, ale obecně 6.2.x a 6.4.x. Před pár měsíci jsme nasadili FortiGate Firewally do provozu a od té doby stále řeším řadu problémů. Myslím, že řada z nich není způsobena mojí neznalostí či chybou konfigurace, ale chybou vlastního FortiOS. S jednou věcí jsem se dokonce obrátil na Fortinet Support a podělím se zde o moje špatné zkušenosti. Rozhodl jsem se sepsat problémy, na které si vzpomenu, a u toho největšího popsat kroky, které jsem prováděl pro zjištění příčiny problému.

Nyní jsem již vážně z Fortinetu rozčílený. Fortinetu rozhodně na zákaznících nezáleží. Jako velmi špatné mi přejde, že česká pobočka nic neřeší. Mám zkušenosti třeba s Ciscem, kde jsou velice ochotní technici a eskalují problémy i do zahraničí. O inteligenci podpory (i když se má jednat o senior inženýra) nemám ani tak pochybnosti, jako jasný názor, je extrémně nízká (pokud to není nařízení, že se tak má chovat, aby odradil zákazníky). Údajně již problém delší dobu řeší Research and development tým, kde musí být také velice omezení. Pak je jasné, proč má FortiGate více bugů než funkčnosti. Poslal jsem jim jasné vysvětlení a důkazy problému, ale nejsou to schopni pochopit. Co naprosto nechápu, proč si situaci nevyzkouší ve svém prostředí!!! To snad dělá každá firma při řešení problému.
Celkově neustále řeším nějaké problémy. Nejčastěji to, že máme různé aplikace, které se pravidelně připojují k nějakým webovým službám v internetu (například do Azure) a to občas začne zlobit a spojení se nedaří. V logu je, jako by server poslal Server Reset (takže se navazují nové a nové sesison), ale odjinud jsou spojení bez chyb. Na dané adresy mám výjimky ze SSL inspekce, apod. Většinou pomůže, když pro danou cílovou adresu změním politiku z Proxy Mode na Flow nebo naopak (nejhorší je, že některé služby chodí v jednom módu a jiné v tom druhém).

Pozn.: 8. 9. 2020 jsem doplnil, jak jsem před časem řešil IPsec VPN.

Pozn.: 11. 9. 2020 jsem doplnil situaci okolo řešeného problému.

Pozn.: 7. 10. 2020 jsem doplnil informaci ohledně opravy bugu ve FortiOS 6.2.6. A zmínil nový problém s přístupem na HTTPS ve FortiOS 6.2.5.

Pozn.: 2. 12. 2020 jsem doplnil informaci o upgradu na FortiOS 6.2.6, který problém nevyřešil, ale zhoršil (již to nefunguje ani s Certificate Inspection).

Pozn.: 1. 2. 2021 jsem doplnil informaci o upgradu na FortiOS 6.2.7, který problém nevyřešil.

Pozn.: 12. 2. 2021 jsem doplnil jak katastroficky pokračuje řešení s Fortinetem a úvodní názor.

Pozn.: 11. 3. 2021 jsem doplnil další problém. Nefunkční HTTPS komunikace z Dynamics 365 na Exchange Web Services v Proxy Mode s certifikátem.

Pozn.: 15. 4. 2021 řeším jsem další problém se Site to Site IPsec VPN, popsal jsem vše do nového článku. Mám otevřený ticket na Support. Jako problém se ukázalo využití VDOM Partitioning (Virtual clustering).

Pozn.: 2. 5. 2021 jsem doplnil informaci o upgradu na FortiOS 6.2.8, který problém konečně vyřešil.

Virtual clustering s VDOM partitioning

Relativně kosmetický problém, ale člověk na něj nesmí zapomenout. Pokud provozujeme FGCP cluster a máme rozdělené VDOM na různé nódy, tak se řada informací nepřenáší na druhý nód a musíme se připojit na ten, kde je daná VDOM Master. To je třeba u SD-WAN (statistiky a monitoring), Site to Site IPsec VPN (často se na druhém nódu ukazuje jako Inactive, to je dost nepříjemné), výpis routovací tabulky, debug pomocí CLI (a vůbec mnoho CLI zobrazovacích příkazů).

FortiGate špatné zobrazení Site to Site IPsec VPN

SSL VPN a špatná LDAP skupina

Po upgradu na FortiOS 6.2.4 se často (ale ne vždy) uživatelé v SSL VPN špatně zařazují do LDAP skupiny (z LDAPu FortiGate načte správnou, ale VPNce předá jinou), takže se sice připojí do VPN, ale tam nemohou komunikovat. Takže jsem hned prováděl downgrade. Jde o známý bug, prý opraven ve FortiOS 6.2.5. Technical Tip: Incorrect portal mapping because of SSL VPN LDAP user matching incorrect group

Nepřipojení do SSL VPN - FortiClient končí na 98%

Podle diskuzí velmi známý problém, který trvá asi od počátku Fortinet SSL VPN. Připojení k SSL VPN z FortiClienta (6.0.x, 6.2.x, 6.4.x) se zasekne na 98 % (buď po delší době skončí nebo zůstane viset) a uživatel se nepřipojí. Někdy se povede na x-tý pokus nebo po restartu aplikace (zajímavé je, že je lepší ukončit a nastartovat aplikaci, ne restartovat počítač). Někdo se nepřipojí vůbec. Asi třetina lidí u nás má s tímto vážný problém. Vypadá to, že kdokoliv má připojení k internetu přes IPv6, tak se nepřipojí (pokud se na stanici IPv6 zakáže, tak to jde). I funkční připojení trvá velice dlouho oproti Cisco AnyConnect. Obecně chybová hlášení Forticlienta nic neříkají (stejně jako debug).

SSL VPN FortiClient končí na 98%

Po dlouhé době se ukázalo, že problém způsobuje snaha připojit se pomocí DTLS. Více informací v FortiGate problémy s připojením do SSL VPN přes FortiClient.

Timeouty session - Poll Active Directory Server

Naprosto zásadní problém, který se objevil odhadem u poloviny lidí (možná i více, ale oni si toho nevšimli). Po přepnutí FortiGate do provozu se začalo mnoha lidem stávat, při komunikaci mezi různými sítěmi, že jim po různé době (někdy pár vteřin, někdy až po desítkách minut) spadne (libovolná) session. Například u RDP se automaticky znovu spojení naváže (problikne černá obrazovka, případně info o navazování spojení), ale SSH se ukončí. Stejně tak připojení na Exchange se při každém pádu spojení znovu obnoví a uživatel si nemusí problému všimnout (ale vše je pomalejší a někdy se nezobrazí správně informace). Práce pomocí SSH či připojení do DB je nepoužitelné, protože se neustále ukončuje a musí se navazovat znovu.

Traffic logu FortiGate se u těchto session uvádělo Firewall Action: timeout. Zkoušel jsem upravovat politiky (vypínat kontroly, HW akceleraci apod.), zvedat timeouty, hledat problém v routingu a NATu. Pak debutovat vše možné, výpis session s filtrem, Packet Sniffer i Debug Flow (často se objevovala zpráva no session matched a od cílového serveru RST ACK). Jinak nikde nebylo nic zásadního vidět.

Až jsem dostal radu vypnout autentizaci na pravidle, obrátil jsem se pro radu na jednoho Fortinet specialistu, který viděl ve výpisu session údaj auth_server=Local FSSO Agent. Já nikde autentizaci nepoužívám, ale měl jsem vytvořený Fabric Connector pro Active Directory bez agenta. Což jsem chápal, že je metoda pro identifikaci uživatelů v lozích. Identifikace fungovala opravdu hezky, ale také způsobovala přerušení mnoha session. Ve chvíli, kdy jsem konektory vypnul (disable), tak vše začalo fungovat. Myslím, že i kdyby byl v získávání údajů o uživatelích jakýkoliv problém, tak by to nemělo způsobit rozbití komunikace.

Mám v plánu zkusit Fortinet Single Sign-On (FSSO) s pomocí agentů (agent-based), zda nebyl problém v tom vzdáleném dotazování do DC logů.

DNS error a IP connection error

Při pohledu do Traffic logu se velice často objevuje chyba v DNS komunikaci. U záznamu je Action: DNS error a Firewall Action: dns. Občas je Action: IP connection error a Firewall Action: ip-conn. Vždy je hned následováno dalším záznamem, kdy DNS komunikace korektně projde. Děje se pro UDP protokol (občasné DNS dotazy přes TCP prochází vždy).

V diskusích se tato situace řeší dost, ale asi není řešení a často se uvádí, že se není třeba touto chybou zatěžovat. Zmiňované je smazat system session-helper 14 pro dns-udp. To u mne nemělo vliv.

IPsec Site to Site VPN - autentizace certifikátem a SHA-2

Pozn.: IPsec VPN jsem se věnoval znovu, pokusil se nastudovat a sepsal článek FortiGate IPsec VPN, debug a problémy, kde také hodně popisuji debug. Je zde také uveden problém, kdy neprobíhá Phase 2 (IPsec) Rekey (řeším s podporou Fortinet). Vyřešilo se vypnutím VDOM Partitioning (Virtual clustering).

Potřebovali jsme vybudovat VPN tunel s jedním zákazníkem, který měl striktní požadavky na zabezpečení. Specifikoval všechny parametry, které byly

  • Phase 1 - Exchange mode IKEv2, autentizace certifikátem, Encryption AES-256-GCM, Integrity HMAC-SHA2, Pseudo Random Function (PRF) SHA512, DH Group 21, SA Lifetime
  • Phase 2 - Protocol ESP, Encryption AES-256-GCM, Integrity HMAC-SHA2, DH Group 21, Lifetime
  • dva subnety na vzdálené straně, jeden u nás

Nevyznám se detailně v této oblasti, takže jsem chvilku řešil i terminologii. FortiGate používá Encryption a Authentication, které dohromady tvoří Proposal. Pro AES-GCM-256 uvádí, že Encryption algorithm obsahuje autentizaci. Ale pro fázi 1 je povinné použít PRF. Takže pro fázi 1 se nastavilo aes256gcm-prfsha512 a pro fázi 2 aes256gcm.

Vše šlo na FortiGate nastavit jednoduše v GUI. Ale tunel se nenavázal. Můžeme se podívat do Log & Report > Events - VPN Events, ale zde jsou pouze hrubé události. Takže musíme použít CLI. Důležitá věc je, pokud používáme VDOM a cluster, připojit se vždy na Master Node (i když následně tunel fungoval, tak jsem jej skoro vždy viděl dole, ale jiný tunel se zobrazoval korektně). Výpis informací o IPsec VPN. Technical Tip: Troubleshooting IPsec VPNs

get vpn ipsec tunnel summary
diagnose vpn ike gateway list name JMENO

A hlavně zapnutí debug IPsec VPN pro cílovou IP.

diagnose debug application ike -1
diagnose vpn ike log-filter dst-addr4 X.X.X.X
diagnose debug console timestamp enable

diagnose debug enable

Část debugu s chybou

2020-07-01 08:29:07.977165 ike 1:JMENO:2924: certificate validation pending
2020-07-01 08:29:07.977755 ike 1:JMENO:2924: certificate validation complete
2020-07-01 08:29:07.977763 ike 1:JMENO:2924: certificate validation succeeded
2020-07-01 08:29:07.977899 ike 1:JMENO:2924: signature verification failed

K této chybě jsem našel jen nějaké staré diskuse, že s certifikátem je třeba použít SHA-1. Udělal jsem nějaké pokusy a funkční bylo

  • změnit autentizaci z certifikátu na Pre-shared Key (PSK)
  • ve fázi 1 použít libovolné šifrování, ale autentizaci nebo PRF SHA1

Nakonec přišel technik druhé strany s tím, že Cisco Firepower má nějaký speciální příkaz, který povolí pro fázi 1 SHA-512, ale pro hashování odpovědi s certifikátem použít SHA-1. Tunel se pak navázal s požadovaným nastavením.

Ještě jsem řešil jednu věc, která je spíše moje neznalost a rychle jsem dostal radu od FortiGate specialisty. Na druhé straně jsou dva subnety, hledal jsem, jak je zadat do fáze 2. Někde v dokumentaci jsem našel, že je třeba vytvořit Address Group, kam se zařadí jednotlivé subnety. V konfiguraci VPN se vybere Named Address a daná skupina. V monitoringu jsem pak viděl oba Phase 2 Selectors, ale navázal se vždy pouze jeden.

Řešení bylo konfigurace pomocí CLI a vytvořit pod stejnou Phase 1 samostatně dvě Phase 2. Naznačeno v Technical Tip: IPSec VPN between a FortiGate and a Cisco ASA with multiple subnets

Nefunkční HTTPS spojení na určité website ve FortiOS 6.2.5

Provedl jsem upgrade z FortiOS 6.2.3 na FortiOS 6.2.5 a hned jsem narazil na nové problémy. Přestal fungovat přístup na některé weby, které dříve fungovaly. Firefox zobrazí chybu

Secure Connection Failed 
Error code: PR_END_OF_FILE_ERROR

Je to při použití politiky v Proxy-based Inspection Mode, kde je pouze SSL Certificate Inspection spolu s libovolným Security Profile (AV, Web Filter, Application Control, IPS). Když se politika přepne do Flow-based Inspection Mode, tak přístup funguje (ale problém je zase s některými jinými adresami).

Je podobné jako známá chyba Proxy web filter with SSL inspection may fail for websites that allow TLS versions below 1.3 after upgrading to FortiOS 6.2.5, ale není to vázané jen na Web Filtering a nevím, co přesně myslí tou SSL inspection.

Nefunkční HTTPS komunikace z Dynamics 365 na Exchange Web Services v Proxy Mode

Velmi dlouho jsem řešil podivný problém, kdy se nedařila komunikace z cloudové služby Microsoft Dynamics 365 (CRM) na interní Exchange 2016 Server. Přesněji jeho službu Exchange Web Services (EWS), která se využívá pro přístup do schránek uživatelů, za pomoci servisního účtu s Application Impersonation rolí. Přístup vracel chybu

Error : System.Net.WebException: The remote server returned an error: (401) Unauthorized.

Stejný problém se ovšem vracel i při přímé autentizaci uživatele (bez Impersonation - zosobnění). Ale pokud se z Dynamics 365 spustil pouze Test připojení, tak proběhl v pořádku (včetně EWS přístupu do schránky). Neprocházel Test a povolení poštovní schránky.

Další věc je, že všechny testy (včetně Impersonation) z Microsoft Remote Connectivity Analyzer procházely bez chyby. Navíc EWS využívají i další služby a také nemají problém. Dlouho jsme tedy řešili, že bude problém v Dynamics 365. Později jsme zkusili napojení na testovací Exchange a to prošlo bez chyb.

Zkoumal jsem nastavení Application Impersonation, které se v diskusích často řeší. Analyzoval jsem logy na FortiGate a testoval vypnutí různých kontrol. Detailně jsem se věnoval Exchange logům EWS i IIS. Skrze FortiGate procházelo při testu mnoho spojení. Řada záznamů byla vidět i v IIS logu, vždy s kódem 401 Unauthorized. V logu EWS byl ovšem vždy pouze jeden záznam. U něj byla chyba

ErrorImpersonateUserDenied - The account does not have permission to impersonate the requested user

U testů, které fungovaly, byl podobný záznam, stejný autentizovaný uživatel (ale jiným formátem zapsaný) i Impersonated uživatel. Samozřejmě bez chyby. Třeba i v IIS logu se dá dobře hledat podle UserAgent = CRM/9.0.0.0/Live.

FortiGate - Proxy Mode a SSL Inspection

Nakonec jsem zjistil, že problém je v určitém nastavení FortiGate. Otestoval jsem, že se takto chová FortiOS 6.2.7 i FortiOS 6.4.5. Pokud je politika v Proxy Mode a zároveň je použit certifikát na FortiGate, řekněme SSL Inspection, tak spojení nefunguje. Jakmile jedna z těchto podmínek splněna není, tak se spojení naváže a vše funguje bez chyb.

Detailnější popis nefunkčního nastavení. Pokud máme více Exchange serverů a chceme na FortiGate využít Server Load Balancing HTTPS spojení pomocí Virtual Server. Tak musíme ve Virtual Server použít certifikát a politiku mít v inspekčním módu Proxy-based. Není asi možnost, jak nastavit Load Balancing na více serverů, aby spojení z Dynamics 365 fungovalo.

Řešení je vytvořit novou publikaci pouze jednoho Exchange serveru (třeba pouze pro Dynamics 365, i když jsem také zjistil, že Internet Service Database na FortiGate sice obsahuje položku Microsoft-Dynamics se spoustou IP adres, ale mezi nimi není ani jedna, z které se k nám Dynamics 365 na Exchange připojuje). Destination NAT vytvoříme pomocí Virtual IP, pokud nepoužijeme SSL inspekci, tak může být politika v Proxy Mode i Flow Mode. Ale asi nám bude vadit, že Firewall nekontroluje provoz. Tak můžeme použít SSL Inspection typu Protecting SSL Server, kde zadáme certifikát serveru. Politika pak musí být ve Flow Mode, aby komunikace fungovala.

Případně informace ke konfiguraci FortiGate Firewall politiky, NAT, Load Balancing, Debug.

Nemám energii hledat, co se liší v komunikaci která funguje, a která ne, při různých nastaveních FortiGate. A již vůbec ne se to snažit řešit s Fortinet Support, to by patrně byla ztráta času. Ale bohužel další důležitá věc, kde FortiGate zklamal, a stála mne spoustu času.

Nefunkční HTTPS spojení z Javy verze 11 a větší při SSL inspekci v Proxy Mode

Zatím největší problém, který se dosud nepovedlo vyřešit a velmi nás omezuje. Dokonce jsem otevřel ticket na Fortinet Support, i když nemám moc dobré zkušenosti s podporou velkých firem, takže se snažím vše vyřešit sám. Ale zde jsem přesvědčen, že jde o chybu FortiOS. Jak špatná je Fortinet podpora popíšu dále.

Popis problému a TLS 1.3

Mám Firewall Policy pro přístup do internetu na HTTPS, která je v Proxy-based Inspection Mode a využívá SSL Deep Inspection spolu s AV, Web Filter, Application Control a IPS. Ze všech webových prohlížečů funguje přístup na webové stránky dobře (samozřejmě po vyřešení CA certifikátu a výjimek pro určité weby). Ale využíváme také mnoho Java aplikací, ať již našich vlastních nebo různých vývojových nástrojů apod. Pokud je použita Java 8, tak je vše v pořádku. Dnes se ale hodně přechází na Java 11 a z ní se nedá připojit na většinu HTTPS stránek. Spojení končí na handshake failure.

Nejprve jsem dělal různé pokusy a debugoval připojení z Javy (vývojáři mi k tomu napsali malou aplikaci). Vyzkoušel jsem různé verze OpenJDK 11 a 14 (Adopt Open JDK, Amazon Corretto) i Oracle Java. Všude stejné chování.

V debug logu bylo vidět, že je problém, když se zkusí navázat TLS 1.3. Java 8 nepodporuje TLS 1.3 a zkouší TLS 1.2, což projde bez problémů. Stejně tak, pokud se v Java 11 vynutí použití TLS 1.2 při startu, parametrem -Dhttps.protocols="TLSv1.2", nebo se TLS 1.3 zakáže v konfiguraci, tak spojení přes TLS 1.2 proběhne.

Zakázání protokolu TLS 1.3 se provádí v konfiguračním souboru java.security doplněním do položky (zde je pouze začátek)

jdk.tls.disabledAlgorithms=TLSv1.3, SSLv3, RC4

Zajímavé je, že prohlížeče se pomocí TLS 1.3 připojí. Proto si nemyslím, že je problém v tomto protokolu nebo podpoře TLS 1.3 na FortiGate.

Pokusy konfigurace na FortiGate

Zkoušel jsem různá nastavení na FortiGate a níže jsou výsledky.

  • když se přepne SSL Deep inspection na Certificate Inspection, tak spojení funguje
  • pokud nechám SSL Deep inspection, ale vypnu všechny ostatní Security Profiles, tak spojení funguje, jakmile zapnu libovolný další profil, tak nefunguje (patrně se Deep inspekce neprovádí)
  • pokud politiku přepnu z Proxy-based do Flow-based, tak začne spojení fungovat, myslel jsem, že to takto vyřeším, ale objevil se jiný vážný problém (popíšu dále)
  • pokud se pro adresu nastaví výjimka ze SSL inspekce, tak spojení funguje

Testované adresy

Nejprve jsem měl pocit, že nefunguje přístup na žádný web, ale zjistil jsem, že některé fungují. Příklady funkčních webů a protokol a šifra, co si zvolí prohlížeč.

Těch, které nefungují, je mnohem více. Například:

Debug na webovém serveru

Porovnání funkční a nefunkční komunikace (je vidět, že na některém serveru stejné parametry fungují a jinde ne) mne dovedlo k jedné informaci, kterou jsem ověřil na testovacím Linuxovém web serveru. Pokud se používá OpenSSL 1.0.x (které nepodporuje TLS 1.3), tak připojení funguje. Pokud se použije OpenSSL 1.1.1, tak nefunguje, i v případě, kdy se nepovolí TLS 1.3 v konfiguraci serveru.

Při zapnutí debugu na serveru se také zobrazila již více navádějící informace (to jsem zkoušel, až po debugu na FortiGate popsaném dále).

fd[000e] OpenSSL error[0x14201076] tls_choose_sigalg: no suitable signature algorithm

Zkoušel jsem provádět různý debug na FortiGate. Jednotlivé věci jsou orientačně popsány v dalších kapitolách.

FortiGate (FortiAnalyzer) logy

Traffic logu FortiGate je Action: Accept a Firewall Action: server-rst. V logu SSL inspekce nic. V Event logu (All Types) se dá pro cílovou IP nalézt událost WAD SSL Fatal Alert received, handshake failure.

Výpis session

Nic zajímavého neukáže.

diagnose sys session filter src 10.0.100.10 
diagnose sys session filter dst 192.168.50.45 
diagnose sys session list
session info: proto=6 proto_state=56 duration=2 expire=2 timeout=3600 flags=00000000 sockflag=00000000 sockport=0 av_idx=0
 use=5
...

Packet Sniffer

diagnose sniffer packet Local 'host 10.0.100.10 and host 192.168.50.45' 4 100

interfaces=[Local]
filters=[host 10.0.100.10 and host 192.168.50.45]
24.710746 Local -- 10.0.100.10.51369 -> 192.168.50.45.443: syn 2544371997 
24.713290 Local -- 192.168.50.45.443 -> 10.0.100.10.51369: syn 3361056785 ack 2544371998 
24.713921 Local -- 10.0.100.10.51369 -> 192.168.50.45.443: ack 3361056786 
24.771173 Local -- 10.0.100.10.51369 -> 192.168.50.45.443: psh 2544371998 ack 3361056786 
24.771303 Local -- 192.168.50.45.443 -> 10.0.100.10.51369: ack 2544372422 
24.773966 Local -- 192.168.50.45.443 -> 10.0.100.10.51369: fin 3361056786 ack 2544372422 
24.774212 Local -- 10.0.100.10.51369 -> 192.168.50.45.443: ack 3361056787 
24.777604 Local -- 10.0.100.10.51369 -> 192.168.50.45.443: psh 2544372422 ack 3361056787 
24.777648 Local -- 192.168.50.45.443 -> 10.0.100.10.51369: rst 3361056787

Ani Packet Sniffer moc nepomůže. Člověk z podpory jej spouštěl rozšířený (prý to dokáží převést do Wiresharku).

diagnose sniffer packet any 'host 192.168.50.45' 6 0 1

Debug Flow

diagnose debug flow filter proto 6
diagnose debug flow filter saddr 10.0.100.10
diagnose debug flow filter daddr 192.168.50.45
diagnose debug flow show function-name enable
diagnose debug console timestamp enable
diagnose debug flow trace start 100
diagnose debug enable

Debug WAD

WAD daemon se používá pro SSL inspekciProxy Mode. Pro Flow Mode je to IPS engine. Pro debug je potřeba zapnout level verbose (což jsem prve nedělal). Pak se již určité informace zobrazí.

diagnose wad filter dst 192.168.50.45
diagnose wad debug enable category ssl
diag wad debug enable level verbose
diagnose debug enable

Pouze pár řádků z výstupu.

...
SESSION-ID: d4f4e378b0c9b6e00d1ebf5c0c9106d4ae2021021e6c719f80d354667f41aa75
wad_ssl_proxy_find_session(2667): can't find the session!
__wad_ssl_proxy_filter_ciphers(7560): unsupported num = 12, supported num = 32, intersection num = 32
wad_ssl_proxy_filter_ciphers(7609): wsp(0x7f49d461a880/6) cipher filter: ns=12, is=32
wad_ssl_proxy_srv_continue_fwd_client_hello(9236): sp=0x7f49d461a880/6 start handshake with server. changed_ch=1
wad_ssl_proxy_clt_caps_find_session(12611): sp=0x7f49d461a510/7 find session from (nil)
...
wad_ssl_port_caps_on_alert_recv(12368): fts recv alert level=2 desc=handshake failure
...

Packet Capture

Zachycení komunikace nakonec ukázalo nejvíce a patrně identifikuje problém. Nejprve jsem zachytával komunikaci Wiresharkem na stanici. Ale ověřil jsem, že pomocí Network > Packet Capture v GUI FortiGate, pro rozhraní do sítě, kde je klient, je výsledek stejný a zachycení je pohodlné. Následně jsem pomocí WireSharku provoz analyzoval. Musím přiznat, že až člověk z podpory mne navedl k tomu, abych zachytil komunikaci na vstupním (interní síť) i výstupním (internet) rozhraní. On se totiž pořád snažil nastavit interface na any, když mu to nešlo v GUI, tak použil Packet Sniffer v CLI.

Následující obrázek ukazuje komunikaci od klienta na FortiGate.

Packet Capture od klienta na FortiGate

Na dalším je vidět, jak vypadá od FortiGate na server.

Packet Capture od FortiGate na server

Analýza komunikace

Je vidět, že cílový server dostane Client Hello pro vyjednání TLS komunikace a hned odpovídá Handshake Failure. Porovnával jsem tedy, jak vypadá Client Hello, které odesílá Java, a jak vypadá to, které odchází z FortiGate. Ten navazuje komunikaci na cílový server za klienta a patrně vychází z povolených šifer ve své konfiguraci. Myslel jsem, že FortiGate bude vytvářet Client Hello vždy stejně (dle konfigurace), ale podle testů je vidět, že se hodně odráží od parametrů, které přijdou od klienta.

Nevyznám se detailně v TLS protokolu a zaráží mne několik věcí. Třeba uvádění verze TLS, kdy Wireshark někde označuje v Client Hello paketu TLS 1.2 Record Layer a jinde (podle mne stejné parametry) TLS 1.3 Record Layer. Pak je tam několikrát Version: TLS 1.2 (a třeba od prohlížeče TLS 1.0) a finálně se přitom naváže TLS 1.3 (samozřejmě se uvádí seznam nabízených protokolů v supported_versions).

Porovnání ukázalo, že Java nabízí 45 Cipher Suites, FortiGate z nich několik odstraní a nabízí 33 Cipher Suites. Ale všechny hlavní a podporované šifry na serveru zde jsou, včetně té, která se bez SSL inspekce použije. Liší se trochu i některá rozšíření (extension). Podle chyby, zobrazené při debugu na serveru, jsou hlavní dvě z nich:

  • signature_algorithms
  • signature_algorithms_cert

Rozšíření signature_algorithms obsahuje stejných 16 Signature Hash Algorithms od Javy i od FortiGate. Rozšíření signature_algorithms_cert od Javy obsahuje totožných 16 algoritmů, ale od FortiGate je jich pouze 9 z nich. (nenabízí RSASSA-PKCS1-v1_5 algorithms a Legacy algorithms). Porovnání je na následujících obrázcích.

Client Hello signature_algorithms_cert od klienta Client Hello signature_algorithms_cert od FortiGate

Díval jsem se na komunikaci v různých případech, kdy se spojení naváže. Zaměřil se na extension signature_algorithms_cert.

  • jediná stránka s TLS 1.3, která mi z Javy 11 funguje, je google.com, zajímavé je, že v tomto jediném případě FortiGate toto rozšíření nepoužije
  • když se v Java 11 zakáže TLS 1.3, tak Java stále toto rozšíření vkládá, ale v paketu od FortiGate není
  • prohlížečů spojení vždy funguje, vypadá to, že ty toto rozšíření nevkládají
  • na některé stránky s TLS 1.2 se z Javy 11 připojit lze (třeba, kde je OpenSSL 1.0.x), v paketu od FortiGate se rozšíření nachází, ale podle informací na internetu jej některé servery nepoužívají (pracují pouze se signature_algorithms)
  • když je SSL inspekce vypnutá nebo je politika ve Flow Mode, tak to vypadá, že odchází originální Client Hello, které vytvořila Java (a rozšíření má všech 16 algoritmů a spojení se naváže)

Hledal jsem nějakou dokumentaci, zajímavé je třeba The Evolution of Signatures in TLS a Signature algorithms. Vypadá to, že rozšíření signature_algorithms, bylo přidáno v TLS 1.2. A signature_algorithms_cert až v TLS 1.3 (starší verze TLS 1.3 ho ani nezmiňuje), i když ho patrně používají i některé implementace TLS 1.2.

Nepovedlo se mi nalézt, jak definovat povolené algoritmy v Javě 11 nebo na webovém serveru, na rozdíl od určení povolených Cipher Suites. Stejně tak zjistit, jaký z nabízených algoritmů se na serveru použil.

Závěr

Z výše popsaného jsem přesvědčený, že ve FortiOS je chyba (bug). Špatně pracuje s rozšířením TLS zpráv signature_algorithms_cert. Pokud dané algoritmy povolí pro signature_algorithms, tak by je měl povolit i pro signature_algorithms_cert. Velmi mne překvapuje, že na tento problém již nenarazil jiný zákazník, hlavně velké firmy. Pořád vycházím z toho, o čem mne přesvědčovali zástupci všech výrobců FW, že SSL inspekce se dnes opravdu běžně používá. Potom aplikace v Java jsou naprosto běžné a přechod na verzi 11 je dnes doporučený.

Pokračování řešení a testy

Kontaktoval jsem český Fortinet, kde mi hned reagoval jeden technik a ochotně mi pomáhal, i když říkal, že na podporu nemá vliv. Díky němu jsem získal Eval licenci na FortiGate-VM. Udělal jsem tedy testy čistě nainstalovaného FortiOS 6.2.3 s minimální konfigurací. Problém zde byl. Zkoušel jsem postupné upgrady a nakonec i čistou instalaci FortiOS 6.4.2. Všude se popsaný problém projevuje.

Pozn.: Mimochodem. Nechápu, proč se ve FortiOS 6.4 přesunulo FortiViewMonitor do Dashboard. Navíc u mne defaultní položky v Dashboard vypadají jinak, než na všech obrázcích z dokumentace.

V té době jsem dostal zprávu ze suportu, že problém začal řešit vývojový tým. Po pár dnech, že zjistili, že chování odpovídá známému problému s ID #658654. Aktuálně se vývojáři věnují opravě tohoto problému. Mám dostat informaci o průběhu.

FortiOS 6.2.6 a neopravený bug

Podle Fortinet Supportu měla být chyba opravena ve FortiOS 6.2.6. Také FortiOS 6.2.6 Release Notes uvádí jako opravený problém ID 658654 (Cannot access the specific website using proxy-based UTM with certification inspection.) I když z popisu bych nepoznal, že jde o můj problém.

Provedl jsem upgrade clusteru na verzi FortiOS 6.2.6 a rychlé testy hned ukázaly, že problém stále trvá. Provedl jsem řadu pokusů a chování je úplně identické jako dříve. Co je horší. Předtím, když se nastavila vyjímka ze SSL Inspection (nebo na politice byla pouze Certificate Inspection místo SSL Deep inspection), tak komunikace fungovala. Nyní se projeví stejný problém. Vše funguje pouze ve Flow-based módu nebo když není použit žádný Security Profile.

Zadal jsem nový ticket na Fortinet Support.

Přístup na weby se SSL inspekcí ve Flow Mode

Při testech problémů s Java 11 jsem zjistil, že pokud je politika v inspekčním módu Flow-based, tak vyjednání spojení funguje. Přepnul jsem tedy politiku pro celou firmu a po pár hodinách se mi ozvalo mnoho lidí, že mají problémy s komunikací do internetu na HTTPS. Ve výsledku šlo o pár stejných adres. Když jsem je testoval z prohlížeče, tak mi zprvu vše fungovalo, ale zjistil jsem, že v určitou dobu se stránka opravdu nenačte. Ale pokud v prohlížeči zkusím načíst znovu, tak se již většinou zobrazí. Pak nějakou dobu daná adresa funguje. Kde jsme narazili na problém:

  • https://www.linkedin.com/ - náhodou jsem zjistil, že se mi nenačítá LinkedIn, poprvé stránka timeoutuje
  • https://epodani.cssz.cz/ - pro nás velmi důležitá adresa, která se volá z aplikace (takže nelze provést nové načtení), poprvé se nepovede vyjednat SSL, vrací SSL_ERROR_BAD_HANDSHAKE_HASH_VALUE
  • naše Java aplikace - funguje jako klient (v tuto chvíli s Java 8) server, v průběhu práce začala opakovaně vyskakovat chyba Read time out (SocketTimeoutException)

Protože se chyby objevují občas, tak se velmi špatně debugují. Na skupinu uživatelů (kteří ovšem nepoužívají uvedené dvě problematické aplikace) jsem nechal Flow Mode povolený. Nehlásí mi žádný problém. Ale již, když jsem hledal informace k problému s Java 11, tak jsem našel mnoho diskusí, kde řeší lidé problém s přístupem na určité webové adresy. Občas dokonce jen z určitého prohlížeče. Řešení uvádí naprosto různé, často návrat k nějaké předchozí verzi FortiOS. Různé přepnutí do Proxy mode nebo naopak Flow mode (očividně každému funguje něco jiného). Někomu prý TAC poradil zablokovat na FortiGate TLS 1.3.

Moje zkušenost s Fortinet Support

Jak jsem psal, nemám s podporou velkých firem moc dobré zkušenosti. V minulosti jsem něco řešil se Symantec, Microsoft, Cisco. Radši se snažím problém vyřešit sám. Ale zde si myslím, že je to chyba v systému. Podpora Fortinetu je ještě horší, než co jsem dosud zažil.

Hned při vytvoření ticketu jsem vše popsal, kdy problém nastává a kdy ne, přiložil jsem debugy, logy, zachycení provozu. Nechtěl jsem dávat naši konfiguraci, ale tu si samozřejmě hned první zprávou vyžádali. Tak jsem ji poslal. Měli vše, aby si tento problém vyzkoušeli. Já myslím, že je naprosto obecný, takže by ani nemuseli zkoušet naši konfiguraci, ale pouze vyzkoušet spojení z Javy 11. To se dosud nestalo.

Prvních 14 dní se nedělo nic. Pak mne kontaktoval zahraniční inženýr a domluvilo se vzdálené spojení. Jsem přesvědčen, že nečetl můj popis problému a již vůbec se nedíval do zaslaných podkladů. Na vše se vyptával, debugy, které jsem poslal, si sám vytvořil znovu. Pak pokaždé řekl, že si to musí projít, nebo chtěl ještě něco poslat, a domluvilo se další spojení. A při tom spojení opět stejně. Teprve v tu chvíli začal prohlížet zaslané podklady. Na nic nebyl dopředu připravený.

V té chvíli jsem již došel k přesvědčení, že je problém v Client Hello a TLS rozšíření signature_algorithms_cert. Vše jsem mu detailně popsal, tak jako výše. Ale přijde mi, že to ignoruje a mne neposlouchá. Snaží se třeba problém svést, že se jedná o naši aplikaci (nechápe argument, že se nelze z obecné Javy připojit na stránku Microsoft). Stále dokola si nechává poslat zachycenou komunikaci. A snaží se něco hledat v CLI (přijde mi, že ho příliš nezná).

A to nejjednodušší, aby si problém zkusil někde v labu, to asi není schopen udělat. Po měsíci se začalo řešit s vývojovým týmem a vše se pohnulo.

Pozn.: Docela pozdě jsem zjistil, že zprávy do mailu nechodí dobře a je potřeba si je otevírat na webu. Nejen, že v nich chybí konce řádků, ale někdy chybí kus zprávy (asi se objeví nějaký znak, který v jejich systému způsobí ukončení a odeslání mailu).

Časový průběh

  • 4. 8. 2020 založení ticketu
  • 4. 8. 2020 velice záhy mne odpověděl člověk s českým jménem, požadoval konfiguraci a schéma sítě a radil udělat upgrade na 6.2.4
  • 4. 8. 2020 vše jsem mu poslal, napsal, že 6.2.4 je nepoužitelná (nechodí VPN) a poslal dotaz, již se neozval
  • 10. 8. 2020 automatická zpráva, že ticket byl eskalován na senior inženýra
  • 16. 8. 2020 plánoval si se mnou vzdálené spojení
  • 18. 8. 2020 proběhlo první spojení
  • 25. 8. 2020 proběhlo druhé spojení
  • 31. 8. 2020 proběhlo třetí spojení
  • 8. 9. 2020 jsem dostal požadavek od vývojového týmu na zachycení komunikace na klientovi, serveru i FortiGate ve stejnou chvíli
  • 10. 9. 2020 přišla zpráva, že R&D team zjistil, že chování odpovídá známému problému s ID #658654 a pracuje se na opravě
  • 27. 9. 2020 jsem provedl upgrade na FortiOS 6.2.5
  • 6. 10. 2020 přišla zpráva, že developer team chybu opravil a bude součástí FortiOS 6.2.6 plánované na 3. 11. 2020
  • 30. 11. 2020 jsem provedl upgrade na FortiOS 6.2.6 (vyšla někdy v polovině listopadu), problém trvá stále, dokonce se nyní projevuje, i když nastavíme vyjímku ze SSL Deep Inspection
  • 31. 1. 2021 jsem provedl upgrade na FortiOS 6.2.7 na základě požadavku supportu (z 25. 1. 2021), kteří psali, že sice problém stále řeší, ale protože je k dispozici nová verze, tak požadují otestování. Problém je pořád stejný.
  • 9. 2. 2021 přišla zpráva, která mne již vážně naštvala. Po 5 měsících řešení, kdy již dvakrát uznali bug a jednou tvrdili, že ho opravili, se vrátili úplně na počátek. Poslali dotazy, které jsme řešili na začátku, aby se tím vůbec zabývali. Zase tam tvrdí, že je problém na našem serveru. Vůbec nechápou, co jim stále píšu, že problém je s velkými servery, jako Microsoft, Apple či Apache. I když jsem jim dokázal, že problém je v rozšíření signature_algorithms_cert, tak hledají problém v podporovaných Cipher Suites. Takže jsem jim znovu detailně popsal chování v různých situacích a zachytil komunikaci před FortiGate a jak ji modifikuje. Je tam jasně vidět, že v Proxy Mode (za určitých podmínek) FortiGate upraví Client Hello tak, že ho servery odmítnou. A od FortiOS 6.2.6 se to děje i při Certificate Inspection. Tak jsem zvědavý, jaké bude pokračování.
  • 27. 4. 2021 přišla zpráva, že ten den vyšel FortiOS 6.2.8, kde je chyba opravena, a že mám 5 dní na otestování, pak se ticket uzavře (vtipné). 1. 5. jsem novou verzi nasadil, a zdá se, že konečně opravdu chybu opravili. BTW začal jsem sledovat RSS kanál https://pub.kb.fortinet.com/rss/firmware.xml, kde jsou informace o nových verzích.
zobrazeno: 7026krát | Komentáře [26]

Autor:

Související články:

Fortinet FortiGate a další

Bezpečnostní řešení firmy Fortinet. Nejvíce zaměřeno na Next Generation Firewall (NGFW) FortiGate.

Bezpečnost

Nástroje zajišťující bezpečnost. Primárně Firewall a podobné.

Pokud se Vám článek líbil, tak mne potěšíte, když uložíte odkaz na některý server:

Pokud se chcete vyjádřit k tomuto článku, využijte komentáře níže.

Komentáře

  1. [1] aaa

    Dobrý den.

    Ad připojení FC 98% kdysi jsem to také viděl. Souviselo to tuším s nějakým jiný VPN klientem, který tam byl dřív a který cosi změnil v ip stacku stanice. Byl na to nějaký fix, ale už si nepamatuju. Obecně máme FC na stovkách či spíše tisících klientech a už sem to roky neviděl. Musí to nějak souviset s něčím specifickým a vašich stanicích.

    Ad resetování vašich spojení související s FSSO.

    Ano, může se to dít. FG prohledává logy na DC a vytváří podle toho tabulku userů. Pokud usoudí, že se user někde nalogoval znovu, tak mu stávající spojení resetuje. Ta funkcionalita je tam kvůli řízení přístupů - ne jen kvůli zalogování identity, tudíž reset spojení je logický. Funguje to celkem spolehlivě, ale má to svá specifika.

    Nedávno se mě to co popisujete začalo dít u zákazníka, kde do té doby celkem spolehlivě poolování AD fungovalo. Nakonec jsem zjistil, že pár userů má nově Outlook 2019, který snad v 2 min intervalech generuje na řadiči logon událost, která má stejné ID a FG ji nedokáže odlišit.

    Použijte monitoring agentem. Je to spolehlivější a dají se tam případně řešit výjimky na IP, ID událostí v logu které to monitoruje.

    Jinak povolené verze TLS a Cipher Suites se dají na FG konfigurovat.

    Pátek, 04.09.2020 15:31 | odpovědět
  2. [2] Radek

    Naprosto přesné.

    Přijde mi, že dobrá verze byla 5.6.x pak to u fortinetu šlo jen zkopce. Verze 6.2.x je tak strašně zabugovaná, až to hezký není.

    Dělám hodně věcí přes Fortimanager a ten je ještě horší než Fortigate. Mám seznam asi 13 nefunkčních věcí, nebu asi bugů, a dalších 5 věcí, co by chtělo dodělat aby se FMG dal používat stejně jako normální gui Fortigatu.

    Zatím mám vyřešený první bod mého seznamu. Fortinet support to vyřešil tak že doporučil upgrade z 6.2.3 na 6.2.5.

    Byl to problém s wifi ssid kdy FMG při instalaci policy package mazal radius authentfikaci z SSID.

    Po upgradu na 6.2.5 to sice opravil, ale hned se objevil další bug, kdy hlásí conflict a modified konfiguraci i když tam není žádná změna. Po dotazu na Fortinet support přišla odpověď, že je to "bug" :-) Překvapivě :-)

    A řešení je upgrade na 6.2.6 který ještě nevyšel, ale brzy vyjde. :-)))

    No takže jsem opět pozastavil řešení nefunkčností mého seznamu, kdy jsem vyřešil pouze první bod a při jeho řešení se objevil další, kvůli kterému teď čekám na upgrade FMG.

    A nemá cenu ztrácet čas debugem dalších bugů, když vím, že bude brzy upgrade a bude se to zase chovat úplně jinak.

    Nejhorší byl asi conserve mode po vylistování seznamu ip adres v nějaké "internet-service". To bylo dost.

    A bohužel zákazníci nechápou, že za to technik nemůže.

    Jestli s tím Fortinet něco neudělá, tak brzy asi budeme muset hledat jiný alespoň trochu použitelnější firewall, protože si nemůžeme dovolit pořád jen omlouvat se tím, že je to bug u výrobce.

    Pátek, 04.09.2020 16:00 | odpovědět
  3. [3] Samuraj

    odpověď na [1]aaa: Díky za reakci a informace.

    SSL VPN - zkusím se na to podívat z tohoto pohledu. Ale zkoušeli jsme i čistě nainstalovanou stanici a problém byl hned. Nejvíce lidem se děje to, že několik dní to funguje bez problémů a pak se jeden den vůbec nemohou připojit.

    Jasně TLS a šifry mohu nastavovat, ale určitě nechci třeba TLS 1.3 vypínat. Jestli to chápu, tak ty Signature Hash Algorithms nesouvisí s domluveným Cipher Suite.

    Pátek, 04.09.2020 16:09 | odpovědět
  4. [4] Radek

    Jen ty problémy za dnešek:

    FMG nevidí FortiAP připojené k Fortigatu. Samotný Fortigate to AP vidí jako neregistrované, čekající na autorizaci. Fortigate má GUI readonly, protože je řízen z FMG. Nicméně přes ssh lze konfigurovat. Když ho autorizuji přes ssh CLI, tak pak ale Fortimanager ho stejně nevidí a naopak při příští instalaci policy package konfiguraci smaže.

    Do FMG se mi ho prostě automaticky nepodařilo dostat. Po 2 hodinách jsem ho zkusil do FMG dát ručně a pak už to fungovalo

    i další změny už chodili jak měli.

    Proč ho FMG nevidí jsem nepřišel a není čas na nějaký hlubší debug. Už tak jsem obyčejným přidáním FAP zabil spoustu času.

    Nebo hledání řešení proč nefunguje DHCP? Fortigate ukazoval, že ip adresu počítači přidělil, MAC adresa souhlasila, v seznamu je vidět, nicméně počítač hlásil neznámé spojení, ip adresu nedostal a použil autokonfiguraci.

    Nakonec jsem přišel na to, že na fortigatu v definici dhcp serveru byl příkaz "set ntp-service default".

    Všiml jsem si toho již dříve, ale nepřikládal jsem tomu pozornost, protože proč by měly ntp servery ze systému zakazovat samotné dhcp přidělení ip adresy klientovi? No po přepnutí do defaultní hodnoty "set ntp-service specify" to začalo fungovat, kde specifické ntp servery byly 0.0.0.0. Ale toho času co to stálo....

    Pátek, 04.09.2020 16:14 | odpovědět
  5. [5] jkcinik

    Zdravím, u Sophosu to není o moc lepší. Verze XG 18 je peklo. Podpora z GB je prakticky k ničemu. Obchodně změna politiky každé 3 měsíce.

    Jenže kam jinam? Fortigate je zjevně z bláta do louže.:-(

    Pondělí, 07.09.2020 10:46 | odpovědět
  6. [6] PM

    ID #658654 - taky jsem se na tohle na par mistech nachytal (nejdou treba mapy.cz, angular.io). Na vetsine mist staci prepnout z proxy na flow rezim a mam po problemu (pouze certificate inspection).

    Pátek, 25.09.2020 12:49 | odpovědět
  7. [7] Samuraj

    odpověď na [1]aaa: Připojení FortiClient 98%. Tak jsem zkusil ručně nainstalovat nový notebook, jen základní aplikace a FortiClient 6.4.1. Během dvou dnů se problém se zaseknutím objevil několikrát.

    Pondělí, 28.09.2020 09:08 | odpovědět
  8. [8] TMS

    ad timeouty session: nevím jestli je to ještě aktuální, u nás se to začalo projevovat častým padáním zejména RDP a SMB session po upgrade z FortiOS 6.0.6 na 6.0.8, tudíž jsme se vrátili zpět na 6.0.6, bylo to opraveno až ve verzi 6.0.10 (6.2.5 u FortiOS 6.2)

    Čtvrtek, 03.12.2020 13:04 | odpovědět
  9. [9] MichaelsCZ

    odpověď na [5]jkcinik: Sophos dělám od doby, co koupili Astaro a vznikl po čase Sophos UTM aktuálně v9

    Nasazeno mám několik řešení na MěÚ a středních firmách a musím říci, že to je balzám na duši. Co nastavím, funguje. SSL VPN, Site2Site VPN, Web proteciton (rev proxy) prostě paráda.

    Neznám žádné bugy, prostě to funguje - není to reklama, je to zkušenost. GUI super, logicky navrženo, intuitivní.

    Bohužel moje nadšení končí se Sophos XG, které je tlačené jako TOP produkt, ale je to totální s*ačka :( Koupili Cyberoam a začali to překrucovat na NextGen firewall, ale UTM to nesahá ani po kotníky.

    UTM ještě bude pár let žít, ale jednoho dne skončí a tak se také ptám, KAM PŘEJÍT?

    Čtvrtek, 10.12.2020 22:26 | odpovědět
  10. [10] snydlik

    odpověď na [9]MichaelsCZ: Zdravím, do Sophos XG určitě ne, aktuálně od nich odcházíme k Fortinetu. Přemýšlel jsem ještě o PaloAltu, má někdo nasazeno?

    Úterý, 26.01.2021 22:24 | odpovědět
  11. [11] Samuraj

    odpověď na [10]snydlik: Palo Alto jsem testoval, vypadá zajímavě, trochu jiný koncept, ale cena je úplně jinde :-)

    Středa, 27.01.2021 07:23 | odpovědět
  12. [12] zefe

    S Fortinetom mam 10+ rocne skusenosti, mame ich nasadenych kopec interne, aj u zakaznikov a nie su to zle boxy. Pomer cena/vykon/funkcie je vyborny.

    Support je kapitola sama o sebe...to je fakt, ale u inych vendorov tiez nemam co chvalit. Strasne zalezi, na koho clovek nabehne, zazil som uz aj "royal treatment", kde mi supportak dokodoval patch na opensource vpnc klienta vo svojom volnom case!

    Ale platia tu zlate pravidla:

    1) Ak zivotne nepotrebujete nejaku feature noveho releasu a mate aj inu zabavu, ako robit Fortinetu betatesting, tak pod patch 5 do produkcie nenasadzovat!

    2) Cim dolezitejsi box, tym vyssi patch to chce. V datacentre upgradujeme velmi vynimocne na release skor, ako vyjde aspon patch 8.

    Samozrejme treba citat release notes.

    90% boxov nam aktualne k spokojnosti bezi na 6.0.9 - 6.0.12 (postupne upgradujeme na 6.0.12), niektore dokonca z lenivosti stale na 5.6.x. Na 6.2.x par ks, 6.4.x mam akurat doma.

    Pátek, 12.02.2021 17:05 | odpovědět
  13. [13] Samuraj

    odpověď na [12]zefe: Já jsem stále více naštvaný. Při každém upgradu začnou zlobit další věci. Koupili jsme FortiGate s tím, že chceme využívat všechny jeho "moderní" bezpečnostní vlastnosti. Ale v praxi to vypadá, když chci aby fungovala komunikace, tak musím vše vypnout. Pak ale nepotřebuji FortiGate. Pořád řeším problém, že na nějakou webovou službu FortiGate občas vrací Server Reset, většinou musím pro danou adresu nastavit politiku a změnit buď na Flow mode nebo naopak Proxy mode a problémy zmizí.

    Pokračování 5 měsíčního řešení se supportem za chvíli doplním. Děs.

    Pátek, 12.02.2021 18:28 | odpovědět
  14. [14] zefe

    odpověď na [13]Samuraj: Neskusali/nezvazovali ste prejst na release 6.0.12? Dost sa vam cudujem, ze ste zacinali so 6.2.3. Hoci ano, napr. TLS 1.3 moze byt dovod pre 6.2.

    Rovnako FortiClient, mame tvrdohlaveho zakaznika, co za kazdu cenu chcel FC 6.4.x, cista tragedia, pricom na FC max 6.2.x by fungoval na 90% bez problemov a asi tam aj skonci, ak sa s cerstvym FC 6.4.3 nestane zazrak.

    Akoze nie su veci idealne, ale ked sa v tom clovek nauci chodit, celkom sa da zit. Ticketov otvaram minimum, to vacsinou nema cenu.

    Na druhej strane ja mam hororovu skusenost s Cisco Firepower, od toho nepodarku paralelne beziaceho pri ASA IOS az po prve FTD images. Uz to nechcem ani vidiet. Na takych zakazkach odmietam pracovat, bez ohladu na dosledky.

    Pátek, 12.02.2021 18:44 | odpovědět
  15. [15] Samuraj

    odpověď na [14]zefe: Verzi 6.2.3 nám doporučil přímo Fortinet a byly tam funkce, které jsme při výběru (a srovnávání s jinými výrobci) požadovali. Mám také jeden malý FortiGate s 5.6.8, nejsou tam placené žádné služby, takže se používají jen základní funkce. A to asi běží OK. Ale musím říci, že verze 6.2.x se mi líbí více.

    VPN jsem také popisoval problémy. Nyní již každý ve firmě alespoň jednou narazil na to, že se mu VPN nespojila vždy končila na 98%. Někomu se to děje velmi často. Ale vypadá to, že s FortiOS 6.2.7 a FortiClient 6.4.2 se to snad zlepšilo.

    Pátek, 12.02.2021 19:00 | odpovědět
  16. [16] zefe

    Fortinet tie releasy vzdy odporuca predcasne (na niekom to vyladit musia :-D). Oni zreju dlho, ako dobre vino, 6.2.8 alebo 6.2.9 (=cca o pol roka) uz bude OK aj s pokrocilymi funkciami ;-)

    Ano, kazdy major release ma dalsie zaujimave funkcie a spociatku za vagon bugov. Pre vase problemy je celkom stastie, ze 6.2.x umoznuje prepinat proxy/flow per policy, co je novinka v 6.2.

    Mame novy projekt, kde Fortinet odporucil OS 6.4 a ked to odporucil vendor, so zakaznikom sa pohnut neda a ist aspon so 6.2...takze sa tesim na zabavu.

    FC skuste 6.4.3, vysiel 10.2.2021

    Pátek, 12.02.2021 20:20 | odpovědět
  17. [17] kyssling

    Zdravím vidím, že podpora je všude stejná. Já řešil problémy se Zyxelem s jejím USG110, ale tam jsou tedy vstřícnější, rychlejší, ale většinu problémů stejně nevyřeší až nakonec člověk rezignuje.

    Čtvrtek, 25.02.2021 11:00 | odpovědět
  18. [18] Santa

    FYI, 6 0 l|a sniffer si můžete přeložit do pcapu sami taky: https://github.com/ondrejholecek/sniftran

    Sobota, 27.03.2021 00:06 | odpovědět
  19. [19] Pavel

    odpověď na [15]Samuraj: Ahoj, to nepřipojování Forticlienta se mi naposled stalo před několika roky. Co jsem tak namátkou vypozoroval tak problémy se u nás děly na noteboocích které používali USB 3G/LTE modemy. Pak se mi to semtam stalo při neaktuálním OS.

    Sobota, 03.04.2021 23:27 | odpovědět
  20. [20] Martin

    Neni se cemu divit, Fortinet na jobsech stale hleda pro CZ technika - a asi vi proc.... nejsou lidi :-O

    Mimochodem, radeji Wireguard nez tohle https://thehackernews.com/2021/04/hackers-exploit-unpatched-vpns-to.html

    Pondělí, 12.04.2021 08:34 | odpovědět
  21. [21] Shob

    Po dobrých 5 hodinách debugování s pomocí "application fnbamd" jsem zjistil, proč se po víkendovém upgrade z FortiOS 6.0.12 na 6.4.4 nemůže nikdo přihlásit na SSL VPN v zahraniční dceřiné společnosti. Těžko říct, jestli je to bug nebo featura - u Fortinetu někdy tyhle věci mohou splývat dohromady :) Kupodivu se mi na to podařilo vymyslet i funkční workaround přes SSL VPN realms, teď už to jen zbývá celé nabouchat do Fortimanageru a poslal na příslušné boxy. Není to tedy jediná věc, která mi po upgradu bouchla - ráno jsem řešil mysteriózní chování jednoho pravidla (opět těžko říct zda je to bug či featura), které zapříčinilo záhadnou částečnou nefunkcionalitu jedné "Custom Internet Service" - řešením bylo tu Internet Service zrušit a příslušná pravidla rozepsat na několik IPv4 Policy řádků. Fortimanager je pak kapitola sama pro sebe - na to je třeba speciální skill a hodně zkušeností, aby si člověk něco nerozbil.

    Permanentním zdrojem trablů je FSSO, které nikdy nefungovalo na 100% a zřejmě ani nikdy nebude díky technologickým limitům. Koketuji teď s myšlenkou naučit se C# na takové úrovni, abych si napsal vlastního RSSO klienta (jako service pro Windows 10), který by mne zbavil repetitivních problémů s FSSO, které teď humpolácky řeším fixními pravidly, kde je zapsána IPv4 příslušné stanice (která se ovšem může za určitých okolností změnit).

    Na support Fortinetu jsem se kvůli technickým problémům obrátil zatím jen jednou a výsledek byl takový, že jsme nic nevyřešili – mně už to pak přestalo bavit, tak jsem technika požádal, ať ticket uzavře, že třeba s nějakým budoucím FortiOS se to vyřeší.

    Ze všech IT technologií, které mám primárně na starost, je Fortinet ten největší „pain in the ass“, na druhém místě je pak antispam, ale tam se to dá docela chápat a tak člověk tolik nebrble.

    Pondělí, 12.04.2021 22:17 | odpovědět
  22. [22] Shob

    Tak dnes mi došla od TAC odpověď ohledně toho "Custom Internet Service" bugu. Jak jsem uštěpačně psal o těch "features", byla to nadsázka, ale nakonec se to překvapivě ukázalo jako holá realita:

    *** The following update has been added to your ticket ***

    Dear Customer,

    I have received a response from the development team.

    The behavior observed is by design.

    While matching the traffic, based on the 3T (IP, protocol, port) only the first ISDB object is returned.

    The reason for the behavior is a performance.

    The 3T (IP address, protocol, port) should uniquely match one object.

    The overlap in custom internet service objects should be avoided.

    Alternatively, traditional service + address configuration can be used in policy.

    Based on the gathered information I have requested to add this limitation to the documentation.

    Please let me know if you have further questions on the issue.

    Have a nice day.

    Kind Regards,

    Fortinet EMEA TAC Engineer - Level 2

    Pondělí, 19.04.2021 10:17 | odpovědět
  23. [23] TMS

    Ve FortiOS 6.4.x nefunguje CAPWAP přes VRRP interface.

    Po komunikaci se supportem mi bylo sděleno, ze je to funkční ve FortiOS 7.0 (nebudu aplikovat), nebo je možné počkat na další release 6.4 - možná bude opraveno :-)

    Čtvrtek, 06.05.2021 12:30 | odpovědět
  24. [24] Petr

    Jj, taky nam support Fortinetu doporucil prejit na nejnovejsi FortiOS 7.0 :-O, kde je bug jiz opraven (a do zpetne opravy vetve 6.2/6.4 se jim evidentne moc nechce)... ach jo... snad na hrani doma jo, ale do produkcniho nasazeni rozhodne ne! :-(

    Středa, 12.05.2021 20:35 | odpovědět
  25. [25] AtiT

    Ano, to je hlavni problem Fortinetu, maji hlavni/nejnovejsi vetev a do toho vsechno hrnou, jak vyvoj tak i opravy. Je potreba zalozit supportni tiket a eskalovat ze chcete opravu i v predchozi verzi. Pokud je na to vice tiketu tak se to udela, jinak je to na pul roku nebo i na rok nez se to opravi... jestli vubec. Bohuzel Fortinet nema zadny zavazek jak rychle ma opravit bugy, to je na tom to nejhorsi. Ale support se platit musi.

    Čtvrtek, 13.05.2021 13:05 | odpovědět
  26. [26] RS

    Pracuji u jednoho pomerne velkeho ISPka s mezinarodnim presahem. V siti mame cca 600 zakaznickych FortiGates + ostatni Forti zarizeni typu FMG, FAZ, FortiMail. To, co zazivame se supportem Fortinetu, to se opravdu casto nevidi. Kdyz porovnam s placenymi supporty ostatnich vendoru, co v siti mame (Cisco, Juniper, Huawei), je to nebe a dudy. Velebnosti jdu blejt, Veracomp OK, ale toto fakt ne... :-(

    Úterý, 25.05.2021 18:44 | odpovědět
Přidat komentář

Vložit tag: strong em link

Vložit smajlík: :-) ;-) :-( :-O

Nápověda:
  • maximální délka komentáře je 2000 znaků
  • HTML tagy nejsou povoleny (budou odstraněny), použít se mohou pouze speciální tagy (jsou uvedeny nad vstupním polem)
  • nový řádek (ENTER) ukončí odstavec a začne nový
  • pokud odpovídáte na jiný komentář, vložte na začátek odstavce (řádku) číslo komentáře v hranatých závorkách