> 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. > 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. 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 :) > > -- > 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=11847&d=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/ > > _______________________________________ 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/
