Newsgroup: it.comp.reti.locali
Titolo: Problema con firewall Dlink DFL-200

Ciao, ho un problema con la configurazione di un DLink DFL-200.
Attualmente ho un router del mio provider (192.168.0.254) di cui non 
posso modificare la configurazione configurato per fare nat sulla 
sottorete 
192.168.0.0/24
 ed inoltre ha attivato il forward di tutte le 
porte sull'ip privato 192.168.0.1.
Per vari motivi che vi risparmio e' stato aggiunto un secondo router, il 
DLink DFL-200 in oggetto, alla cui porta WAN e' collegato il router del 
provider (la porta wan e' configurata con ip statico 192.168.0.1 e gw 
192.168.0.254) e fa nat sulla sottorete 
192.168.1.0/24
 a cui sono 
collegati i "miei" pc.
Tutto funziona correttamente, ad eccezione che non riesco a configurare 
il firewall del dlink (il secondo router) in modo da accettare le 
connessioni sulla porta 22 ed inoltrarle ad un pc della rete "interna" 
(192.168.1.x).
Il virtual server e' configurato cosi' come tutte le altre voci 
relative, nel firewall ho le regole
WAN->LAN e LAN->WAN configurate per accettare connessioni da "any" verso 
"any" per qualsiasi protocollo ma nel log del malefico firewall dlink, 
quando provo a connettermi da un pc "esterno" all'ip pubblico fornitomi 
dal provider vedo:
<5> EFW: DROP: prio=2 rule=dropall-final action=drop recvif=WAN 
srcip=151.21.x.x destip=192.168.0.1 ipproto=TCP ipdatalen=40 
srcport=48509 destport=22 tcphdrlen=40 syn=1
... e il mio client che prova a connettersi in ssh rimane catatonico per 
un po' prima di desistere (tipico sintomo da porta stealth).
Idee? Non riesco a capire perche' il dlink ignori la regola WAN->LAN e 
continui a cassare le connessioni in ingresso, non e' che gli da 
fastidio il fatto che la wan sia su una classe di ip privata (sebbene in 
una sottorete diversa dalla LAN e di conseguenza non dovrebbe essere 
"infastidito" dalla cosa)...
Ogni idea e' ben accetta.
Ciao e grazie
Luca

 wrote:
Ciao
Verifica qui se il portforward che hai fatto è corretto (sia udp che
tcp): 
http://portforward.com/english/routers/port_forwarding/Dlink/DFL-200/SSH.htm
Stai facendo le prove da un client connesso ad un'altra adsl? non lo
puoi fare da locale.
Ciao

 puoi fare da locale.
certo, le prove le faccio da una adsl "esterna" ma purtroppo il firewall 
ignora le regole da me impostate...
Ciao
Luca

 srcport=48509 destport=22 tcphdrlen=40 syn=1
qualcosa non mi torna (oppure � come dico io e la 22 viene usata dal
router): hai come destip il router stesso e non un PC della lan.
Non � che questo � il log del primo router invece che del dlink?
-- 
MirkoB.   
ne...@bsi-net.it
Motoretta BMW R1150R Nera...
L'indirizzo em@il non � da considerarsi pubblico,
ma utilizzabile solo per temi inerenti il NG corrente.

 Non � che questo � il log del primo router invece che del dlink?
purtroppo sul primo router non ho nessun tipo di accesso (quindi non 
potrei postare il log nemmeno volendo), per la porta anche mettendo il 
tutto sulla 22 il risultato non cambia, stesso identico messaggio (porta 
a parte ovviamente... ;)
Ciao e grazie
Luca

 a parte ovviamente... ;)
c'� qualcosa che non va. Non conosco i firewall dlink ma quel log dice
che il sorgente � il 151.21, che la destinazione � il tuo firewall e
che viene bloccato dalla regola dropall-final (almeno cos� mi pare di
capire). 
Verifica questa regola dropall-final cosa dice e occhio anche
all'ordine delle regole (magari sei convinto che l'ordina sia dettato
dalla posizione e invece dipende dall'ID)... potrebbe essere che tu
abbia fatto le regole al disotto della regola che blocca.


 capire).
Tale e' la regola predefinita di blocco dei NetDefend, che viene 
applicata quando non avviene il match con altre regole di allow/deny
definite dall'utente.
In tali casi conviene procedere :
==
1. Verificando la versione firmware in uso = sono noti problemi di
   gestione firewall con vecchie versioni precedenti alla 1.34 per tale
   apparato.
2. Impostando in WAN->LAN e WAN->DMZ regole realmente prioritarie di
   allow per il traffico SSH e SSH/in con SRC 0.0.0.0 e DST 0.0.0.0 ,
   e controllare che risultino correttamente Activated in seguito al
   reboot del DFL-200.
3. Effettuando le verifiche prima con Host associati all'interfaccia 
   LAN in NAT M-1 e successivamente con Host in DMZ con analoga
   impostazione.
Ulteriore suggerimento e' quello di abilitare l'Audit Logging nelle
impostazioni del DFL-200 (perlomeno durante le verifiche), onde tener
traccia di tutte le operazioni associate alle connessioni.
-- 
|� \/� | /�\ /�__/�__|<|> *FAX/Mail Server  : 
+39 - 02700426582
 <|
|�|\/|�|/�_�\|(__\__ \<|> *Casella Vocale   : 
+39 - 0230312251
  <|
|_|  |_/_/ \_\___|___/<|> *FAQ ITGF 
http://plany.fasthosting.it
 <|
|>- RST - Plany/MACS -<|> *FAQ GCN  
http://faq.news.nic.it/
 ____<|

 traccia di tutte le operazioni associate alle connessioni.
Ok, procedo...
Per ora... grazie mille!
Ciao, Luca

 posto di lasciare vuoto?
Crea una regola in entrambi i set (WAN->LAN e WAN->DMZ) del seguente
tipo :
==
------------------------------------------------------------------------
Name .................: allow_ssh
Position .............: 1
Action ...............: Allow
Source Nets ..........: 0.0.0.0
Destination Nets .....: 0.0.0.0
Service ..............: Custom TCP
Custom source ports ..: lascia vuoto
... destination ports : 22
Schedule .............: Always
Intrusion IDS/IPS ....: lascia disattivato (almeno per le verifiche)
------------------------------------------------------------------------
Quindi applicala (cliccando su Apply) & attivala (cliccando su Activate)
in modo che venga memorizzata al riavvio.
La regola di Port-Mapping e' semplice, considerando 
p.es
. di impostarla
in associazione all'IP 192.168.1.200 della subnet LAN :
==
------------------------------------------------------------------------
Name .................: port_ssh
Source Nets ..........: 0.0.0.0
Destination IP .......: 192.168.0.1
Service ..............: Custom TCP
Custom source ports ..: lascia vuoto
... destination ports : 22
... pass to port .....: 22
Pass to ..............: 192.168.1.200
Schedule .............: Always
Intrusion IDS/IPS ....: lascia disattivato (almeno per le verifiche)
------------------------------------------------------------------------
Ovviamente anche per la regola di port-mapping e' necessario procedere
prima con Apply & poi con Activate = il solo Apply inserisce infatti la
regola, ma questa viene attivata solo in realta' dopo il riavvio del
dispositivo (successivo al click su Activate).
A quel punto effettua le verifiche di port-mapping, puntando prima ad
un host nat-ted & associato alla subnet dell'interfaccia LAN -> in caso
ancora di KO ripeti la prova, puntando stavolta ad un host nat-ted &
associato alla subnet dell'interfaccia DMZ (e.g. 
192.168.2.1/24
) .
La verifica con variazione di puntamento LAN/DMZ per il port-mapping
serve ad acclarare eventuali differenze di gestione dei filtri (ved.
voci nel log con Audit abilitato) in base alle connessioni in ingresso
lato WAN.


 lato WAN.
Risolto!
L'errore (mio) derivava dall'aver interpretato male il "Custom source 
ports" del port mapping (solo ora ho capito che e' la porta da cui 
*origina* la connessione, pensavo fosse quella di destinazione 
sull'interfaccia wan del mio router).
Grazie 1000!
Ciao
Luca

 Luca
Non avevi visto il linck che ti ho postato allora ;-)
Ciao

 Non avevi visto il linck che ti ho postato allora ;-)
che poi confondere source con destinazione ce ne vuole... :-)
