Newsgroup: it.comp.os.linux.sys
Titolo: Mi aiutate a capire cosa non va con questo firewall?

Sono alle prese con una rete protetta da shorewall. Dentro la rete c'e' una 
macchina debian che dovrebbe fornire accessi vpn tramite pptpd.
Da "dentro" la rete funziona perfettamente, quindi lasciamo perdere pptpd 
perche' evidentemente e' ben configurato.
Da fuori, quindi passando sotte le forche di shorewall ho qualche problema.
Il fatto e' che ho letto qui (ovviamente) 
http://shorewall.net/PPTP.htm
 dove 
c'e' una sezione intitolata appunto "PPTP Server Running Behind your 
Firewall"
Ho eseguito tutto alla lettera, infatti nei log di shorewall tutto e' ok, 
nessun pacchetto viene droppato, pero' inspiegabilmente se da fuori tento di 
accedere in vpn, alla richiesta di user e password si ferma e dopo un po' 
ottengo un errore 630, e sul server con pptpd i log terminano cosi'
Mar  6 15:22:16 davidemobile pppd[13378]: Using interface ppp0
Mar  6 15:22:16 davidemobile pppd[13378]: Connect: ppp0 <--> /dev/pts/2
Mar  6 15:22:46 davidemobile pppd[13378]: LCP: timeout sending 
Config-Requests
Mar  6 15:22:46 davidemobile pppd[13378]: Connection terminated.
Mar  6 15:22:46 davidemobile pppd[13378]: Using interface ppp0
Mar  6 15:22:46 davidemobile pppd[13378]: Connect: ppp0 <--> /dev/pts/2
Mar  6 15:22:46 davidemobile pppd[13378]: tcflush failed: Bad file 
descriptor
Mar  6 15:22:46 davidemobile pppd[13378]: tcsetattr: Invalid argument (line 
1011)
Ripeto che dentro la lan e' tutto ok. Infatti nei log:
Mar  6 15:33:19 davidemobile pppd[13575]: Using interface ppp0
Mar  6 15:33:19 davidemobile pppd[13575]: Connect: ppp0 <--> /dev/pts/1
Mar  6 15:33:19 davidemobile pppd[13575]: MPPE 128-bit stateless compression 
enabled
Mar  6 15:33:21 davidemobile pppd[13575]: local  IP address 192.168.1.1
Mar  6 15:33:21 davidemobile pppd[13575]: remote IP address 192.168.1.235
Mar  6 15:33:21 davidemobile pppd[13575]: pptpd-logwtmp.so ip-up ppp0 davide 
192.168.0.2
Avete qualche idea? 

perche' evidentemente e' ben configurato.
Sicuramente il tuo problema č sul router (ovviamente do' per scontato
che  hai aperto il GRE sul fw)
La butto lģ, hai un TTL troppo basso sul router?
Luix

 La butto lì, hai un TTL troppo basso sul router?
Il firewall come dici tu, ovviamente e' ben configurato:
firewall:~# iptables-save |grep gre
-A net_dnat -p gre -j DNAT --to-destination 192.168.0.35
-A net2lan -d 192.168.0.35 -p gre -j ACCEPT
Infatti, come dicevo nel post, nei log non trova lcuna traccia di pacchetti 
droppati durante l'operazione di accesso alla macchian vpn (192.168.0.35), 
e' ho tutte le chain loggate quindi lo vedrei, ed in effetti, anche nei log 
del server vpn ho la conferma che il firewall non blocca proprio nulla.
Per quanto riguarda il TTL sul router non saprei..... questi i risultati su 
SpeedGuide.net:
TCP options string = 020405b401010402
MTU = 1500
MTU is fully optimized for broadband.
MSS = 1460
Maximum useful data in each packet = 1460, which equals MSS.
Default TCP Receive Window (RWIN) = 65535
RWIN Scaling (RFC1323) = 0 bits
Unscaled TCP Receive Window = 65535
Note: TCP 1323 Options need to be enabled for RWIN over 2^16 (65535). 
Windows 9x might also need the MS Vtcp386 fix.
For optimum performance, consider changing RWIN to a multiple of MSS.
Other RWIN values that might work well with your current MTU/MSS:
513920 (MSS x 44 * scale factor of 8)
256960 (MSS x 44 * scale factor of 4)
128480 (MSS x 44 * scale factor of 2)
64240 (MSS x 44)
bandwidth * delay product (Note this is not a speed test):
Your TCP Window limits you to: 2621.4 kbps (327.675 KBytes/s) @ 200ms
Your TCP Window limits you to: 1048.56 kbps (131.07 KBytes/s) @ 500ms
MTU Discovery (RFC1191) = ON
Time to live left = 118 hops
TTL value is ok.
Timestamps (RFC1323) = OFF
Selective Acknowledgements (RFC2018) = ON
IP type of service field (RFC1349) = 00000000 (0) 

 Sicuramente il tuo problema č sul router
Penso che tu abbia ragione. Pensa che ho collegato il server vpn su un ip 
"diretto" senza firewall in mezz, ed il risultato e' lo stesso!
Solo che non credo sia un problema di ttl. 

"diretto" senza firewall in mezz, ed il risultato e' lo stesso!
Te ne racconto un'altra 5 sedi con 5 firewall identici (clonati dallo
stesso master), su 4 la vpn pptp funziona benissimo, su una ogni tanto
svalvola, anzi ti dico di piu' su quest'ultima  sede ho aggiornato  a
fedora core 4 e quando viene scangiata la vpn pptp si incriccano gli
pseudo-device ppp e dumpa tutto il layer network della macchina :-)))
(ovviamente da dentro, senza passare dal router, funziona tutto
perfettamente)
Quindi, e te lo dico con l'esperienza di chi ci ha litigato tanto ma
tanto con la vpn pptp, i problemi sono in genere legati al
router.....ma da qui a dirti quale'e' il problema....(anche perche' se
il router lo gestisce telecom stai fresco...)
Comunque io sto abbandonando pptp per openvpn, ormai in convivenza con
pptp da tempo ed implementato in funzione di tale eliminazione.
Luix


 pptp da tempo ed implementato in funzione di tale eliminazione.
Bene cerchero' di capire allora.
Il router e' uno Zyxel, e' mio quindi nno c'e' problema per questo.
OpenVpn funziona alla grande, anche dietro il router e il firewall nessun 
problema.
Ma e' comodo in certe situazioni, avere la possibilita' di collegarsi con lo 
stumento standard di windows senza dover installare nulla.
Ciao e grazie 1000. 

 tanto con la vpn pptp
Senti, questo e' il risultato di  tcpdump -nlieth0 -s0 -vvv -xX sulla 
macchina con pptpd, ti dice qualcosa?
17:09:47.790771 IP (tos 0x0, ttl 64, id 62186, offset 0, flags [DF], proto: 
GRE (47), length: 65) 85.43.42.244 > 
85.43.42.243
: GREv1, Flags [key 
present, sequence# present, ack present], call 512, seq 0, ack 4294967295, 
length 45
LCP, Conf-Request (0x01), id 1, length 27
encoded length 25 (=Option(s) length 21)
0x0000: c021 0101 0019
ACCM Option (0x02), length 6: 0x00000000
0x0000: 0000 0000
Auth-Prot Option (0x03), length 5: CHAP, MS-CHAPv2
0x0000: c223 81
Magic-Num Option (0x05), length 6: 0xefb595c1
0x0000: efb5 95c1
PFC Option (0x07), length 2:
ACFC Option (0x08), length 2:
0x0000: 4500 0041 f2ea 4000 402f 4766 552b 2af4 E..A..@.@/GfU+*.
0x0010: 552b 2af3 3081 880b 001d 0200 0000 0000 U+*.0...........
0x0020: ffff ffff ff03 c021 0101 0019 0206 0000 .......!........
0x0030: 0000 0305 c223 8105 06ef b595 c107 0208 .....#..........
0x0040: 02 .
... ripetuto tante volte fino a che non il client non rinuncia tornando 
errore 630. 

macchina con pptpd, ti dice qualcosa?
....cut....
guarda forse meglio analizzare i log del pptp, per farlo:
1) aggiungi in syslog.conf:
	#poptop
	daemon.*                        /var/log/poptop
2) riavvii syslog
3) tail -f /var/log/poptop
4) lanci la connessione vpn e segui i log
.....posti i log :-)))
Luix

 .....posti i log :-)))
Mi dice semplicemente GRE: Bad checksum from pppd.
Mi sa tanto di firmware del router da aggiornare.... voi che ne pensate? 



Ovviamente ppp e' all'utlima versione....vero?
Luix

 Ovviamente ppp e' all'utlima versione....vero?
E' la 2.4.3