Re: [Cug] pix and icmp
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
Re: [Cug] pix and icmp
Il giorno 29/set/2011, alle ore 22.54, Giulio Lo Presti ha scritto: Ciao, ciao a tutti, ho un dubbio sul funzionamento dell' icmp attraverso un pix ver 7.0. in allegato trovate il disegno con gli apparati e le lan. se pingo dal pc con indirizzo 192.168.50.90(che ha come default il pix) verso il router con indirizzo 172.30.1.1 ricevo richiesta scaduta... se pingo da un pc con indirizzo 172.16.0.10 sempre verso lo stesso 172.30.1.1 il ping va a buon fine. il pix ha le acl configurate sulle interfacce del tipo acl out extended permit icmp any any e inoltre icmp permit outside; inside; dmz. ho provato percaso se poteva essere il permit intra interface. ma niente mi sa che e un qualcosa riguardante il proxy arp.. ma ho letto che e abilitato di default... nelle acl hai anche access-list ___ extend permit icmp any any echo-reply? Potresti postare la conf del pix? ___ 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/
Re: [Cug] pix and icmp
Il giorno 29/set/2011, alle ore 22:54, Giulio Lo Presti ha scritto: ciao a tutti, ho un dubbio sul funzionamento dell' icmp attraverso un pix ver 7.0. in allegato trovate il disegno con gli apparati e le lan. se pingo dal pc con indirizzo 192.168.50.90(che ha come default il pix) verso il router con indirizzo 172.30.1.1 ricevo richiesta scaduta... se pingo da un pc con indirizzo 172.16.0.10 sempre verso lo stesso 172.30.1.1 il ping va a buon fine. il pix ha le acl configurate sulle interfacce del tipo acl out extended permit icmp any any e inoltre icmp permit outside; inside; dmz. ho provato percaso se poteva essere il permit intra interface. ma niente mi sa che e un qualcosa riguardante il proxy arp.. ma ho letto che e abilitato di default... perche non ricevo echo reply??? p.s. se abilito icmp trace sul pix vedo arrivare sul log echo ma non echo reply Grazie Giulio pix.jpeg___ 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/ Ciao, domanda scontata: hai controllato il routing? Federico Ciulla Network Administrator CCNA, CCDA, CCNP, FCNSA Mobile: 3488680699 E-Mail: federico.ciu...@gmail.com ___ 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/
Re: [Cug] pix and icmp
Ciao, domanda scontata: hai controllato il routing? si il routing e corretto almeno credo c'e una rotta statica per la network 172.30.0.0/16 192.168.70.10 nelle acl hai anche access-list ___ extend permit icmp any any echo-reply? Potresti postare la conf del pix? si nelle access list c'e echo reply e funziona da tutte le altre interfacce regolarmente. cerchero di postare la configurazione del pix ma essendo un cliente devo prima chiedere l'accesso. altri suggerimenti? potrebbe essere necessario mettere tutte le /24 invece della /16? grazie ___ 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/
Re: [Cug] pix and icmp
Il 29/09/2011 22:54, Giulio Lo Presti ha scritto: p.s. se abilito icmp trace sul pix vedo arrivare sul log echo ma non echo reply Grazie Giulio 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 Se vedi pacchetti diretti al router, allora il firewall ha fatto il suo ed il problema è un altro (ma ne dubito). Inoltre, credo che il permit intra-interface sia necessario in quanto di norma PIX/ASA non lasciano entrare ed uscire lo stesso traffico dalla medesima interfaccia. Altra cosa da verificare è il NAT, al quale si applica lo stesso discorso del permit intra-interface. 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) Ciao. -- 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: Prova il servizio di Email Marketing di Email.it, incrementi la visibilita' della tua azienda e trovi nuovi clienti Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=11847d=30-9 ___ 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/
