Newsgroup: it.comp.reti.locali
Titolo: Zyxel FTP dietro NAT su porta alternativa

Ciao,
Ho uno zyxel 662HW, con gestione delle DMZ e tutto quanto, uso nat full
featured, e ho un problema. Ho necessita` di buttare su un server ftp
su porta 2424. Ora, mi sono accorto che da LAN riesco a accedere 
tranquillamente al server, mentre da internet no. Questo perche` il
connection tracking dello zyxel sembra attivarsi sono quando si usa
la porta 21! Chiedo lumi, c'e` la possibilita` di fargli capire allo
zyxel che la porta 2424 deve trattarla come la 21? Ora il server ftp usa
la modalita` passiva, ovvero e` il client che apre il canale dati,
potrei risolvere usando la modalita` attiva, in teoria o sbaglio?
Purtroppo pero` potra` capitare qualche client nattato a sua volta,
quindi non cambierebbe niente.
Any solutions?
Ciao e grazie
-- 
err: signature too big

 Ciao e grazie

 questo router?) forse potresti aiutarmi :p
E' un buon routerino secondo me e` un modello abbastanza completo per
uso SOHO, forse lo sto snobbando un po visto che sono abituato ad altri
prodotti ben piu` sofisticati. A casa ho un 660HW (penso sia uguale
tranne la dmz), e mi trovo benone.
Ciao


Ho il tuo stesso problema, ma con un altro router.
http://www.3com.com/prod/it_IT_EMEA/detail.jsp?tab=features&sku=3CRWDR100A-72
Richiedendo la connessione ftp all'indirizzo ip pubblico il sever risponde
con la richiesta di utente e password, inserendole, al client non perviene
il listato del contenuto del server ftp.
Indirizzo ip del server 87.3.... server 192.168.1.10, client 192.168.1.11.
Se mi collego con il client dalla stessa rete ma eseguendo il collegamento
con ftp 87.3...., il tutto funziona, ma se sposso il cliente in un'altra
rete, il collegamente si comporta come descritto sopra.
Se controllo il tutto con uno sniffer, posso notare che il server cerca di
rispondere al client 192.168.1.11 e non al suo indirizzo ip pubblico.
Non sono riuscito a capire se è un problema che bisogna mettere il server in
una DMZ o settare correttamente il server ftp.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 deve trattarla come la 21?
L'ALG FTP dello ZyXel lavora infatti in modalita' predefinita sulla
porta 21 -> tuttavia i firmware per la serie 662HW successivi a maggio
2005 hanno corretto i problemi di gestione FTP su non-standard port,
introducendo anche la possibilita' di modificare correttamente il
dynamic ALG FTP (in modo da non inibire sessioni su porte non standard).
Qualora l'aggiornamento firmware e l'eventuale modifica ALG non fossero
risolutive, potresti impostare il server FTP in LAN sulla porta 21 come
control port e regolare il resto lato port-forward.
In sintesi definiresti le seguenti regole di traduzione NAT/PAT :
==
- WAN 2424 --> LAN 21
- WAN 2423 --> LAN 20
- WAN PASV Port-range --> LAN PASV Port-range (definite sul server FTP)
-- 
|Ż \/Ż | /Ż\ /Ż__/Ż__|<|> *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/
 ____<|

 deve trattarla come la 21?
L'ALG FTP dello ZyXel lavora infatti in modalita' predefinita sulla
porta 21 -> tuttavia i firmware per la serie 662HW successivi a maggio
2005 hanno corretto i problemi di gestione FTP su non-standard port.
Qualora - pur aggiornando il firmware - avessi ancora problemi col
mapping diretto, potresti impostare il server FTP sulla porta 21 come
control port e regolare il resto lato port-forward.
In tal caso queste sarebbero le regole di traduzione NAT/PAT :
==
- WAN 2424 --> LAN/DMZ 21
- WAN 2423 --> LAN/DMZ 20
- WAN PASV Port-range --> LAN/DMZ PASV Port-range (sul server FTP)
A quel punto seguirebbe solo la verifica in PASV (modalita' suggerita
dalla KB ZyXel per non-standard FTP) ed anche in Active Mode.


 deve trattarla come la 21?
L'ALG FTP dello ZyXel lavora infatti in modalita' predefinita sulla
porta 21 -> tuttavia i firmware per la serie 662HW successivi a maggio
2005 hanno corretto i problemi di gestione FTP su non-standard port.
Qualora - pur aggiornando il firmware - avessi ancora problemi col
mapping diretto, potresti impostare il server FTP sulla porta 21 come
control port e regolare il resto lato port-forward.
In tal caso queste sarebbero le regole di permesso/traduzione :
==
- WAN 2424 --> LAN/DMZ 21
- WAN PASV Port-range --> LAN/DMZ PASV Port-range (sul server FTP)
==
per una connessione FTP in PASV.


scusa se mi reintrometto...ma a livello di connessione adsl come va il 
router?

 router?
Non e` ottima, a volte scarico a palla dalla dmz e la lan non accede
piu` a internet finche non ho finito, inoltre appena avviato quasi mai
riesce a tirar su la connessione, devo andare nel menu 21,4 (mi pare) e
fare il reboot), appena riavviato la conn. va su subito. Se intendi come
velocita` invece mi pare normalissimo, quindi bene. Ps questi prob non
li ho su un 660 ne' su un 650R.
Ciao


 control port e regolare il resto lato port-forward.
Il firmware attuale non lo fa, ma comunque risolveri solo parte dei
miei problemi....
Ciao


Ho mandato un email alla zyxel, infatti non ha funzionato
l'aggiornamento del firmware...accidenti.
Altri suggerimenti?


 l'aggiornamento del firmware...accidenti.
Sarebbe utile sapere quale dei 2 scenari PASV - a firmware aggiornato -
non ti avesse funzionato correttamente :
==
* Scenario 1
- WAN 2424 --> LAN/DMZ 2424
- WAN PASV Port-range --> LAN/DMZ PASV Port-range (sul server FTP)
* Scenario 2
- WAN 2424 --> LAN/DMZ 21
- WAN PASV Port-range --> LAN/DMZ PASV Port-range (sul server FTP)
==
tenendo conto che sono impostabili entrambi a livello CLI/CI in ambito
NAT Full-Feature (ved. definizione Address Mapping svrport/intport).


 un ftp su porta non standard?
Premesso quanto indicato nell'altro mio messaggio di risposta, dipende
dallo scenario NAT/DMZ -> in uno scenario 
p.es
. DMZ sull'IP LAN RFC-1918
192.168.0.11 questa configurazione (realizzata tramite CLI/CI) e'
funzionante senza problemi per l'FTP in PASV Mode la seguente :
==
NAT mapping : svrport 2424 intport 21 192.168.0.11
DMZ default : 192.168.0.11
==
con server FTP mantenuto in ascolto sulla porta standard di controllo.
In caso invece di IP non definito su DMZ, devi definire le regole di
forwarding/mapping anche per l'intervallo delle porte PASV definite sul 
server FTP.
In ogni caso, una volta definite le regole, puoi controllare anche i log
del server FTP in uso oltre a quelli sul router (visibili da interfaccia
CI Mode) per le traduzioni NAT/PAT.


 Ciao

 per non parlare del wi-fi che praticamente non va piů :O
Dopo aver visto come ZyXel aveva implementato il supporto wireless 
nella serie 650H (ed i relativi problemi), ho iniziato a preferire
- giusto per scrupolo - soluzioni che prevedessero il collegamento di AP
esterni.



idem

 NAT Full-Feature (ved. definizione Address Mapping svrport/intport).
Innanzitutto grazie per l'aiuto che mi stai dando, ora vorrei scrivere
due righe per chiarire la mia situazione. Mi scuso per le inesattezze
che posso aver detto precedentemente ma la situazione e` in sviluppo.
Ho un server ftp (ftpserver di apache, progetto in java), che sebbene
dica di supportare il passivo, questo non passa attraverso il nat. Non
so per quale ragione ma se mi passa per il router, il client riceve un
"425 Can't open passive connection. Passive mode refused.".
La configurazione per il passivo sarebbe fatta ad hoc, infatti funge 
con vsfptd sullo stesso server dietro lo stesso router e sulla stessa
porta (2424 sia srv che int), ma non la posso usare causa il tipo di 
server ftp che uso (e non posso cambiare).
Ho dei client tutti gestiti da me, che si connetteranno tramite gprs
omnitel e posso configurare a piacere, ma una volta fatto non posso
piu` toccarli perche` non ne avro` piu` accesso diretto.
_Il problema_ : Usando l'attivo (unica modalita` che mi resta), se setto
il server per usare la porta 21, tutto funge, se uso la porta 2424 non
va (timeout). Sto parlando sempre di srvport = intpor. A tal proposito,
sull'interfaccia web come nei menu' via telnet, nn ho trovato la
possibilita` di settare il port forward con srvport != intport, ma ho
visto qualcosa nel cli. Non so se il mio router lo fa a dire il vero,
anche se dalla tua frase si evince di si. Ora vado a vedere meglio, ma
se hai qualche dritta sono tutto orecchie.
In pratica ora potrei risolvere in due modi;
1) trovo il modo di abilitare l'ALG FTP su porta 2424
2) uso la srvport 21
Nel secondo caso, se fossi costretto ad usare la srvport 21 (quindi
sull'ip pubblico), avrei la necessita` minimo di forwardarla alla 2424
interna, per permettere al ftpserver in java di girare come utente e non
come root (se dovessi usare la porta 21).


 router, per non parlare del wi-fi che praticamente non va più :O
Brutta cosa, io cmq il wifi non l'ho mai usato.


 come root (se dovessi usare la porta 21).
Ma....ma.....maaaa.... rileggendo ho notato che c'e` un errore di fondo,
per l'attivo su porta 2223 probabilmente la ragione per cui non va e`
che l'ALG sul *router client* non si accorge che c'e` una connessione
ftp su quella porta 2424 e non apre le porte giuste.....
Scusate per l'abbaglio che ho preso ma sto facendo tante di quelle prove
fra attivo e passivo e vari server e varie connessioni che non ci
capisco piu` niente :-)
Attualmente comunque, come client sto usando un 660HW ultimo firmware,
ma a lavori ultimati i client staranno dietro il router omnitel quindi
non posso risolvere agendo sul router dalla parte del client.
L'unica soluzione e`, a livello di server, fargli usare la porta 21
sull'ip pubblico. A questo punto l'unica cosa che necessito di fare e`
un forward sulla porta 2424 in dmz.


 un forward sulla porta 2424 in dmz.
ip nat server load 2
ip nat server edit 3 intport 2424
ip nat server save 2
Cosi` ovviamente funge, era una cosa che volevo evitare di fare ma visto
che non posso configurare l'ALG sui router omnitel.... :-D
Il port forwarding mi ha permesso di tenere la porta interna 2424 che
comunque e` quello che mi interessava forse di piu`, visto che mi
permette di far girare il server ftp java come utente normale.
Peccato che non vada in passivo :-(
Grazie molte per le dritte


 Peccato che non vada in passivo :-(
Questo e' strano, assumendo che tale server sia in DMZ -> potresti in
tal caso aggiungere a tale NAT server set le regole di forwarding
invariato per l'intervallo di porte definito sul server FTP per le
sessioni PASV.


 cioč? e come hai risolto?
Rendendo meno "paranoiche" le impostazioni di Protocol Filter In/Out
sull'interfaccia WAN per le connessioni TCP/UDP associate alle porte
Well Known Services < 1024 (in particolare quelle UDP 68<-67 e 68->67),
e definendo apposite regole di permesso prioritarie che evitassero il
blocco delle comunicazioni di DHCP renew con l'indirizzo IP dedicato del
provider.


 
ah...ok...ma non credo stia li il problema o meglio,
avendo pure resettato il router allo stato di default e dunque senza 
nessuna regola in tal senso il router o meglio il modem interno del 
router non riesce ad agganciare la portante...le rarissime volte che 
l'aggancia dopo un tot la perde o comunque al primo 
spegnimento\accensione  si ripresenta lo stesso problema.
sinceramente incomincio ad avere il sospetto che qualcosa si sia fritta :-\
avevo visto due modelli cable\router della netgear che mi sembrano 
validi per un uso soho semi-professionale (non cose stratosferiche in 
ogni caso)...server ftp, web-server(ma non qualcosa di stratosferico), 
vpn (non spinta),samba:
Netgear FVS114 e Netgear FVS318...dalle features mi sembrano validi e 
dinamici...il primo sta tra le 80-90€ mentre il secondo sulle 150€...non 
ho capito però se la differenza sta solo nello switch, il primo a 4 il 
secondo a 8, perchè in tal caso me ne frego (sempre uno switch devo 
mettere).
che ne dici\te? parere?

 sessioni PASV.
Le porte le forwardo eccome, tant'e` che vsftpd funge, il problema penso
sia solo l'ftpserver di apache che non e` nat-friendly.


 mettere).
Differiscono - oltre che nella gestione firewall SPI - anche lato VPN,
soprattutto se e' utilizzato per tunnel VPN branch-office oltre che per
roaming mobile users.


>secondo a 8, perchè in tal caso me ne frego (sempre uno switch devo


 rn_p=9478bda4
In effetti quello e' un problema a livello di sync dell'apparato, e puo
essere causato 
p.es
. da :
==
- problemi HW dello ZyXel
- incompatibilita' nelle comunicazioni con remote node/DSLAM
- impostazioni non both-direction nelle comunicazioni con il remote node
In aggiunta al trace dei pacchetti, puoi controllare da interfaccia CI
mode l'output del comando :
==
ras > wan adsl diag
==
che riporta le info dettagliate sullo stato della portante.


  
purtroppo già provato ed in ogni caso non riuscendo ad agganciare la 
portante non è in grado di restituirmi i valori della portante.
quindi credo sia proprio un problema hw visto che tra l'altro già da un 
pezzo aveva incominciato a scricchiolare con la parte hw dell'wi-fi.
riguardo al post precedente sul netgear credo che prenderò il fvs318 
anche se in realtà ero più propenso a tirar su ipcop su un pc con 4 
schede ethernet, il problema però è reperire il pc e la locazione :-(

 portante non è in grado di restituirmi i valori della portante.
Ovviamente serve che lo stato sia up per avere i dati completi = lo
indicavo - a connessione avvenuta - come sistema per verificare alcune
cose a livello di protocollo linea (compresi gli errori indicati).
-- 
|¯ \/¯ | /¯\ /¯__/¯__|<|> *FAX/Mail Server  : 
+39 - 02700426582
 <|
|¯|\/|¯|/¯_¯\|(__\__ \<|> *Casella Vocale   : 
+39 - 0230312251
  <|


 
si lo so ma purtroppo oramai non aggancia più la portante nemmeno 
sporadicamente.
credo che qualcosa a livello di hw si sia guastato.
comunque grazie per l'aiuto.