Perdido con OpenVPN y dd-wrt

Me vi en la necesidad de implementar una VPN decidí pasar completamente de el PPTP por obvias razones e intentar con OpenVPN, de el lado de el servidor tengo un Centos 5.6 con OpenVPN 2.5

De el lado de los clientes unos ciscos e4200 con dd-wrt.

El problema es que las redes clientes pueden ver los equipos de las redes dentro de el servidor, pero dentro de la red de el servidor es imposible ver los equipos de la red cliente. De igual forma los equipos de redes clientes no pueden verse entre si.

Agradezco de antemano de parte de la comunidad linuxera cualquier ayuda para resolver este inconveniente.


La Configuracion es Tipo RoadWarrior pero RED a RED.

Configuracion de el servidor.

————–

port 1194
proto udp
dev tun
persist-tun
persist-key
#—- Seccion de llaves —–
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key
dh /etc/openvpn/keys/dh1024.pem
#—————————-
server 192.168.254.0 255.255.255.0
client-config-dir usuarios
route 192.168.51.0 255.255.255.0
route 192.168.52.0 255.255.255.0
client-to-client
push “dhcp-option WINS 192.168.50.1”
push “route 192.168.50.0 255.255.255.0” #si no la pongo no se genera la ruta
#push “route 192.168.51.0 255.255.255.0” Si activo esta bloqueo completamente el router de esta red
#push “route 192.168.52.0 255.255.255.0” Si activo esta bloqueo completamente el router de esta red
max-clients 30
keepalive 10 120
cipher AES-128-CBC
comp-lzo
persist-remote-ip
float
status /var/log/openvpn-status-servidorvpn-udp-1194.log
verb 5

——————————

configuracion individual (de cada cliente dentro del server).

cliente1
——————————–

ca /etc/openvpn/keys/ca.crt
dh /etc/openvpn/keys/dh1024.pem
cert /etc/openvpn/keys/cliente0.crt
key /etc/openvpn/keys/cliente0.key
push “route 192.168.52.0 255.255.255.0”
push “route 192.168.50.0 255.255.255.0”
#aparentemente esta ignorando estos comandos ya que estas rutas no las esta generando.
iroute 192.168.51.0 255.255.255.0
verb 5
status /var/log/openvpn-torreon.log
mute 20

——————————–

cliente2

——————————–

ca /etc/openvpn/keys/ca.crt
dh /etc/openvpn/keys/dh1024.pem
cert /etc/openvpn/keys/cliente1.crt
key /etc/openvpn/keys/cliente1.key
push “route 192.168.51.0 255.255.255.0”
push “route 192.168.50.0 255.255.255.0”
#aparentemente esta ignorando estos comandos ya que estas rutas no las esta generando.
iroute 192.168.52.0 255.255.255.0
verb 5
status /var/log/openvpn-sabinas.log
mute 20

——————————–

Configuracion de los equipos clientes dd-wrt.

Asi queda la tabla de ruteo en el servidor.

——————————–

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.254.2   *               255.255.255.255 UH    0      0        0 tun0
192.168.52.0    192.168.254.2   255.255.255.0   UG    0      0        0 tun0
192.168.50.0    *               255.255.255.0   U     0      0        0 eth0
192.168.51.0    192.168.254.2   255.255.255.0   UG    0      0        0 tun0
192.168.254.0   192.168.254.2   255.255.255.0   UG    0      0        0 tun0
203.203.244.0    *               255.255.254.0   U     0      0        0 eth1
169.254.0.0     *               255.255.0.0     U     0      0        0 eth1
default         fixed-203-204-1. 0.0.0.0         UG    0      0        0 eth1

——————————–

Ahora en dd-wrt (cuando menos en la versión que uso) no es necesario usar el comando sysctl -p ya que net.ipv4.ip_forward = 1 viene por default.

No obstante si hago uso de.

echo “1” > /proc/sys/net/ipv4/ip_forward

Para asegurar el valor de ip_forward aun con eso las redes dentro de los clientes siguen inalcanzables.

Ahora… si reconfiguro todo para trabajar sobre TAP en lugar de TUN con eso ya existe comunicacion entre red cliente y red servidor, pero las rutas hay que generarlas a mano…. aun asi la comunicacion entre cliente a cliente es inexistente..

Cualquier ayuda es bienvenida.

P.D. Les anexo el log de openvpn de el lado de el servidor.

Fuentes.

Cómo Configurar un Servidor OpenVpn

Configuración de OpenVPN Red a Red

dd-wrt forum ip_forward

Nota: Intente la configuracion tipica RED a RED pero al igual que en esta los pings de servidor a clientes no se responden.