Fortinet - Fortigate Dual Link Load Sharing

Test dual link Internet in HA con Load Balancing del traffico tramite policy routing Per configurare un doppio link Internet in High Availability con Load Balancing e’ necessario abilitare i due gateway Internet a disposizione con lo stesso peso in modo da effettuare il load balancing e contemporaneamente l’ alta affidabilità e impostare il policy routing per selezionare il link preferenziale. Per fare questo inseriamo una default route 0.0.0.0/0.0.0.0 con gateway l’ip del router internet (nell’esempio 62.123.90.25) sulla wan1 impostando una distanza 10, poi impostiamo una seconda default route con l’ip del router della wan2 (nell’esempio 80.204.121.193) impostando la stessa distanza.

Ora le cose interessanti. Proviamo

Impostando lo stesso peso nel routing monitor compaiono entrambi i default gateway.

Ora nel policy route impostiamo la route internet preferenziale (in questo caso outgoing interface senza specificare il gateway che viene preso in automatico). Nell’esempio impostiamo una policy route che forza tutto il traffico proveniente dalla subnet 10.200.1.0/24 a transitare in uscita verso l’interfaccia wan1.

Per la navigazione internet non vengono riscontrati problemi. Dalla sottore 10.200.1.0/24si riesce a raggiungere internet tramite il link Internet attestato sulla wan1. Adesso in questa configurazione diventa interessante analizzare il comportamento delle route statiche sul firewall. Prenderemo come lan di riferimento per effettuare i test la sottorete 10.200.1.0/24 con default gateway 10.200.1.254 (ip del nostro firewall). La configurazione del firewall e’ sempre con doppio link in Load Balancing con le policy route attive. Nell’esempio e’ necessario raggiungere una sottorete remota 10.100.1.0/24 raggiungibile tramite un router della lan, il router con ip 10.200.1.1. Dalla figura si nota che per raggiungere la sottorete 10.100.1.0/24 e’ stata impostata una route statica.

Interessante vedere come lavorano i client che puntano come default gateway al 10.200.1.254, il nostro firewall, ma che possonoraggiungere la 10.100.1.0/24 tramite il router 10.200.1.1.

Nel test effettuato in modalità doppio link in HA senza policy routing abbiamo visto come con questa configurazione venivano passate al client dal firewall Fortigate, tramite un icmp redirect delle route statiche che permettevano al client di raggiungere la sottore remota 10.100.1.0/24.

Nella configurazione con il policy routing attivo notiamo la prima differenza: gli host non riescono piu’ a raggiungere la sottorete 10.100.1.0/24 e il messaggio d’errore e’ : “TTL scaduto”

E nella routing table dei client non compaiono più le route statiche passare tramite icmp redirect.

In questo caso il firewall Fortigate legge come prima la policy route riguardante la rete interna e ignora la route statica (che prima provacava l’icmp redirect) ancora presente. Da qui si evince cha la policy route ha precedenza su tutte le route statiche (e non solo come vedremo piu’ avanti).

A questo punto allora impostiamo una policy route che forzi i client interni a usare il gateway 10.200.1.1 per raggiungere la sottorete 10.100.1.0/24 (esattamente come faceva la route statica) tramite l’interfaccia interna

Spostiamo la route appena creata in alto come preferenziale (le policy route non usano la distanza per impostare la precedenza ma l’ordine dall’alto al basso, con quelle in alto lette per prime)

Ora provando a fare un pingda un client vediamo che ancora non funziona, ma stavolta non con messaggio “ttl scaduto” ma con “request timeout”

Controllando lo sniffer non vediamo passare sulla rete nessun “icmp redirect”, quindi i pacchetti arrivano direttamente al firewall e lui li droppa. Nel primo caso in cui non avevamo impostato una policy route specifica per la sottorete in questione i pacchetti uscivano dal firewall secondo l’impostazione dell’unica policy route presente (quella che forzava la rete 10.200.1.0/24 verso 0.0.0.0 ad andare sull’interfaccia internet ). Quindi in questo caso i pacchetti diretti verso al

sottorete 10.100.1.0/24 finendo su internet si perdevano fino a fare troppi hop e provocando l’errore di TTL scaduto. In questo secondo caso i pacchetti non si perdono su internet, sembrano seguire la route corretta ma vengono droppati, infatti il messaggio d’errore è “Request Timed Out”.

A questo punto abilitiamo una regola che premette il traffico da internal a internal.

Ora il ping dal client ha ripreso a funzionare.

In che modo? Sempre con icmp redirect (esattamente come nel caso del doppio linkin HA con solo le route statiche), infatti lo sniffer vede passare gli icmp

E la routing table del client di test 10.200.1.10 si è ripopolata con le route statiche

La differenza è che stavolta le regole di firewall vengono controllare prima delle regole di policy di routing. Quindi in questo caso la regola firewall permette di utilizzare la policy route che a sua volta ridirige con lo stesso metodo delle route statiche il client verso la sottorete remota 10.100.1.0/24. Ultima nota: se provo a pingare un host in una ipotetica dmz, ad es. 10.20.1.0/24 non ci riesco nonostante le regole firewall siano impostate per tale operazione. In questo caso vengo nuovamente spedito su internet (con tanto di TTL scaduto)

Il polcy routing ha priorità non solo sulle route statiche ma addirittura sulle route delle interfacce direttamente connesse!

Per poter attraversare quindi le interfacce del firewall da una specifica sottorete devo creare una policy route per ognuna delle interfacce connesse relative, cosa superflua quando si usa il routing statico. In questo caso per andare da una subnet in lan ad es. 10.200.1.0/24 verso un’interfaccia del firewall in dmz con ad es. 10.20.1.0/24 devo creare una policy route che forzi il traffico verso l’interfaccia dmz coma da figura:

In questo modo il routing è ok e il ping funziona

Test eseguiti su Fortigate firmware 3.0 MR6 patch2 Autore: Fabrizio Rosina Per ulteriore documentazione e articoli: www.gzone.it