Il 30/09/2011 15:34, Giulio Lo Presti ha scritto:
Piuttosto, oltre a vedere che entrano, ti servirebbe sapere se i pacchetti
echo-request escono dall'interfaccia DMZ.
Lo puoi fare attivando un capture tipo:
access-list CAPTURE extended permit icmp host 192.168.50.90 host 172.30.1.1
access-list CAPTURE extended permit icmp host 172.30.1.1 host 192.168.50.90
!
capture CAPT type raw-data access-list CAPTURE interface
"NOME-DELL-INTERFACCIA"
Fai traffico e lo guardi con "show capt CAPT"
provero a fare il capt dei pacchetti, ma non posso farlo
nell'immediato perche devo avere accesso prima.
Scusa, ma non amministri tu il firewall??
Altra cosa da verificare è il NAT, al quale si applica lo stesso discorso
del permit intra-interface.
i nat sono questi c'e qualche errore?
global (outside) 1 10.10.10.2
global (inside) 1 192.168.111.1
nat (dmz) 1 172.16.0.2 255.255.255.0
nat (inside) 1 192.168.0.0 255.255.0.0
static (dmz,outside) 172.16.0.0 172.16.0.0 netmask 255.255.255.0
static (dmz,inside) 172.16.0.0 172.16.0.0 netmask 255.255.255.0
Le macchine che sono nella inside raggiungono il router perchè seguono un
iter corretto, la "anomalia" è che il 192.168.50.90 abbia come defgw il PIX.
Secondo me ti conviene far fare da gw al primo router nella DMZ in quanto se
deve far entrare/uscire un pacchetto da una stessa interfaccia, non fa altro
che fare il suo lavoro.
Il firewall sotto questo punto di vista (ed a ragione) è un po'
"schizzinoso" ;O)
le macchine della inside cioe per me la 192.168.0.0/16 hanno tutte
come gateway il l'interfaccia del pix 192.168.0.1 perche gli altri
router non sono di gestione mia e quindi non posso ne vedere le conf
ne agire sulle conf. so che hanno una default verso 192.168.0.1 e il
bgp per terminare vpls e scambiarsi le rotte varie verso le sedi
remote.
quindi riepilogando, se cerco di pingare dalla macchina 192.168.50.90
il 192.168.0.1 e ok; il 192.168.70.10 e ok; il 172.30.1.1 ko; e cosi
tutti le altre reti remote.
di seguito delle conf che non avevo postato:
access-list out extended permit icmp any any echo-reply
access-list out extended permit icmp any any source-quench
access-list out extended permit icmp any any unreachable
access-list out extended permit icmp any any time-exceeded
route inside 172.30.0.0 255.255.0.0 192.168.70.10 1
access-group out in interface inside
class-map inspection_default
match default-inspection-traffic
!
!
policy-map global_policy
class inspection_default
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect skinny
inspect esmtp
inspect sqlnet
inspect sunrpc
inspect tftp
inspect sip
inspect xdmcp
inspect icmp
inspect netbios
!
service-policy global_policy global
manca qualcosa che mi sfugge :)
Solo "qualcosa"? :O)
Non so chi abbia messo in piedi questa struttura ma, IMHO, ci sono un
bel po' di errori di concetto.
1) Dati i security level dello schema, credevo che la inside (di norma
con sicurezza maggiore) fosse la 172.16.0.0/24 e non quella dove risiede
il PC. E' assurdo che una DMZ (De-Militarized-Zone, quindi poco sicura)
abbia una importanza maggiore a livello di sicurezza rispetto ad una inside.
2) Per i motivi di cui sopra trovo strano vedere una linea di
configurazione come "global (inside) 1 192.168.111.1". E' sempre bene
usare un NAT statico (con "static") se si vuole comunicare con l'inside
piuttosto che un nat dinamico (PAT) come nel caso da te indicato.
Inoltre, l'unica nat che può corrispondere con quel global è "nat (dmz)
1 172.16.0.2 255.255.255.0" di cui è sbagliata la netmask. Quindi, se
nella nmask l'ultimo ottetto arebbe dovuto essere un 255, allora il
discorso del PAT decade. Ma se invece è sbagliato l'ultimo ottetto
dell'IP (forse 0?) allora resta in piedi. Ed in ogni caso più sotto si
vede un "static (dmz,inside) 172.16.0.0 172.16.0.0 netmask
255.255.255.0". Insomma, come dire (ipotizzando che la netmask fosse con
l'ultimo 255): tutti gli host della 172.16.0.0/24 si presentano in
inside con i loro stessi IP, tranne 172.16.0.2 che deve presentarsi come
192.168.111.1. Ci saranno sicuramente delle motivazioni, ma il
ragionamento mi pare "intricato". :O)
3) I ping dalla DMZ verso tutte le altre reti funzionano, perchè i
crismi per acl, routing, nat vengono rispettati. I ping dalla inside
verso la stessa lan funzionano perchè, appunto, i pacchetti viaggiano
sulla stessa lan senza bisogno di GW, ma se devono andare verso altre
reti, in un ambiente "sano" servirebbero: NAT+acl+routing verso la DMZ;
solo routing verso le reti in MPLS. Nel tuo caso, a giudicare dalle acl
elencate (sempre che siano tutte), credo che non ti funzioni neanche il
ping dalla inside verso gli host in DMZ, in quanto nelle acl sulla
inside non accetti icmp di tipo echo-request. Lo stesso motivo potrebbe
essere la causa del ping non riuscito verso il router in MPLS. Prova ad
aggiungerlo, ma abilitando anche il permit intra-interface.
Riguardo al permit intra-interface, anche abilitandolo, ho comunque dei
dubbi che il ping ti funzioni. Sicuramente funzionerebbe se i pacchetti
fossero sulla stessa lan (ma losono! tu dirai...) o meglio, sulla stessa
classe di indirizzi.
Mi spiego meglio, di norma permettere lo stesso traffico in/out sulla
stessa interfaccia è utile nei casi in cui si debba consentire il
traffico tra client remoti, o consentire a client remoti di navigare in
internet tramite il firewall (stando in VPN). L'ambiente più frequente
in questi casi è, ad esempio, far comunicare 2 o più sedi fra loro
quando queste sono collegate in VPN tutte sullo stesso FW. Praticamente
una classica configurazione HUB/Spoke. Però viste le implicazioni di
sicurezza che questo comporterebbe per un FW, per questi ambienti di
solito si usano i router con le configurazioni tipo DMVPN (un tipo di
HUB/Spoke che usa il protocollo NHRP). Ovvio, poi, che dietro ad ogni
router ci sarebbe un FW a fare il suo lavoro :O)
Ma questa è solo teoria che non serve al caso tuo.
In sostanza, io ti consiglierei di rivedere lo schema di rete, perquanto
ti sia possibile.
In alternativa, sempre che ti sia possibile, ti consiglierei aggiungere
un router prima del FW, così che ti faccia lui da GW e sicuramente saprà
come gestire i tuoi pacchetti icmp ;O)
Ciao.
Alessio.
--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP
autenticato? GRATIS solo con Email.it http://www.email.it/f
Sponsor:
Peluche Originali Disney, Simpson, Bugs Bunny, Spongebob... a partire da soli
Euro 9.90!
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=11653&d=2-10
_______________________________________
Articoli CISCO: http://www.areanetworking.it/category/cisco
Cug mailing list
Cug@ml.areanetworking.it
http://lists.ml.areanetworking.it/cgi-bin/mailman/listinfo/cug
Servizio ML offerto da Ehiweb.it - http://www.ehiweb.it/
