Newsgroup: it.comp.reti.ip-admin
Titolo: strane rotte

Ciao a tutti.
 
Ieri ero da un mio cliente che ha una normalissima LAN 
192.168.1.0/24
.
 
Era presente un fornitore di telefonia che gli sta installando un sistema 
voip, costui mi dice:
 
La rete voip e' 192.168.10.x e l'ho collegata alla lan tramite un mio 
firewall watchguard con due porte eth una 192.168.1.253 e l'altra 
192.168.10.253,
mi occorre poter raggiungere gli apparati voip dai pc per cui dovresti 
aggiungere una rotta sul tuo firewall per cui la rete 192.168.10.0 è 
raggiungibile dal gateway 192.168.1.253 che è il mio watchguard.
 
Quindi:
 
rete    192.168.1.0
             |
             |
             |------------  192.168.1.254 mio firewall
             |
        ---------------
        192.168.1.253
         watchguard
        192.168.10.253
        --------------
             |
rete voip  192.168.10.0
 
 
Provo a fare quanto mi chiede e vedo che riesco a pingare dal mio pc 
192.168.1.1 con WIN-XP un suo apparato 192.168.10.10 solo se faccio fare NAT 
al mio firewall.
 
Se non eseguo il NAT il ping non fuziona.
 
Mi pare che sia giusto così in quanto se eseguo il NAT, il pacchetto di 
ritorno del ping esce dal watchguard diretto al mio firewall che esegue il 
contro NAT e manda il pacchetto al mio pc.
 
Se non eseguo il NAT, il pacchetto di ritorno, quando esce dal watchguard va 
direttamente al mio pc il quale però non se lo aspetta provenire dal 
watchguard ma se lo aspetterebbe arrivare dal 192.168.1.254 che è il gateway 
a cui l'ha mandato.
 
E giusto ?
 
La cosa strana è che su tutti i pc della rete 192.168.1.0 che hanno Win XP 
accade quello che ho descritto, ma su un pc con Win-Vista e un MAC sempre 
sulla rete 192.168.1.0 il ping funziona sempre sia con NAT che senza !
 
 
 
 
 
-- 
Stefano L.

 a cui l'ha mandato.
 
e da cosa stabilirebbe l'IP del gateway che gli sta consegnando il
pacchetto?  O:-)
 
 
 
-- 
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/
 
 
 

 E giusto ?
 
Non mi pare, perche' il pc sa come instradare, visto che ha come gateway
di default 192.168.1.254. Semmai, non gli arriva proprio niente di
ritorno dal gateway, e mi spiego: per quanto riporti (col nat,funziona),
mi pare piu' plausibile che il gateway/pbx non abbia una route che gli
dica come raggiungere 
192.168.1.0/24
. Cioe', non sa che 192.168.10.253
e' il gateway che gli consente di raggiungere la rete 
192.168.1.0/24
,
pertanto il pbx se gli arriva qualcosa dal MAC dell'interfaccia con ip
192.168.10.253, che ha come source address un ip di 
192.168.1.0/24
, non
ha alcun elemento per supporre che sia un pacchetto "routato" dal
firewall, e rispondere di conseguenza.
 
bye G.L.
-- 
Da i.d.c.tutela:
P.S. Quando ci sarà lo switch-off, avrò problemi anche col
monitor del PC? Ho visto che è collegato in modalità analogica.

 pacchetto?  O:-)
 
Hai ragione, l'IP da nulla, forse c'entra qualcosa il mac-address  ?
 
Non sono un esperto in materia, ma vorrei capire il perche' di quello che 
accade. 
 
-- 
Stefano L.

 firewall, e rispondere di conseguenza.
 
Proseguo, per completezza: se invece il firewall natta la 
192.168.1.0/24
 
su 192.168.10.253, il source address dei pacchetti inoltrati (e
modificati dal natting) sara' sempre 192.168.10.253, pertanto il pbx
risponde come risponderebbe ad un qualunque host sulla sua rete, ed il
firewall sa dalle sue tabelle di natting come inoltrare la risposta
sulla rete nattata 
192.168.1.0/24
.


 Hai ragione, l'IP da nulla, forse c'entra qualcosa il mac-address  ?
 
Sě e No.
Sě: perchč se volesse potrebbe "capire" chi gli sta consegnando il
pacchetto guardando il MAC sorgente.
No: perchč non mi risultano OS che facciano enforcing di questo genere,
nč avrebbe senso che lo facessero; avere routing asimmetrico non č cosě
anomalo, e su Internet at large č assolutamente la norma...


 firewall, e rispondere di conseguenza.
 
Gia' ma se io natto mi presento come 192.168.1.254 che è l'IP del mio 
firewall.
 
 
 
-- 
Stefano L.

 firewall, e rispondere di conseguenza.
 
O meglio, forse lo avrebbe anche (il MAC address del firewall), ma come
scrive skull, di solito non viene fatta una forzatura del genere. :-)


 firewall.
 
No, semmai ti presenti come 192.168.10.253 (leggi il mio proseguio)


 192.168.10.10 e' un Win-Wista allora il ritorno c'e' ?
 
Possibile pasticcio con gli switch? (ipotesi non cosi' peregrina,
ma tant'e'...). Altrimenti, non saprei...


 No, semmai ti presenti come 192.168.10.253 (leggi il mio proseguio)
 
No, il NAT viene eseguito dal mio firewall il quale imposta come source 
address 192.168.1.254.
 
 
Forse non sono stato chiaro, il mio firewall ha due interfacce, una sulla 
lan con indirizzo 192.168.1.254 e una sulla wan con un indirizzo pubblico di 
una HDSL.
 
Il WatchGuard è un altro firewall con due interfacce, una sulla lan con 
indirizzo 192.168.1.253 e uno sulla rete voip con indirizzo 192.168.10.253 
 
Sul mio firewall la rete 192.168.10.x è solo la destinazione di una rotta 
per raggiungere la quale dovrà usare come gateway il watchguard che ha come 
ip sulla stessa mia lan l'indirizzo 192.168.1.253
 
 
-- 
Stefano L.

 ip sulla stessa mia lan l'indirizzo 192.168.1.253
 
Ok.
Se i pc sulla lan hanno solo il gateway di default 192.168.1.254,
qualunque destinazione che non e' su 192.168,1,0/24 viene mandata li'...
Quindi, se la rete 
192.168.10.0/24
 e' raggiungibile tramite il gateway
192.168.1.253, i casi sono due: o istruisci ogni singolo pc con una
route statica tipo ROUTE ADD 192.168.10.0 MASK 255.255.255.0
192.168.1.253, oppure istruisci il firewall 192.168.1.254 per operare un
"bounce" verso 192.168.1.253.
Che ti funzioni operando un NAT (non hai specificato bene come) sul
tuo firewall 192.168.1.254, mi rimane un po' misterioso...
 
Per il vista, non lo so: magari 192.168.1.253 annuncia le subnet
raggiungibili tramite lui con RIP, e vista lo becca mentre XP no,
quien sabe?


 192.168.1.254 e 192.168.1.253 sul firewall per la rete 
192.168.1.0/24
?
 
192.168.1.254 e' l'iterfaccia del MIO firewall collegata alla LAN
 
192.168.1.253 e' l'interfaccia del watchguard collegata alla LAN, un ALTRO 
firewall, quello del fornitore del sistema voip
 
E' chiaro adesso ?
 
 
-- 
Stefano L.

 E' chiaro adesso ?
 
Si', ma manteniamo un po' la calma, grazie.


 quien sabe?
 
Si', forse e' possibile, vista ha un listener RIP:
http://windows.microsoft.com/it-IT/windows-vista/Configuring-multiple-gateways-on-a-network
 


 "bounce" verso 192.168.1.253.
 
Che hai gia' fatto... l'ho capito meglio dalla risposta di skull.
Ipotesi: puo' essere che il wtachguard non sappia che i pacchetti
provenienti da 
192.168.10.0/24
, e che avranno come destinazione un ip
appartenente a 
192.168.1.0/24
, deve restituirli al tuo firewall
192.168.1.254 e non lanciarli sulla lan... Mentre col nat chiaramente
sarebbe obbligato a restituirli al firewall 192.168.1.254...
Spero di star quagliando. :-)


 quien sabe?
 
Ecco appunto, è quello che volevo sapere, cercavo lumi.
 
 
-- 
Stefano L.

 bye G.L.
 
Scusa se ho dato una cattiva impressione, sono calmissimo, sarei un cretino 
a trattar male chi mi da retta.
 
Ripeto scusa, mi accorgo che non ti ho ancora ringraziato ne' te ne' Skull
 
-- 
Stefano L.

 Skull
 
Ok, no problem, bisogna stare attenti al tono su usenet perche' sono
assai facili i fraintendimenti. :-)


  un "bounce" verso 192.168.1.253.
 
Che hai gia' fatto... l'ho capito meglio dalla risposta di skull.
Ipotesi: puo' essere che il wtachguard non sappia che i pacchetti
provenienti da 
192.168.10.0/24
, e che avranno come destinazione un ip
appartenente a 
192.168.1.0/24
, deve restituirli al tuo firewall
192.168.1.254 e non lanciarli sulla lan... Mentre col nat chiaramente
sarebbe obbligato a restituirli al firewall 192.168.1.254...
Spero di star quagliando. :-)
 
 


 sarebbe obbligato a restituirli al firewall 192.168.1.254...
 
Ma l'ICMP echo reply non dovrebbe essere comunque accettato da
192.168.1.1 anche se non proveniente dal 192.168.1.254?
 
 
-- 
In God we trust. All others must bring data
W. E. Deming