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