Non capisco: quando si programma un IP Trunking nelle HG1500 appartenenti a sedi interconnesse tramite una VPN (nello specifico: VPN Box-To-Box instaurate dai rispettivi Firewall, Firewall che fungono da (Default) Gateway per ciascuna delle HG1500 in questione) GIA' nella programmazione dei Trunk si inseriscono (ad incrocio) gli IP di ciascun nodo remoto...quindi le "rotte" sono GIA' (in qualche misura) dettate (...altrimenti l'HG1500 della Sede A non saprebbe di dover riversare il suo traffico IP/VoIP verso l'HG1500 della Sede B e viceversa...).
Se dovesse essere necessario esplicitare una rotta statica (quindi sul Routing) dell'HG1500 oltre a quella che si crea quando si programma l'IP Trunking significherebbe che i due Firewall non sono programmati (la loro VPN non è programmata) a dovere.
O sbaglio il ragionamento ?
Sbagli in parte il ragionamento e in parte è corretto.
Lascia perder per un attimo gli ip "incrociati" sui trunk degli HG.
In una situazione normale accade questo:
Un pc deve instradare un pacchetto, se la destinazione è nella sua rete (controllo tramite sn mask), instrada il pacchetto diretto.
Se non è nella sua rete cerca un rotta statica per instradare, se non è nelle rotte statiche usa il GW di default.
Tralaltro il gw di default in teroia non esiste perchè un una rotta statica verso tutte le destinazioni. Vedi un "route print" su qualunque pc.
Negli HG, invece, accade una cosa strana specialmente nella parte voip:
HG deve instradare un pacchetto, la destinazione non è nella sua rete, per instradarlo usa la catena delle rotte statiche e poi il default GW.
I pacchetti di ritorno (per chi conosce iptables: stato connessione RELATED, ESTABLISHED) vengono instradati secondo la catena già "scovata" per l'invio.
Quando HG riceve un pacchetto, per la prima volta (per chi conosce iptables: stato connessione NEW) e il pacchetto proviene da una rete diversa, HG in alcuni casi non risponde.
Se invece la rete di provenienza è presente tra le rotte statiche allora risponde.
Ora il motivo esatto non lo so...
le ipotesi sono due:
A) Siemens ha messo volutamente questa cosa come controllo di sicurezza
B) E' un bug: hg riceve il pacchetto, cerca di rispondere ma non trova una via su cui instradarlo.
Tralatro questa cosa non è valida sempre. esempio che è successo a me:
Due sedi in VPN con cornet ip e alcuni pc connessi in vpn con softclient SIP.
Sede A 192.168.60.x
Sede B 192.168.70x
pc in vpn 192.168.250.x con Sede A
le due sedi avevano un solo gw di default, i pc di più avendo una VPN sul pc ma non centra.
I pc si registravano (e funzionavano) correttamente sulla sede A, Sede A e Sede B non si connettevano in cornet.
Aggiunte le rotte statiche sui due HG per le due sedi (straripeto assolutamente inutili in teoria) e tutto ha preso a funzionare.
Forse questo problema c'è solo con le connesisoni TCP (trasporto del cornet se non sbaglio) mentre con le UDP (SIP) no.
Oppure è proprio stato fatto come controllo di sicurezza solo sui trunk per. Non lo so.