[OT] VPN ikec - postrouting iptables

Discussion:

Debian Forever

2018-10-14 21:37:49 UTC

Buenas, recientemente he montado un servidor bajo debian el cual lo
quiero para montar una VPN usando el software ikec.

Lo tengo todo montado, conecta sin problemas y llego a los hosts
internos a través de la conexión VPN tap0 sin problemas.

# ifconfig

tap0 Link encap:Ethernet direcciónHW aa:7f:94:15:7d:cc
Direc. inet:192.168.0.230 Difus.:192.168.0.230 Másc:255.255.255.255
Dirección inet6: fe80::a87f:94ff:fe15:7dcc/64 Alcance:Enlace
ACTIVO DIFUSIÓN FUNCIONANDO MTU:1380 Métrica:1
Paquetes RX:0 errores:0 perdidos:0 overruns:0 frame:0
Paquetes TX:0 errores:0 perdidos:0 overruns:0 carrier:0
colisiones:0 long.colaTX:1000
Bytes RX:0 (0.0 B) TX bytes:0 (0.0 B)

La máquina linux donde he montado la VPN tiene la ip 192.168.1.33/24

Mi máquina linux debian desktop tiene la 192.168.1.34

Ahora pasaría al siguiente punto, que es poder acceder a los hosts
internos desde otra máquina linux, por ejemplo la mia desktop. Para
ello de forma rápida, me he puesto la ruta necesaria:

route add -net 192.168.0.0 netmask 255.255.255.0 gw 192.168.1.33

Y el tráfico, ya se enruta correctamente.

Faltaría activar ip forward en el servidor:

# sysctl -p
net.ipv4.ip_forward = 1

Y finalmente, como siempre he hecho para conexiones openvpn, meter una
regla iptables postrouting en el servidor de esta forma:

iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o tap0 -j MASQUERADE

Pero no funciona, el tráfico lo enruta bien desde mi máquina hacia la
máquina linux al hacer un traceroute e intentar llegar a un host
interno pero no obtengo respuesta... Siempre he usado este método para
otras conexiones VPN como por ejemplo openpvn o vpnc.

Hay algo que se me escapa al ser una conexión de tipo de adaptador tap0?

Gracias de antemano.

Matias Mucciolo

2018-10-16 12:03:59 UTC

Permalink

Post by Debian Forever
Buenas, recientemente he montado un servidor bajo debian el cual lo
quiero para montar una VPN usando el software ikec.
Lo tengo todo montado, conecta sin problemas y llego a los hosts
internos a través de la conexión VPN tap0 sin problemas.
# ifconfig
tap0 Link encap:Ethernet direcciónHW aa:7f:94:15:7d:cc
Direc. inet:192.168.0.230 Difus.:192.168.0.230
Másc:255.255.255.255 Dirección inet6: fe80::a87f:94ff:fe15:7dcc/64
Alcance:Enlace ACTIVO DIFUSIÓN FUNCIONANDO MTU:1380 Métrica:1
Paquetes RX:0 errores:0 perdidos:0 overruns:0 frame:0
Paquetes TX:0 errores:0 perdidos:0 overruns:0 carrier:0
colisiones:0 long.colaTX:1000
Bytes RX:0 (0.0 B) TX bytes:0 (0.0 B)
La máquina linux donde he montado la VPN tiene la ip 192.168.1.33/24
Mi máquina linux debian desktop tiene la 192.168.1.34
Ahora pasaría al siguiente punto, que es poder acceder a los hosts
internos desde otra máquina linux, por ejemplo la mia desktop. Para
route add -net 192.168.0.0 netmask 255.255.255.0 gw 192.168.1.33
Y el tráfico, ya se enruta correctamente.
# sysctl -p
net.ipv4.ip_forward = 1
Y finalmente, como siempre he hecho para conexiones openvpn, meter una
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o tap0 -j MASQUERADE
Pero no funciona, el tráfico lo enruta bien desde mi máquina hacia la
máquina linux al hacer un traceroute e intentar llegar a un host
interno pero no obtengo respuesta... Siempre he usado este método para
otras conexiones VPN como por ejemplo openpvn o vpnc.
Hay algo que se me escapa al ser una conexión de tipo de adaptador tap0?
Gracias de antemano.

Buenas
realmente no necesitas "masquerear" los paquete de salida...
tenes que asegurarte solamente que salgan ..
esta bien el ip_forward y el ruteo para que salga por el tap0

es decir si tu desk es la 1.34 y quiere acceder a la red .0.x
hiciste todo bien...ahora lo que supongo que esta pasando(sin pruebas)
es que no vuelven los paquetes..porque la red .0.X no sabe como llegar
a tu desk(1.34)...por lo que a mi a simple vista me parece que falta la
regla de vuelta..

esto facilmente lo podes analizar con tcpdump..para ver si llegan los
paquete y donde se queda...por ejemplo en le servidor podes poner

tcpdump -i tap0 -n

algo asi de sencillo y hacer un ping de tu desk a una ip .0.x
y deberias ver lso paquetes saliendo por tap0..

ahora tenes que poner uno tcpdump en la otra punta y ver si llegan
al host .0.x .. y a la inversa...proba haciendo traceroute
desde la red .0.x a tu desk a ver que pasa..

si adjuntas tcpdump's y traceroute's bien detallados
y rutas de los hosts en cuestiion seria mas facil de saber
que estaria pasando..

saludos..
Matias.

Matias Mucciolo

2018-10-16 12:10:48 UTC

Permalink

Post by Debian Forever

Buenas
realmente no necesitas "masquerear" los paquete de salida...
tenes que asegurarte solamente que salgan ..
esta bien el ip_forward y el ruteo para que salga por el tap0
es decir si tu desk es la 1.34 y quiere acceder a la red .0.x
hiciste todo bien...ahora lo que supongo que esta pasando(sin pruebas)
es que no vuelven los paquetes..porque la red .0.X no sabe como llegar
a tu desk(1.34)...por lo que a mi a simple vista me parece que falta la
regla de vuelta..
esto facilmente lo podes analizar con tcpdump..para ver si llegan los
paquete y donde se queda...por ejemplo en le servidor podes poner
tcpdump -i tap0 -n
algo asi de sencillo y hacer un ping de tu desk a una ip .0.x
y deberias ver lso paquetes saliendo por tap0..
ahora tenes que poner uno tcpdump en la otra punta y ver si llegan
al host .0.x .. y a la inversa...proba haciendo traceroute
desde la red .0.x a tu desk a ver que pasa..
si adjuntas tcpdump's y traceroute's bien detallados
y rutas de los hosts en cuestiion seria mas facil de saber
que estaria pasando..
saludos..
Matias.

aclaracion ahora que reeleo creo que lo que no podes hacer es llegar
desde la .1.34 a la pc con la vpn.. todo lo que dije anterior
aplicalo al reves. jaja

es decir la pc .1.34 no sabe como entrar al tap0.
no se que gateway tendra esa pc...pero deberia tener al menos
para esa red la ip .1.33 y hace las pruebas con tcpdump que te vas
a dar cuenta facilmente lo que esta pasando.

saludos.
Matias

Debian Forever

2018-10-16 14:48:21 UTC

Permalink

Buenas Matías, antes de nada gracias por contestar. Lo primero me
corrijo, puesto que la regla postrouting estaba mal puesta:

MAL:
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o tap0 -j MASQUERADE

BIEN:
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o tap0 -j MASQUERADE

Aún así no funciona... He lanzado tcpdump en la máquina linux que
actúa de servidor, como cliente de la VPN, y lo que veo es que en
cuanto lanzo un pingo desde mi máquina cliente hacia una ip del rango
de las máquinas de la VPN 192.168.0.0/24, enruta bien y comienzo a ver
"echo request ICMP" pero no veo "echo reply" ...

No sé donde puede estar el problema, con otras conexiones VPN como
openvpn, vpnc no he tenido problema...

Post by Matias Mucciolo

Post by Debian Forever

Buenas
realmente no necesitas "masquerear" los paquete de salida...
tenes que asegurarte solamente que salgan ..
esta bien el ip_forward y el ruteo para que salga por el tap0
es decir si tu desk es la 1.34 y quiere acceder a la red .0.x
hiciste todo bien...ahora lo que supongo que esta pasando(sin pruebas)
es que no vuelven los paquetes..porque la red .0.X no sabe como llegar
a tu desk(1.34)...por lo que a mi a simple vista me parece que falta la
regla de vuelta..
esto facilmente lo podes analizar con tcpdump..para ver si llegan los
paquete y donde se queda...por ejemplo en le servidor podes poner
tcpdump -i tap0 -n
algo asi de sencillo y hacer un ping de tu desk a una ip .0.x
y deberias ver lso paquetes saliendo por tap0..
ahora tenes que poner uno tcpdump en la otra punta y ver si llegan
al host .0.x .. y a la inversa...proba haciendo traceroute
desde la red .0.x a tu desk a ver que pasa..
si adjuntas tcpdump's y traceroute's bien detallados
y rutas de los hosts en cuestiion seria mas facil de saber
que estaria pasando..
saludos..
Matias.

aclaracion ahora que reeleo creo que lo que no podes hacer es llegar
desde la .1.34 a la pc con la vpn.. todo lo que dije anterior
aplicalo al reves. jaja
es decir la pc .1.34 no sabe como entrar al tap0.
no se que gateway tendra esa pc...pero deberia tener al menos
para esa red la ip .1.33 y hace las pruebas con tcpdump que te vas
a dar cuenta facilmente lo que esta pasando.
saludos.
Matias

Debian Forever

2018-10-16 15:07:21 UTC

Permalink

He lanzado un tcpdump en el servidor desde donde lanzo la VPN en tap0
y no veo nada ... cuando lanzo el traceroute, telnet, ping... desde mi
máquina linux, no mete tráfico...

tcpdump -i tap0

Sin embargo, si hago el tcpdump en la interfaz de red eth0
192.168.1.34, al hacer traceroute, telnet, ping desde mi máquina, sí
que veo que mete tráfico... es decir, el enrutado está bien, el
tráfico lo dirige bien pero no lo mete por tap0...

192.168.0.100 (uno de los servidores dentro de la VPN)

tcpdump -i eth0 host 192.168.0.100

17:03:40.318708 IP 192.168.0.34 > 192.168.0.100: ICMP echo request, id
14754, seq 1, length 64
17:03:40.323021 IP 192.168.0.100 > 192.168.0.230: ICMP echo reply, id
14754, seq 1, length 64
17:03:41.337833 IP 192.168.0.34 > 192.168.0.100: ICMP echo request, id
14754, seq 2, length 64
17:03:41.341602 IP 192.168.0.100 > 192.168.0.230: ICMP echo reply, id
14754, seq 2, length 64

On Tue, Oct 16, 2018 at 4:48 PM Debian Forever

Post by Debian Forever
Buenas Matías, antes de nada gracias por contestar. Lo primero me
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o tap0 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o tap0 -j MASQUERADE
Aún así no funciona... He lanzado tcpdump en la máquina linux que
actúa de servidor, como cliente de la VPN, y lo que veo es que en
cuanto lanzo un pingo desde mi máquina cliente hacia una ip del rango
de las máquinas de la VPN 192.168.0.0/24, enruta bien y comienzo a ver
"echo request ICMP" pero no veo "echo reply" ...
No sé donde puede estar el problema, con otras conexiones VPN como
openvpn, vpnc no he tenido problema...

Post by Matias Mucciolo

Post by Debian Forever

Buenas
realmente no necesitas "masquerear" los paquete de salida...
tenes que asegurarte solamente que salgan ..
esta bien el ip_forward y el ruteo para que salga por el tap0
es decir si tu desk es la 1.34 y quiere acceder a la red .0.x
hiciste todo bien...ahora lo que supongo que esta pasando(sin pruebas)
es que no vuelven los paquetes..porque la red .0.X no sabe como llegar
a tu desk(1.34)...por lo que a mi a simple vista me parece que falta la
regla de vuelta..
esto facilmente lo podes analizar con tcpdump..para ver si llegan los
paquete y donde se queda...por ejemplo en le servidor podes poner
tcpdump -i tap0 -n
algo asi de sencillo y hacer un ping de tu desk a una ip .0.x
y deberias ver lso paquetes saliendo por tap0..
ahora tenes que poner uno tcpdump en la otra punta y ver si llegan
al host .0.x .. y a la inversa...proba haciendo traceroute
desde la red .0.x a tu desk a ver que pasa..
si adjuntas tcpdump's y traceroute's bien detallados
y rutas de los hosts en cuestiion seria mas facil de saber
que estaria pasando..
saludos..
Matias.

aclaracion ahora que reeleo creo que lo que no podes hacer es llegar
desde la .1.34 a la pc con la vpn.. todo lo que dije anterior
aplicalo al reves. jaja
es decir la pc .1.34 no sabe como entrar al tap0.
no se que gateway tendra esa pc...pero deberia tener al menos
para esa red la ip .1.33 y hace las pruebas con tcpdump que te vas
a dar cuenta facilmente lo que esta pasando.
saludos.
Matias

Matias Mucciolo

2018-10-16 15:20:10 UTC

Permalink

Post by Debian Forever
He lanzado un tcpdump en el servidor desde donde lanzo la VPN en tap0
y no veo nada ... cuando lanzo el traceroute, telnet, ping... desde mi
máquina linux, no mete tráfico...
tcpdump -i tap0
Sin embargo, si hago el tcpdump en la interfaz de red eth0
192.168.1.34, al hacer traceroute, telnet, ping desde mi máquina, sí
que veo que mete tráfico... es decir, el enrutado está bien, el
tráfico lo dirige bien pero no lo mete por tap0...
192.168.0.100 (uno de los servidores dentro de la VPN)
tcpdump -i eth0 host 192.168.0.100
17:03:40.318708 IP 192.168.0.34 > 192.168.0.100: ICMP echo request, id
14754, seq 1, length 64
17:03:40.323021 IP 192.168.0.100 > 192.168.0.230: ICMP echo reply, id
14754, seq 1, length 64
17:03:41.337833 IP 192.168.0.34 > 192.168.0.100: ICMP echo request, id
14754, seq 2, length 64
17:03:41.341602 IP 192.168.0.100 > 192.168.0.230: ICMP echo reply, id
14754, seq 2, length 64

hola devuelta..contesta abajo no hagas top-posting...

definitivamente no esta volviendo por la vpn...el "Masquerade"
como te comente antes no hace falta...no deberias usarlo.

y hacerla de los tcpdump para analizar mas la cosas
deberias poner el ejemplo de cada prueba que estas haciendo
y el resultado del tcpdump..y no te olvides de las rutas..

analizando ese tcpdump que pusiste mucho no me dice
ya que no se de donde sali y a dodne iba el ping
como que la .0.34(?) mando un ping a la .0.100 ??
estan en la misma red...obviamente eso no va a
pasar por la vpn..

saludos.
Matias