Ciao a tutti,
Uno dei miei clienti ha la seguente configurazione:
site A ← IPsec → site B ← IPsec → fornitore X
Recentemente abbiamo implementato SD-WAN con site B come hub e diversi altri spoke. Tutto funziona bene per tutti loro.
Tuttavia, dopo aver migrato il site A nello SD-WAN, eliminando l’IPsec statico, gli utenti segnalano che un’app web dal lato fornitore è super lenta e non risponde.
Tutte le policy coinvolte non hanno profili di sicurezza né ispezione.
SD-WAN usa BGP sul loopback con 3 tunnel. Gli SLA sono perfetti su ogni tunnel.
MTU per l’interfaccia WAN era impostato a 1492, quindi ho provato a reimpostarlo al valore predefinito (ma i VPN non sono scesi durante il cambiamento, il che è strano).
Oggi ho disabilitato SD-WAN e riabilitato IPsec e da allora funziona bene.
È piuttosto strano perché tutto ciò che è cambiato è che l’IPsec non è più uno solo e il routing è dinamico invece che statico.
Qualcuno ha vissuto qualcosa di simile? Come avete risolto? Potrebbe davvero essere qualcosa legato all’MTU?
L’unica cosa che cambi con lo sdwan è la decisione di routing, da policy statica a dinamica.
Come potrebbe essere legato all’MTU?
Se le policy sono le stesse, tranne che la zona sdwan è referenziata invece dell’interfaccia tunnel, non può essere nemmeno legato alle policy.
Se lo stesso tunnel viene scelto dalle tue regole/strategia sdwan e tutti gli SLA rilevanti sono a posto, non vedo come possa essere correlato.
Prova forse una regola manuale senza SLA e solo il tunnel principale.
Qual è la differenza di configurazione tra il vecchio tunnel IPsec e quello nuovo sul sito A?
Può essere molte cose a seconda della configurazione/configurazioni reali.
Ma le sessioni ausiliarie mi sono venute in mente leggendo il tuo problema.
Le hai abilitato? https://community.fortinet.com/t5/FortiGate/Technical-Tip-SD-WAN-Auxiliary-Sessions/ta-p/229467
Se l’OP ha impostato i tunnel con costo uguale potrebbe multiplexare il traffico tra essi e con latenza diversa i pacchetti potrebbero arrivare fuori ordine che potrebbe causare ritrasmissioni che rendono tutto molto laggoso.
Assicurati che il percorso preferito abbia la priorità migliore in SDWAN e non una priorità uguale.
Sto già usando manuale, inoltre attualmente non ho SLA sul controllo di salute del tunnel.
L’unica differenza tra IPsec vecchio e nuovo sono crittografia/autenticazione (AES256-SHA512 prima, AES256-SHA256 dopo) e il dispositivo di rete (disabilitato prima, abilitato dopo).
Ho letto sulla documentazione che abilitare il net-device può causare problemi di prestazioni, ma sembra essere necessario sul lato spoke per SD-WAN con ADVPN. Tuttavia è strano, dato che ho solo 4 tunnel (prima 2), non centinaia…
Equal cost in SD-WAN non significa che i pacchetti vengano load-balanced. Supponendo che tu non abbia specificamente impostato l’opzione load-balance, o usato massimizzare la larghezza di banda come metodo (dipende dalla versione), i membri con costo uguale non vengono usati per il load-balancing. Il costo più basso ha un tie-breaker, che è la preferenza dell’interfaccia.
È una buona idea… stavo assumendo che l’OP stesse usando SLA
Ma usi advpn o un tunnel dial-up? Se no, suggerirei di disabilitare net device
Intendevo l’opzione di massimizzare la larghezza di banda.
È un collegamento dial-up sul hub, S2S normale sullo spoke ma configurato con ricevitore autodiscovery per avere scorciatoie con altri spoke
Sembra un problema interessante.
A questo punto, farei PCAP sul client, sull’interfaccia in ingresso e uscita di Fortigate e sul server di destinazione, se possibile, e analizzerò i pacchetti.
Dalla descrizione non ho idea di come possa essere colpa di Fortigate, anche se sembra essere tutto ciò che è cambiato.
Hai provato a eliminare il tunnel dalla zona sdwan e a rifare una rotta statica? Solo per dimostrare che questo è il problema?
Sì, è interessante davvero. Ho già distribuito SD-WAN nello stesso modo su molti altri clienti e niente di tutto ciò è mai accaduto.
Prima del weekend, ho disattivato tutti i tunnel SD-WAN e riabilitato l’IPSec + rotte statiche e il cliente ha detto che il problema è scomparso immediatamente. Farò nuovamente qualche controllo sulla stabilità.
Penso comunque di provare disabilitando il net-device e vedere cosa succede (sperando che non rompa nulla).
Non avrai advpn, è quello che succederà lol.
Fammi sapere come va a finire. Non ha senso secondo me.
Solo per informare, perché ero molto curioso, ho configurato un lab virtuale su FNDN. Risulta che anche con net-device disabilitato, le scorciatoie tra gli spoke si formano normalmente e vengono usate per il traffico diretto.
Ad essere onesti, penso che questo dovrebbe funzionare anche in un ambiente di produzione. Testerò e ti farò sapere.
Non ho configurato advpn da molto tempo, quindi forse qualcosa è cambiato. Troverei comunque fastidioso non vedere quale tunnel advpn è quale spoke con net device disabilitato.