Problema trunk Ip in cornet o sip tra due centrali H3000

[Kimera]

Ho parlato con un altro installatore e mi ha confermato che anche lui, in casi simili, è stato costretto ad inserire delle rotte statiche (ripeto, teoricamente totalmente inutili essendoci un solo GW) sugli HG.

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 ?

D'altra parte ho il caso sotto gli occhi di un PC nella LAN della Sede A (IP Statico/Subnet Mask/Default Gateway per la Sede A) connesso ad un Firewall Netgear ProSafe FVS318 in VPN Box-to-Box con un'altro Firewall ad esso gemello installato presso la Sede B dove ho un'altro PC con le medesime impostazioni ovviamente inerenti alla Sede B (quindi, ovviamente, LAN differenti come nel tuo caso).

Tra le altre cose (a "complicare" lo scenario) ci sono di mezzo i Router di Telecom Italia per le due rispettive ADSL Alice Business che fanno NAT (1 solo IP Pubblico Statico disponibile) e sui quali ho fatto il puro e totale Port Forwarding tra le loro WAN e le WAN dei rispettivi Firewall (che ovviamente sono connesse alle LAN dei rispettivi Router)...quindi la configurazione è: PC - Firewall - Router - Router - Firewall - PC. Nulla di trascendentale. Nessuna Rotta Statica nei PC.

[ziotibia81]

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.
 

[Davide_Baratelli]

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.

le rotte statiche e il defautl gateway servono per indicare verso che destinazione mandare i pacchetti... non per valutare da chi arrivano. nell' header del pacchetto c'è l'indirizzo del mittente e del destinatario con le rispettive porte . se l'indirizzo del destinatario non  è nella stessa sotto rete viene inviato o al default gateway oppure se presente una rotta statica di quella sotto rete al suo gateway ....
Per quanto riguarda la differenza tra tcp e udp la differrenza è solo a livello di trasmissione dei pacchetti... TPC controlla la reale ricezione del pacchetto da parte del destinatario e non fa il riodino dei pacchetti  ed è per questo che è usato nella trasmissione della voce (sip e non sip) ma anche di tutti le trasmissioni "real-sensitive"

[Kimera]

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.

OK, capisco.

Ma quando si definisce una rotta (statica) verso una Subnet che non è la Subnet cui fa parte l'Host su cui tale rotta viene definita (sia che essa sia la Default Route sia che essa sia una nuova Route)...si deve sempre definire sempre un "Next-Hop-Router" che altri non è che il Gateway per tale rotta...altrimenti i pacchetti destinati alla nuova Subnet gestita da tale rotta non potrebbero essere instradati.

Oppure si può definire una rotta statica che usi come Next-Hop una interfaccia fisica specifica (eth0, seriale, ecc.) senza definire un Gateway IP.

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...

Ma questo è il comportamento tipico di un Firewall che ha la funzionalità di "Stateful Inspection"...il tuo riferimento ad Iptables non è infatti fatto a caso. O tale Inspection viene fatta dalla HG (?) oppure da uno dei due Firewall (o da entrambi).

OK, se non ci sono rotte statiche (come tutti presumiamo) definite nelle due HG, esse instraderanno tutti i pacchetti destinati alle Subnet "aliene" (non le proprie) al loro rispettivo Default Gateway...che è anche il Default Gateway e si ritorna al caso base.

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.

Oltre al Router/Firewall che instaura la VPN non è che sull'HG c'è il Firewall attivato ? Che versioni hanno queste benedette HG1500 ?

Edit 1: in effetti la parte di Routing compete alle rotte mentre la parte di Firewalling è quella che fa l'analisi del traffico IP che transita (o che vuole transitare "attraverso" il - o i - Firewall coinvolti)...

Edit 2: non è che uno dei due Firewall (o entrambi) deputati a realizzare la VPN siano "Stateful Inspection" (sarebbe quasi normale) oppure eseguano controlli (ACL ?) specifici e differenti tra loro (inerenti MAC Address/IP sorgente/destinazione o altro)?

[ziotibia81]

[..]le rotte statiche e il defautl gateway servono per indicare verso che destinazione mandare i pacchetti... non per valutare da chi arrivano. nell' header del pacchetto c'è l'indirizzo del mittente e del destinatario con le rispettive porte . se l'indirizzo del destinatario non  è nella stessa sotto rete viene inviato o al default gateway oppure se presente una rotta statica di quella sotto rete al suo gateway ....[..]

Lo so benissimo!!!
Ma sembra che gli HG non ragionino così!!

[Kimera]

Lo so che lo sai...non l'ho scritto per te...l'ho scritto per fondare un ragionamento.

[ziotibia81]

Lo so che lo sai...non l'ho scritto per te...l'ho scritto per fondare un ragionamento.

ma non l'hai scritto tu....

[Kimera]

porca miseria...hai ragione...non ho nemmeno guardato se era mio l'intervento...è che ero così sicuro di star scambiando con te i miei pareri che sono andato dritto...aaaaaaaaaa sto diventando vecchio ragazzi miei!

Allora diventa: "Io lo so che lui sa che tu lo sai...l'ha solo scritto per fondare un suo ragionamento"...AAAAAAA

[ziotibia81]

OK, capisco.

Ma quando si definisce una rotta (statica) verso una Subnet che non è la Subnet cui fa parte l'Host su cui tale rotta viene definita (sia che essa sia la Default Route sia che essa sia una nuova Route)...si deve sempre definire sempre un "Next-Hop-Router" che altri non è che il Gateway per tale rotta...altrimenti i pacchetti destinati alla nuova Subnet gestita da tale rotta non potrebbero essere instradati.

Oppure si può definire una rotta statica che usi come Next-Hop una interfaccia fisica specifica (eth0, seriale, ecc.) senza definire un Gateway IP.

Normalmente è così...

Ma questo è il comportamento tipico di un Firewall che ha la funzionalità di "Stateful Inspection"...il tuo riferimento ad Iptables non è infatti fatto a caso. O tale Inspection viene fatta dalla HG (?) oppure da uno dei due Firewall (o da entrambi).

OK, se non ci sono rotte statiche (come tutti presumiamo) definite nelle due HG, esse instraderanno tutti i pacchetti destinati alle Subnet "aliene" (non le proprie) al loro rispettivo Default Gateway...che è anche il Default Gateway e si ritorna al caso base.

Il riferimento a iptables non è del caso specifico, è per "dovere di cronaca".
Il comportamento del firewall potrebbe essere ma in questo caso è irrilevante:

sono già state fatte prove per cui si vedono i pacchetti arrivare ad HG ma HG non risponde.
Quindi i firewall non centrano, i pacchetti sono transistati.
Poi la prova corretta sarebbe collegare un pc e l'hg ad uno stesso hub e verificare con un packet sniffer.
Penso sia stato fatto così
 

Oltre al Router/Firewall che instaura la VPN non è che sull'HG c'è il Firewall attivato ? Che versioni hanno queste benedette HG1500 ?

Edit 1: in effetti la parte di Routing compete alle rotte mentre la parte di Firewalling è quella che fa l'analisi del traffico IP che transita (o che vuole transitare "attraverso" il - o i - Firewall coinvolti)...

Edit 2: non è che uno dei due Firewall (o entrambi) deputati a realizzare la VPN siano "Stateful Inspection" (sarebbe quasi normale) oppure eseguano controlli (ACL ?) specifici e differenti tra loro (inerenti MAC Address/IP sorgente/destinazione o altro)?

- Niente firewall su HG
- Versione V8 (il firmware esatto non me lo ricordo)
- come ho già detto sopra se i pacchetti arrivano ad HG e HG non risponde i firewall non centrano. I pacchetti sono arrivati quindi i firewall hanno fatto il loro lavoro.

[Kimera]

Stando così le cose è evidente che l'unico imputato al banco è l'HG1500. Sarei curioso di fare un diff sui file di configurazione per vedere tra quella di Como e quella di Prato le differenze significative.

OK, HiPath HG1500 V8 (APS: HI-G15.85.006)...ignoro lo stato (APS) dei due HiPath 3000 V8.

Detto fatto (perdonatemi la formattazione):

Code: [Select]

diff -y --suppress-common-lines export_como.xml export_prato.xml
Ecco:

Code: [Select]

172.51.100.1</HostID>          | 172.25.100.1</HostID>
02/07/2013 17:18:42</DateAndTime>              | 02/07/2013 17:22:37</DateAndTime>
<I_HiPath3000_ID>3</I_HiPath3000_ID>       | <I_HiPath3000_ID>1</I_HiPath3000_ID>
<gwHG1500SlotNumber>7</gwHG1500SlotNumber>       | <gwHG1500SlotNumber>9</gwHG1500SlotNumber>
<IUTCTime>1360253923</IUTCTime>       | <IUTCTime>1360254157</IUTCTime>
<SystemUpTime>32471</SystemUpTime>       | <SystemUpTime>131486436</SystemUpTime>
<SystemDateAndTime>02/07/2013 17:18:43</SystemDateAndTime>    | <SystemDateAndTime>02/07/2013 17:22:37</SystemDateAndTime>
<SystemIPAddress>172.51.100.1</SystemIPAddress>       | <SystemIPAddress>172.25.100.1</SystemIPAddress>
<SystemName>Nodo COMO</SystemName>               | <SystemName>Nodo PRATO</SystemName>
<SystemLocation></SystemLocation>       | <SystemLocation>Prato</SystemLocation>
<ITraceStartedAt>02/07/2013 17:18:44</ITraceStartedAt>       | <ITraceStartedAt>02/07/2013 17:22:38</ITraceStartedAt>
<PActionCurrentTime>1360257524</PActionCurrentTime>       | <PActionCurrentTime>1360257759</PActionCurrentTime>
<PActionCurrentTime>1360257524</PActionCurrentTime>       | <PActionCurrentTime>1360257759</PActionCurrentTime>
<PActionCurrentTime>1360257524</PActionCurrentTime>       | <PActionCurrentTime>1360257759</PActionCurrentTime>
<PnodeID>1</PnodeID>       | <PnodeID>2</PnodeID>
<PnodeID>2</PnodeID>       | <PnodeID>3</PnodeID>
<PaccClientPassword> </PaccClientPassword>       | <PaccClientPassword>4 43 22 56 4 43 21 176 1 131 244 208 5 11
<PCarNodeTabNodeId>1</PCarNodeTabNodeId>       | <PCarNodeTabNodeId>2</PCarNodeTabNodeId>
<PCarNodeTabIPAdr1>172.25.100.1</PCarNodeTabIPAdr1>       | <PCarNodeTabIPAdr1>172.24.100.1</PCarNodeTabIPAdr1>
<PCarNodeTabNodeId>2</PCarNodeTabNodeId>       | <PCarNodeTabNodeId>3</PCarNodeTabNodeId>
<PCarNodeTabIPAdr1>172.24.100.1</PCarNodeTabIPAdr1>       | <PCarNodeTabIPAdr1>172.51.100.1</PCarNodeTabIPAdr1>
<PCarCallAddrTabNodeId>1</PCarCallAddrTabNodeId>       | <PCarCallAddrTabNodeId>2</PCarCallAddrTabNodeId>
<PCarCallAddrTabCallno>1</PCarCallAddrTabCallno>       | <PCarCallAddrTabCallno>7</PCarCallAddrTabCallno>
<PCarCallAddrTabNodeId>2</PCarCallAddrTabNodeId>       | <PCarCallAddrTabNodeId>3</PCarCallAddrTabNodeId>
<PCarCallAddrTabCallno>7</PCarCallAddrTabCallno>       | <PCarCallAddrTabCallno>8</PCarCallAddrTabCallno>
<PIF1LANIPAddress>172.51.100.1</PIF1LANIPAddress>       | <PIF1LANIPAddress>172.25.100.1</PIF1LANIPAddress>
<PIPDefaultRoute>172.51.1.254</PIPDefaultRoute>       | <PIPDefaultRoute>172.25.1.254</PIPDefaultRoute>

Mi sono permesso di omettere i veri Nomi assegnati ai Nodi ed i MAC Addresses.

[ziotibia81]

Pensa che io, in quel caso, avevo i problemi tra Verona e Romania...

Spostarsi per i vari debug era comodissimo... 

[Kimera]

JaJaJa probabilmente una Romena val bene un SSH disattivato o un Port Forwarding (Web/Manager E) mai attivato! JaJaJaJa

[ziotibia81]

A dir la verità le possibilità di connettersi da remoto c'erano...
Però il cliente voleva qualcuno in loco a risolvere il problema...

Ho visto il diff e praticmante gli HG hanno la stessa configurazione salvo le ovvie differenze per i nodi e la rete.

[Kimera]

Allora, esaminando lo schema che è stato fornito e i diff tra Como e Prato e tra Prato ed Arezzo non sembra esserci alcuna anomalia (gli IP Addresses, le Subnet Masks e le Default Routes - Gateway - riportati nello schema sono congruenti con le impostazioni degli XML), ad esempio le CAR Tables indicano:

Nodo 3 (Como)
verso Nodo 1 Call 1xx
verso Nodo 2 Call 7xx
e gli IP dei Nodi 1 e  2 sono corretti (rispondenti a quelli indicati nello schema).

Nodo 1 (Prato)
verso Nodo 2 Call 7xx
verso Nodo 3 Call 8xx
e gli IP dei Nodi 2 e 3 sono corretti (rispondenti a quelli indicati nello schema).

Nodo 2 (Arezzo)
verso Nodo 1 Call 1xx
verso Nodo 3 Call 8xx
e gli IP dei Nodi 1 e 3 sono corretti (rispondenti a quelli indicati nello schema).

Noto che Como e Prato hanno un <PTraceLevel> "EVTLOG" settato a 3 che invece Arezzo l'ha settato a 0 (disattivato).

Mistero...Kezzenger...

Saluti, Kimera.

P.S.
HiPath HG1500 V8 R5.7.3 HI-G15.85.007-003 (25/10/2011) contro HiPath HG1500 V8 R5.6.0 HI-G15.85.006 (15/07/2011)...Kezzenger...HiPath 3000 V8 R7.1.0...Kezzenger!

[ziotibia81]

...aggiungere le rotte statiche inutili sugli hg...

Per un mistero degno di Kezzenger ci vuole una soluzione degna di Kezzenger!!