ARGOMENTO:

Salve,
sto qui a porre un problema riguardante l'applicazione delle acl finalizzate al blocco/permesso del traffico sulle interfaccie quando le stesse interfaccie siano caratterizzate anche come interfacie inside oppure outside.
Primo caso: acl inbound su interfaccia inside, i questo caso il messaggio arriva con un indirizzo ip mittente che probabilmete se soddisfa le altre condizioni definite nel nat verra' modificato in un indirizzo inside global, la domanda e': su quale indirizzo andra a fare match l'acl inbound?
secondo caso:acl outbound su interfaccia outside, anche in questo caso come per le inbound sulle inside il nat operera' una modifica dell'ip sorgente e quindi sorge la questione di definie su quale indirizzo mittente operera' lacl outbound impostata sulla interfaccia outside.
Comunque senza fare tutti i casi la cosa qualificante e' il notare che la combinazione dei due trattamenti di nat (anche solo statico) ed acl inbound sulle interfaccie inside ed outbound sulle interfaccie outside potrebbe avere effetti differenti a seconda se al messaggio sia applicato prima il processo di nat o se prima venga applicato quello di acl, intendiamoci quando dico acl intendo quelle finalizzate al controllo del traffico.
Quindi come funziona, in che modo e' sequenzializzata e disciplinata l'applicazione dei due processi?
Ovviamente questo problema e' di carattere generale e riguardera' anche altri trattamenti che avvengono sui vari router e che "perturbano" a seconda della sequanzialita' di applicazione dei vari processi, immagino che il nat influenzi anche una eventuale QoS che matchi sugli ip origine e destinazione, e comunque la mia questione e' evidente e di carattere specifico per ACL con NAT ma e' anche una questione di carattere generale, quali sono le linee guida generali tenute per la razionalizzazione delle interazioni tra processi all'interno dei router?
Cio'e in linea generale quale e' la chiave unica che consente di definire cme vanno le cose quendo piu'processi differenti interagiscono sullo stesso messaggio ed utilizano lo stesso messaggio come dato di ingresso?

Buon lavoro

La problematica è seria e fondamentale avere le idee chiare, si pone per tante funzionalità, qui la tabella riassuntiva dell'ordine delle operazioni sull'interfaccia.

Sinteticamente,

inside->outside prima avviene il routing, e se l'interfaccia in entrata è una nat inside e quella di uscita una nat outside allora si innesca anche il nat

outside->inside prima si innesca il nat, poi il routing

Le ACL di filtro vengono sempre controllate prima del NAT, quindi questo vuol dire che vanno sempre scritte tenendo conto degli indirizzi nel pacchetto ip che arriva sull'interfaccia.





In questo ordine delle operazioni c'è poco di standard e alcune implementazioni possono avere ordini differenti, ad esempio sui Firewall Cisco ASA dalla versione 8.3 il nat si innesca prima delle ACL di interfaccia.

Rileggendo oggi il post mi e' venuto un piccolo dubbio sulla affermazione "Le ACL di filtro vengono sempre controllate prima del NAT, quindi questo vuol dire che vanno sempre scritte tenendo conto degli indirizzi nel pacchetto ip che arriva sull'interfaccia." con il termine arriva intendi sia i pacchetti che arrivano "elettricamente" all'interfaccia quindi i pacchetti ai quali si applicano le ACL inbound e con lo steso termine (arriva) intendi indicare i pacchetti in uscita cioe' quelli che arrivano dall'interno che il processo di routing istrada verso una certa interfaccia in uscita ed ai quali si debba eventualmente applicare una ACL outbound?
Io ritengo che tu intendessi cosi e che quindi questa seconda categoria di pacchetti in uscita operi prima il processo di selezione delle ACL e poi il nat, e per meglio dire in maniera piu' estesa che il processo di selezione acl opera sugli indirizzi inside local ed outside local, spero di essermi spiegato con chiarezza, e' cosi?

Sono insegnante di sistemi in un itis indirizzo informatico e uso costantemente Packet Tracer. Ho un dubbio su questa interazione tra acl e nat perchè utilizzando la versione Student 6.2 non mi risulta durante i test. Ho proposto un esercizio con delle Vlan, un nat Overloading e una serie di ACL che agiscono sulle Vlan e su dei server ftp e di post. Dai test effettuati sembrerebbe che le regole ACL sulle Vlan vengano bypassate fino ad arrivare alla regola finale permit any any. Eppure ti posso assicurare le regole sono corrette e semplici (si tratta di bloccare una rete della vlan diretta al server ftp, quindi molto semplice). Il pacchetto però passa.
Potresti dirmi se ho capito male o se con le vlan forse la situazione è diversa (ma non credo, sono sempre reti)?
Grazie in anticipo

Ti allego il file (il controllo è che la VLAn 50 non deve utilizzare il servizio ftp)

Salve Angela,
e benvenuta sul forum

Confermo anzitutto che l'utilizzo delle VLAN non implica differenze nell'utilizzo delle ACL, come pure confermo che le ACL di filtro vengono effettivamente visionate PRIMA di effettuare NAT. Ho controllato le regole scritte nell'ACL 101 e mi viene un dubbio su come tu stia testando l'ACL stessa. Potrei chiedere che tipo di test viene effettuato per capire che il traffico effettivamente passi venendo tradotto?
Lo chiedo perchè se il test venisse effettuato con un ping (ICMP) ed il traffico passasse, non ci sarebbe nulla di strano, anzi... il problema esisterebbe se venisse bloccato

Un saluto, Jody

Grazie Jodi,

faccio il test in simulazione, per vedere il contenuto dei pacchetti che viaggiano e in particolare filtro solo il pacchetto ICMP per non avere molto traffico ....
dall'analisi del pacchetto sul router prima del nat mi dice che incontra l'ACL 101 con la regola permit any any ... come dovrei fare allora il test per verificare l'esattezza dell'esercizio?

Grazie

Salve di nuovo Angela

Il punto è il seguente: rispetto alle regole dell'ACL 101 (che riporto di seguito), l'ICMP trova correttamente match sull'ultima riga del permit ip any any, in quanto i blocchi previsti per FTP, SMTP e POP3 riguardano protocolli diversi da quello utilizzato per il test (ovvero l'ICMP).

access-list 101 deny ip 192.168.40.0 0.0.0.255 192.168.50.0 0.0.0.255
access-list 101 deny ip 192.168.40.0 0.0.0.255 192.168.60.0 0.0.0.255
access-list 101 deny tcp 192.168.40.0 0.0.0.255 host 198.198.198.1 eq ftp
access-list 101 deny tcp 192.168.50.0 0.0.0.255 host 198.198.198.1 eq ftp
access-list 101 deny tcp 192.168.40.0 0.0.0.255 host 197.197.197.1 eq pop3
access-list 101 deny tcp 192.168.40.0 0.0.0.255 host 197.197.197.1 eq smtp
access-list 101 deny tcp host 192.168.50.1 host 197.197.197.1 eq smtp
access-list 101 permit tcp host 192.168.50.1 host 197.197.197.1 eq pop3
access-list 101 deny tcp 192.168.50.0 0.0.0.255 host 197.197.197.1 eq pop3
access-list 101 deny tcp 192.168.50.0 0.0.0.255 host 197.197.197.1 eq smtp
access-list 101 deny tcp 192.168.60.0 0.0.0.255 host 197.197.197.1 eq smtp
access-list 101 deny tcp 192.168.60.0 0.0.0.255 host 197.197.197.1 eq pop3
access-list 101 permit ip any any

Le entry che bloccherebbero l'ICMP (in quanto relative a tutta la suite IP - che comprende appunto anche l'ICMP), sono le prime, ovvero quelle che vietano tutto il traffico dalla rete 192.168.40.0/24 verso la 192.168.50.0/24 e la 192.168.60.0/24, che però non trovano match quando il traffico è diretto verso una destinazione differente.

Se posso permettermi credo che la confusione nasca dall'assimilazione dell'ICMP ad una sorta di protocollo "jolly", mentre per testare un'ACL si deve generare traffico relativo appunto ai protocolli dichiarati nelle ACEs (ad esempio, per la destinazione 198.198.198.1 va generato traffico FTP dalla 192.168.40.0/24 o dalla 192.168.50.0/24: in tal modo il blocco nell'ACL impedirebbe al pacchetto di venire ruotato, e dunque il NAT non entrerebbe in gioco. Mentre invece l'eventuale traffico FTP proveniente dalla 192.168.60.0/24 di nuovo troverebbe match con il permit ip any any e verrebbe tradotto).

Spero sia più chiaro,
un saluto

Jody

Grazie Jodi,

sei stato chiarissimo.
Saluti e grazie ancora dell'assistenza che puntualmente ci date in questo forum.

Angela

Figurati, sempre un piacere

Alla prossima!