Newsgroup: it.comp.os.linux.sys
Titolo: OpenVPN solo ping

Ciao a tutti,
ho ripreso gli esperimenti con OpenVpn e mi trovo dinanzi ad una situazione 
un po' strana: VPN attiva, indirizzo al client assegnato, così come routing, 
dns... riesco a fare il ping tra il client road warrior e le macchine della 
LAN e viceversa, ma tutto il traffico ssh, web, rdp... sembra essere 
bloccato in entrambe le direzioni.
Questa è la configurazione della macchina sulla LAN con il server OpenVpn:
=============================================================================
port 1194
proto tcp
dev tun
ca keys/ca.crt
cert keys/server.crt
key keys/server.key
dh keys/dh1024.pem
server 192.168.17.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
comp-lzo
user nobody
group users
persist-key
persist-tun
status openvpn-status.log
status-version 2
verb 3
client-to-client
push "dhcp-option DNS 192.168.8.234"
push "dhcp-option DNS 192.168.8.110"
push "dhcp-option WINS 192.168.8.110"
push "route 192.168.0.0 255.255.240.0"
=============================================================================
Sempre sulla stessa macchina:
=============================================================================
# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Ifac
192.168.17.2    0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.17.0    192.168.17.2    255.255.255.0   UG    0      0        0 tun0
192.168.0.0     0.0.0.0         255.255.240.0   U     0      0        0 eth0
0.0.0.0         192.168.5.1     0.0.0.0         UG    0      0        0 eth0
=============================================================================
Qualche idea?
Ciao,
  Void

 Qualche idea?
Firewall? Routing asimmetrico? MTU?
Sniffa il traffico sulla macchina OpenVPN Server.
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.

 Sniffa il traffico sulla macchina OpenVPN Server.
Ping roadwarrior -> macchina in lan:
=============================================================================
# tcpdump host 192.168.8.94 and not arp
15:59:13.660597 IP 192.168.17.6 > 
192.168.8.94
: ICMP echo request, id 768, seq 62208, length 40
15:59:13.660914 IP 192.168.8.94 > 
192.168.17.6
: ICMP echo reply, id 768, seq 62208, length 40
15:59:14.489775 IP 192.168.17.6 > 
192.168.8.94
: ICMP echo request, id 768, seq 62464, length 40
15:59:14.490334 IP 192.168.8.94 > 
192.168.17.6
: ICMP echo reply, id 768, seq 62464, length 40
15:59:16.273952 IP 192.168.17.6 > 
192.168.8.94
: ICMP echo request, id 768, seq 62720, length 40
15:59:16.274257 IP 192.168.8.94 > 
192.168.17.6
: ICMP echo reply, id 768, seq 62720, length 40
15:59:17.027707 IP 192.168.17.6 > 
192.168.8.94
: ICMP echo request, id 768, seq 62976, length 40
15:59:17.028008 IP 192.168.8.94 > 
192.168.17.6
: ICMP echo reply, id 768, seq 62976, length 40
=============================================================================
Telnet alla porta 80 roadwarrior -> macchina in lan:
=============================================================================
# tcpdump host 192.168.8.94 and not arp
16:00:03.547859 IP 192.168.17.6.2172 > 192.168.8.94.www: S 2238622583:2238622583(0) win 65535 <mss 1160,nop,wscale 2,nop,nop,timestamp 0 0,nop,nop,sackOK>
16:00:06.035819 IP 192.168.17.6.2172 > 192.168.8.94.www: S 2238622583:2238622583(0) win 65535 <mss 1160,nop,wscale 2,nop,nop,timestamp 0 0,nop,nop,sackOK>
16:00:11.750693 IP 192.168.17.6.2172 > 192.168.8.94.www: S 2238622583:2238622583(0) win 65535 <mss 1160,nop,wscale 2,nop,nop,timestamp 0 0,nop,nop,sackOK>
16:00:23.645257 IP 192.168.17.6.2172 > 192.168.8.94.www: S 2238622583:2238622583(0) win 65535 <mss 1160,nop,wscale 2,nop,nop,timestamp 0 0,nop,nop,sackOK>
16:00:47.729406 IP 192.168.17.6.2172 > 192.168.8.94.www: S 2238622583:2238622583(0) win 65535 <mss 1160,nop,wscale 2,nop,nop,timestamp 0 0,nop,nop,sackOK>
16:01:36.233672 IP 192.168.17.6.2172 > 192.168.8.94.www: S 2238622583:2238622583(0) win 65535 <mss 1160,nop,wscale 2,nop,nop,timestamp 0 0,nop,nop,sackOK>
=============================================================================
Ciao e grazie,
  Void :-?

 =============================================================================
Questo è sulla eth0 o sulla tun0?
Se è traffico sniffato sulla eth0 allora trattasi di firewall (o altro
problema) sulla macchina 192.168.8.94 perché i pacchetti sono
correttamente ruotati ed inoltrati dal firewall al web server.
Una prova è quella di fare telnet dalla macchina openvpn verso la 80 e
poi rifare telnet ma facendo il bind sull'IP dell'interfaccia tun0.
$ telnet -b 192.168.17.1 192.168.8.94 80


 poi rifare telnet ma facendo il bind sull'IP dell'interfaccia tun0.
openvpn# telnet 192.168.8.94 80
Trying 192.168.8.94...
Connected to 192.168.8.94.
openvpn# telnet -b 192.168.17.1 192.168.8.94 80
Trying 192.168.8.94...
telnet: Unable to connect to remote host: Connection timed out


   Void :-?
iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE


 iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
ECCO, PROPRIO LUI!!! Ora funziona, grazie 1000!!!
Ciao,
  Void :-)

 che senso ha ? OpenVPN non necessita per nulla di un trasporto reliable.
In realtà è rimasto dal primo tutorial che ho seguito:
http://www.annoying.dk/2007/10/14/quick-simple-tutorialhowto-on-openvpn-with-debian/
Basterebbe sotituire con "proto udp"? Ci sarebbero dei vantaggi effettivi?
Ci sono altri miglioramenti possibili?
Ciao e grazie,
  Void

 per nulla di un trasporto reliable.
Nella teoria ciò che dici potrebbe essere vero, se fosse documentato.
Nella pratica è una cazzata. Con TCP hai meno problemi.

 Ci sono altri miglioramenti possibili?
Boh... dipende da quel che vuoi fare.
Mia conf...
SERVER
=============
local 
xxx.it
proto udp
port 11194
dev tun0
ca ca.xxx.it.crt
cert vpn.xxx.it.pem
key vpn.xxx.it.pem
dh dh1024.pem
server 192.168.16.0 255.255.255.0
topology subnet
client-config-dir ccd
ccd-exclusive
script-security 2
push "route 192.168.19.0 255.255.255.0"
comp-lzo
mssfix
keepalive 10 120
max-clients 10
persist-key
persist-tun
user nobody
group nogroup
client-to-client
verb 4
mute 20
CCD
=============
ifconfig-push 192.168.16.XXX 255.255.255.0
push "route 192.168.19.0 255.255.255.0 vpn_gateway 10"
CLIENT
=============
client
dev-type tun
dev tung0
remote 
xxx.it
 11194 udp
tls-client
ca ca.xxx.it.crt
cert client.xxx.it.pem
key client.xxx.it.pem
tls-remote 
vpn.xxx.it
comp-lzo
mssfix
keepalive 10 120
persist-key
persist-tun
pull
# Reti RFC1918 locali
route 10.0.0.0 255.0.0.0 net_gateway 10
route 172.16.0.0 255.240.0.0 net_gateway 10
route 192.168.0.0 255.255.0.0 net_gateway 10
user nobody
group nogroup
verb 4


 ECCO, PROPRIO LUI!!! Ora funziona, grazie 1000!!!
No, non funziona. Quello era solo per confermare che il problema è sul
web server che non accetta pacchetti provenienti dalla rete delle vpn
(quindi firewall) o che risponde per strade sbagliate (quindi routing).
Il server VPN è il default gateway? Se non lo è hai aggiunto sul defgw
le rotte di ritorno per la classe IP delle VPN?
Puoi anche tenere la regola, ma ti perdi sulla destinazione
l'informazione di chi si connette, venendo tutto mascherato dal server VPN.


 Nella mia esperienza non ho alcun problema con UDP. E lo uso tanto.
Anche io lo usavo tanto, era più veloce (stiamo parlando di 0.01ms a 
pacchetto, un nulla).
Quando però un router tra te ed il server decide che i pacchetti UDP 
hanno meno rilevanza del TCP o quando decide che ne stai mandando o 
ricevendo troppi, diventa inusabile e switchando a TCP i problemi si 
risolvono.
Tendendo a fanculare chi mi chiama dicendo "il concentratore VPN si è 
rotto", ho deciso per quieto vivere di usare solo TCP.
Troppo difficile far capire certe cose ad una scimmia.

 risolvono.
Per motivi analoghi tendo sempre ad avere entrambe le opzioni attive sul
server VPN.
Un'istanza UDP e un'istanza TCP, che usano due classi /25 attigue (in
modo che il routing lo gestisco sulla /24), due directory ccd distinte
(ccdu e ccdt) per stabilire i parametri dei singoli client. Poi il resto
uguale tra le due istanze, compresi certificati ecc.ecc.
Grazie a push e ccd lato client la configurazione è identica, cambia
solo una riga:
se vuoi usare udp:
   remote 
vpn.xxx.it
 11194 udp
se vuoi usare tcp:
   remote 
vpn.xxx.it
 443 tcp
TCP sai sempre se funziona o no e se non funziona puoi farne
troubleshooting. Inoltre per la porta TCP, oltre alla classica 1194,
redirigo con iptables anche la 443 in modo da poter bypassare eventuali
problemi con firewall rompiscatole.
UDP è un terno al lotto e con tutti i router Alice, Pirelli, ecc.ecc.
che con più di 5 pacchetti UDP si impallano avere un'alternativa pronta
è cosa buona e giusta.


 (road warrior e fra reti) in piedi da anni ormai ...
Io ad oggi ho avuto problemi in 5/6 casi, tutti per colpa dei router
tranne uno che era un firewall del cavolo. La user base però è un po'
più altina, parliamo di oltre un paio di centinaia di vpn.


 Puoi anche tenere la regola, ma ti perdi sulla destinazione
In effetti...
Ho fatto qualche altra prova, riassumo:
* routing: la regola sul DG è che il GW per la rete (vpn) 
192.168.17.0/24
 è 
il vpn server 192.168.8.33;
* firewall: forse è superfluo ma ho aggiunto che 
192.168.17.0/24
 può 
accedere a tutto;
* ping, traceroute e dns funzionano sempre;
* tutti gli altri protocolli non funzionano;
* con il masquerade funziona tutto;
* se su una macchina aggiungo una route statica identica a quella 
specificata sul gateway, magicamente quella macchina diventa raggiungibile, 
e questo mi porta ulteriore frustrazione...
Ciao,
  Void :-?

 e questo mi porta ulteriore frustrazione...
Questo conferma che è un problema di routing. Non conosco pfsense, ma in
genere il problema è riconducibile alla gestione del routeback di
pacchetti verso l'interfaccia da cui sono entrati o a problemi con la
generazione/gestione degli icmp-redirect.


 generazione/gestione degli icmp-redirect.
Al momento non ho risolto il problema e penso di usare il masquerade, non 
avendo necessità di sapere quali (pochi) ip si connettono alle macchine 
interne (in vpn): grazie per tutte le dritte!
Ciao,
  Void :-)