Newsgroup: it.comp.reti.cisco
Titolo: [PIX501] Apertura porte: alcune ok altre no

Ciao,
sto cercando di aprire una porta sul nostro firewall Cisco PIX 501 per
permettere il traffico FTP.
Avevo già aperto una porta in passato per far funzionare un webservice
ed era andato tutto correttamente.
Adesso ci sto riprovando ma non pare funzionare.
I comandi che ho usato sono
####################
access-list acl-outside-services permit tcp any interface outside eq
www
access-list acl-outside-services permit udp any interface outside eq
2343
access-list acl-outside-services permit tcp any interface outside eq
ftp
access-list acl-outside-services permit udp any interface outside eq
21
static (inside,outside) tcp interface www 192.168.10.82 8080 netmask
255.255.255.255 0 0
static (inside,outside) udp interface 2343 192.168.10.241 2343 netmask
255.255.255.255 0 0
static (inside,outside) tcp interface ftp 192.168.10.241 ftp netmask
255.255.255.255 0 0
static (inside,outside) udp interface 21 192.168.10.241 21 netmask
255.255.255.255 0 0
access-group acl-outside-services in interface outside
####################
Di tutte queste direttive l'unica che funziona è relativa alla porta
del webservice (porta 80 traslata in 8080).
Le altre non rispondono.... (anche se, non uscendo dalla LAN, i
servizi li raggiungo).
Avete idea del perché succede questo?


Domanda ovvia, dato che con il PIX non si sa mai...
Hai flashato la configurazione?
Perché hai la porta 21/udp replicata in una seconda istruzione? A che ti 
serve?
Io ho una configurazione diversa:
fixup protocol ftp 21
access-list acl_in permit tcp any host IP_PUBBLICO eq ftp
static (inside,outside) tcp IP_PUBBLICO ftp SERVER_FTP ftp netmask 
255.255.255.255 0 0
e a me funziona...

 e a me funziona...
Forse non devo utilizzare 'access-group'?
Ho poca confidenza con la sintassi Cisco; la sto imparando e ho usato
'access-group' seguendo alcuni tutorial sul port-forwarding, piuttosto
che per una cognizione di causa effettiva.
Ciao,
Pictor

 Pictor
Access-group ce l'ho anch'io.
Premetto che configuro da terminale, quindi magari ho qualche finezza in 
più.
Secondo me, se non hai il fixup non funziona. Anche se il manuale dice 
il contrario...
Togli 21/udp.
Altro non saprei, ho notato che le configurazioni fatte tramite PDM e 
tramite terminale sono differenti, è dal 2005 che non uso PDM, e non 
ricordo se Save è condizione sufficiente per attivare le modifiche.

 Forse non devo utilizzare 'access-group'?
l'access-group ti serve per far capire al pix su quale interfaccia
applicare l'ACL! quindi... ti serve :-)
Ciao
Daniele

 ricordo se Save è condizione sufficiente per attivare le modifiche.
Sì, non sopporto questa inconsistenza tra i due metodi di
configurazione. E' una delle note più dolenti di Cisco, imho.
Comunque incollo qua sotto la config:
Building configuration...
: Saved
:
PIX Version 6.3(5)
interface ethernet0 auto
interface ethernet1 100full
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password /xxxxxxxxxxxx encrypted
passwd xxxxxxxxxxxxx encrypted
hostname pixfirewall
domain-name 
ciscopix.com
clock timezone CEST 1
clock summer-time CEDT recurring last Sun Mar 2:00 last Sun Oct 3:00
fixup protocol dns maximum-length 512
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
fixup protocol pptp 1723
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol sip 5060
fixup protocol sip udp 5060
fixup protocol skinny 2000
fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol tftp 69
names
name 192.168.10.0 Base_LAN
name 192.168.20.0 LAN_20
object-group service mysql tcp-udp
  description MySQL Database service group. (check if UDP traffic is
needed)
  port-object range 3306 3306
access-list outside_access_in permit icmp any any echo-reply
access-list outside_access_in permit icmp any any traceroute
access-list outside_access_in permit icmp any any timestamp-reply
access-list outside_access_in permit icmp any any information-reply
access-list outside_access_in permit icmp any any mask-reply
access-list outside_access_in remark If you drop 11 (source-quench
credo):
access-list outside_access_in remark
access-list outside_access_in remark a) outbound traceroute won't work
(if you don't use traceroute, then
access-list outside_access_in remark you probably should drop type
11), and
access-list outside_access_in remark
access-list outside_access_in remark b) routing loops could go
unreported; this shouldn't really matter
access-list outside_access_in remark unless your network is
sufficiently complex that routing loops are a
access-list outside_access_in remark realistic possibility.
access-list outside_access_in permit icmp any any source-quench
access-list outside_access_in remark Blocca eMule, porta 4662
access-list outside_access_in deny tcp any any eq 4662
access-list outside_access_in deny ip any any
access-list inside_outbound_nat0_acl permit ip any 192.168.10.250
255.255.255.254
access-list inside_outbound_nat0_acl permit ip any 192.168.10.224
255.255.255.240
access-list inside_access_in permit ip Base_LAN 255.255.255.0 any
access-list acl-outside-services permit tcp any interface outside eq
www
access-list acl-outside-services permit udp any interface outside eq
2343
access-list acl-outside-services permit tcp any interface outside eq
ftp
pager lines 24
logging on
logging trap debugging
logging host inside 192.168.10.xx
icmp permit any outside
mtu outside 1500
mtu inside 1500
ip address outside <IP_PUBBLICO> 255.255.255.xxx
ip address inside 192.168.10.254 255.255.255.0
ip verify reverse-path interface outside
ip audit info action alarm
ip audit attack action alarm
ip local pool vpnPool 192.168.10.250-192.168.10.251
pdm location Base_LAN 255.255.255.0 inside
pdm location 192.168.10.224 255.255.255.240 outside
pdm location 192.168.10.250 255.255.255.254 outside
pdm location 67.215.xx.xxx 255.255.255.255 outside
pdm location 81.174.xx.xxx 255.255.255.255 outside
pdm location 192.168.10.xx 255.255.255.255 inside
pdm location 192.168.10.20 255.255.255.255 inside
pdm location 192.168.10.82 255.255.255.255 inside
pdm location LAN_20 255.255.255.0 inside
pdm location 192.168.10.241 255.255.255.255 inside
pdm logging informational 100
pdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 0 access-list inside_outbound_nat0_acl
nat (inside) 1 Base_LAN 255.255.255.0 0 0
static (inside,outside) tcp interface www 192.168.10.82 8080 netmask
255.255.255.255 0 0
static (inside,outside) udp interface 2343 192.168.10.241 2343 netmask
255.255.255.255 0 0
static (inside,outside) tcp interface ftp 192.168.10.241 ftp netmask
255.255.255.255 0 0
access-group acl-outside-services in interface outside
route outside 0.0.0.0 0.0.0.0 188.xxx.xxx.241 1
route inside LAN_20 255.255.255.0 192.168.10.16 1
timeout xlate 0:05:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225
1:00:00
timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout sip-disconnect 0:02:00 sip-invite 0:03:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server TACACS+ max-failed-attempts 3
aaa-server TACACS+ deadtime 10
aaa-server RADIUS protocol radius
aaa-server RADIUS max-failed-attempts 3
aaa-server RADIUS deadtime 10
aaa-server LOCAL protocol local
http server enable
http 81.174.13.208 255.255.255.255 outside
http Base_LAN 255.255.255.0 inside
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
sysopt connection permit-ipsec
sysopt connection permit-pptp
sysopt connection permit-l2tp
isakmp nat-traversal 20
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption 3des
isakmp policy 10 hash md5
isakmp policy 10 group 2
isakmp policy 10 lifetime 86400
vpngroup WESTCISCO address-pool vpnPool
vpngroup WESTCISCO idle-time 1800
vpngroup WESTCISCO password ********
telnet 192.168.10.xx 255.255.255.255 inside
telnet timeout 5
ssh timeout 5
console timeout 0
vpdn group PPTP-VPDN-GROUP accept dialin pptp
vpdn group PPTP-VPDN-GROUP ppp authentication chap
vpdn group PPTP-VPDN-GROUP ppp authentication mschap
vpdn group PPTP-VPDN-GROUP ppp encryption mppe auto
vpdn group PPTP-VPDN-GROUP client configuration address local vpnPool
vpdn group PPTP-VPDN-GROUP pptp echo 60
vpdn group PPTP-VPDN-GROUP client authentication local
vpdn username .......................
vpdn username .......................
vpdn username .......................
vpdn enable outside
dhcpd address 192.168.10.xx-192.168.10.xx inside
dhcpd dns 208.67.222.222 8.8.8.8
dhcpd wins 192.168.10.xx
dhcpd lease 3600
dhcpd ping_timeout 750
dhcpd domain <DOMINIO>
dhcpd auto_config outside
terminal width 80
Cryptochecksum:9884d9asdasda123asd123e71070fca8

 Daniele
Ciao

 sicuro al 100% ^_^
Eè che i pix in fondo gli odiamo un pò tutti quanti ;-)

Mi sono anche assicurato che non fosse un problema di chiusura delle
porte lato provider (centrale oppure router ADSL, a cui non ho
accesso)..... ma nisba: ho un ip pubblico e non vengono bloccate le
connessioni in ingresso.
C'è qualcosa di sbagliato nella mia configurazione?
Devo riavviare il firewall per renderle attive? (ma mi pare assurdo)
C'è un modo per monitorare/debuggare le connessioni in ingresso, in
modo da vedere almeno se il pacchetto di richiesta arriva sulla porta
giusta e se viene bloccato?
Ci sto veramente perdendo troppo tempo ed è frustrante non capire se e
cosa sto sbagliando... :-(

 Eè che i pix in fondo gli odiamo un pò tutti quanti ;-)
Beh, "odiare" è riduttivo direi :-P
Lo torturerei con un apriscatole!!
Possibile che (teoricamente) faccio le cose giuste eppure non funziona
comunque? ... :-(


Se ancora non ti funziona, io ho esaurito i suggerimenti. Posso solo 
consigliarti di abbandonare PDM, usare il terminale ed imparare la 
pallosissima tecnica di configurazione di PIX via TTY, e di abilitare il 
debug, giusto per vedere se si nota qualcosa.

 comunque? ... :-(
prova così:
sostituisci questo: static (inside,outside) tcp interface ftp
192.168.10.241 ftp netmask 255.255.255.255 0 0
con questo: static (inside,outside) tcp interface ftp 192.168.10.241
netmask 255.255.255.255 0 0
poi non capisco bene questa acl: access-list acl-outside-services
permit tcp any interface outside eq ftp
io la farei così: access-list acl-outside-services permit tcp any host
192.168.10.241 eq ftp
puoi comunque monitorare le sessioni facendo da terminale show access-
list; a fianco di ogni riga c'è un contatore che si incrementa ad ogni
sessione nuova. Ti conviene espletare sempre alla fine delle acl una
acl di deny any cosicchè tu possa vedere se il pacchetto viene
droppato.
Bye
Daniele

 droppato.
Ma dove posso vedere quali pacchetti vengono droppati?
Comunque provando su un altro computer/IP_locale (lo chiamo Server2),
con un server in ascolto sulle porte interessate, tutte le connessioni
funzionano!!!
Quindi le porte aperte ci sono sul PIX!
Ho però provato a riportare la stessa configurazione modificando
solamente l'IP, impostando le 'static' verso il server locale
corretto......
...... e continua a collegarmisi al Server2, nonostante abbia rimosso
dalla configurazione qualunque riferimento ad esso ed abbia
reimpostato la static e l'apertura delle porte verso il Server1
(quello su cui effettivamente deve andare tutto)!
E' come se ci fosse una sorta di 'cache' o di memoria della vecchia
configurazione, e non si aggiorna...... non capisco! O_O
Come faccio a fargli refreshare la configurazione forzatamente?

La configurazione mi pare corretta.
Azzardo un'ipotesi assurda: che ci sia una sorta di "incompatibilità"
tra il NAT statico di una porta UDP e quello di una porta TCP.
E proverei a rimuovere (temporaneamente) il NAT della UDP 2343
Claudio

 Come faccio a fargli refreshare la configurazione forzatamente?
prova con clear xlate, male che va riavvialo. Comunque se la prova del
9 è andata a buon fine, meglio così :-) Facci sapere se sei riuscito a
scacciar ei fantasmi da sto pix!!
D


Se così fosse però mi aspetterei che che cambiando l'IP di
destinazione continui a non collegarsi, o che anche la porta 80 aperta
non lasci passare traffico.
Invece in questi due casi funziona.
E' assurdo:
su un IP di prova (Server2) riesce a collegarsi passando attraverso il
firewall.
sull'IP di destinazione reale (Server1, una centralina della National
Instruments) invece tramite il firewall non ce la fa, mentre provando
internamente alla LAN (senza passare dal firewall) la connessione va a
buon fine.
Non riesco quindi a capire quanto il problema sia del firewall o della
centralina....


Mmmmh, non so se per il "clear xlate" o se per il riavvio, comunque il
Pix s'è ripreso. Non saprei dire che fosse successo.
Ho fatto altre prove..... e alla fine il traffico passa.
Peccato che la centralina su cui gira il server FTP sembra non
digerire bene le connessioni da internet.... :-(
Creo la regola, il traffico passa; se sull'IP abilitato alla porta 21
ci metto un PC con un FTP server funziona anche dalla WAN; se ci metto
la centralina invece non riesce neanche a collegarsi.....
.... che disdetta :-(

 .... che disdetta :-(
cosa intendi per centralina?


La centralina è una specie di PLC che programmiamo e su cui girano
diversi servizi.
Alla fine è come un PC.
E con mia somma *incaxxatura* ho scoperto che ne avevano configurato
il gateway con due cifre invertite: x.x.x.245 anziché x.x.x.254.
Quindi tutte le richieste che arrivavano da IP esterni non ricevevano
risposta perché il pacchetto veniva rimandato indietro all'indirizzo
di gateway sbagliato!!
Avrei dovuto controllarlo tra le prime cose ... :-/

 Avrei dovuto controllarlo tra le prime cose ... :-/
meglio così dai :-)

 meglio così dai :-)
Tanto ora c'ho da sbatterci la testa per capire come si apre un range
di porte! O_O
Aperto e funzionante l'FTP, adesso devo aprire le porte
UDP: 2343   ..... facile :-)
UDP: 6000-2010 ...... beh, facile.... ;-)
TCP: 59110 -> 59120 ............... ????  :-(
In pratica il range parte dalla porta 59110 e incrementa di uno per
ogni applicazione che gira sulla centralina.
Tramite il PDM ho definito un "object-group" corrispondente al range.
Sulla "access-list" riesco ad applicarla..... ma sulla "static" come
lo uso?
Se provo
    static (inside,outside) tcp interface object-group
NI_NetworkSharedVariables 192.168.10.241 object-group
NI_NetworkSharedVariables netmask 255.255.255.255 0 0
mi dice che non va bene.
Anche qua conviene utilizzare il 'fixup protocol'?
Sono sempre più nel pallone!! :-D