[Jool-list] Consulta sobre NAT

JORDI PALET MARTINEZ jordi.palet at consulintel.es
Wed Mar 14 02:14:51 CST 2018


Hola Demian,

 

NAT64 solo permite tráfico TCP, UDP, ICMP, salvo que incorpore ALGs.

 

El CLAT es transparente, y la combinación CLAT-NAT64 es básicamente una doble traducción que es aún “mas” transparente.

 

En el último hackaton del IETF, probamos todo tipo de configuraciones de VPNs con 464XLAT, y en ningún caso tuvimos fallos. Esa prueba se hizo con LEDE para el CLAT, con diversos sistemas operativos detrás (tanto de laptops como celulares), y con diversos NAT64.

 

La cuestión es que los túneles PPTP, están siendo retirados de los sistemas operativos, por muchas cuestiones, entre ellas seguridad.

 

Así que mi recomendación es usar un escenario de VPN que sea más seguro. Yo por ejemplo usaba antes PPTP, y ahora uso OpenVPN (y funciona con 464XLAT) … pero teniendo en cuenta que cualquier mecanismo de traducción siempre modificará la cabecera.


Saludos,

Jordi

 

De: <jool-list-bounces at nic.mx> en nombre de Demian Pecile <dpecile at sietecapas.com.ar>
Fecha: miércoles, 14 de marzo de 2018, 3:00
Para: Alberto Leiva <ydahhrk at gmail.com>
CC: <jool-list at nic.mx>
Asunto: Re: [Jool-list] Consulta sobre NAT

 

Hola Alberto

                Gracias por responder !

 

Parte de la confusión tal vez sea porque me interesa probar la solución 464, y no el nat64 propiamente dicho ?

del lado del cliente no estoy usando Tayga ni Jool, si no CLAT.

 

Mis comentarios abajo.



El 13 mar. 2018, a las 15:48, Alberto Leiva <ydahhrk at gmail.com> escribió:

 

Hola



El único problema que encontré (por ahora) es que no logro conectarme a VPNs de tipo PPTP.


Mmm, nunca lo he intentado. Puedo tratar de hacerlo si quieres. Pero
lee mis comentarios de abajo primero; quizá hay algunas cosas que no
estás considerando.



De un lado tengo Jool en LEDE, por el otro el cliente 464XLAT (CLAT) en LEDE también.
Probe con otros traductores (Tayga), y ahí pude conectarme a VPNs PPTP, pero no IPSec.


Ok, esto me parece normal.
(Pero quizá sería bueno que me aclararas una cosa: Cuando lo probaste
con Tayga, ¿usaste dos Taygas, o usaste un Jool y un Tayga?)

 

Tayga haciendo nat 64 y CLAT haciendo nat 46 o Jool haciendo nat 64 y clat haciendo nat 46.






Si agrego los helpers de NAT a LEDE, sigo sin conectarme a PPTP, y deja de funcionar SIP.
Tienen alguna idea si funcionan las cosas que necesitan nat helpers ?


Probablemente no.

Los NAT helpers del kernel son un feature de NAT/conntrack, no de
NAT64. Jool no intenta interactuar con ellos.
(Y muy probablemente Tayga tampoco porque ni siquiera opera en el kernel.)

 

Pero esos nathelpers están del lado del cliente CLAT.

Y algo hacen, porque si los agrego, rompen SIP.

Cuando quiero utilizar pptp, obtengo un mensaje que dice "conntrack: generic helper won't handle protocol 47. Please consider loading the specific helper module” 

y si cargo el helper de GRE el mensaje cambia a [nat46] Could not translate v4->v6

 

El tema es que si utilizo Tayga si funciona PPTP, pero no IPSec. (igual si me dan a elegir prefiero IPSec que PPTP).






En un principio supuse que el problema era del lado del CLAT, pero lo que me hizo sospechar de Jool, es que con Tayga funciona PPTP, pero no funciona IPSec, y con Jool al revés.


Lo que estás intentando hacer me parece un poco extraño.

(Disclaimer: Estoy muy lejos de ser un experto en IPSec, por lo que se
me puede estar escapando algo.)

¿Estás considerando que IPSec es inherentemente incompatible con
traducción IPv4/v6, excepto quizá en circunstancias muy específicas?

 

Ahora mismo está funcionando, demora un poco en marcar la conexión como conectada, pero los paquetes pasan …

 


-> Stateful NAT64 necesita modificar campos de los encabezados de capa
4. (TCP, UDP)
-> Tengo entendido que IPSec encripta estos encabezados.
-> Stateful NAT64 no puede traducir información que está encriptada.
-> Por lo tanto, IPSec no funciona con Stateful NAT64.

Puede que sea posible que IPSec funcione a través de SIIT/DC Dual.
(https://jool.mx/en/siit-dc-2xlat.html)
Menciono esto porque SIIT/DC Dual es un 464XLAT que usa dos SIITs en
lugar de un SIIT y un Stateful NAT64.
SIIT no necesita modificar headers de capa 4, por lo tanto, existe la
posibilidad de que IPSec funcione a través de SIIT/DC Dual.
Pero no tomes esto como una garantía, porque no conozco muy bien IPSec
y quizá se me está escapando algo.

Esto es lo que dicen los RFCs de SIIT y NAT64 respecto a IPSec (pero
nota que ninguno de estos RFCs considera SIIT/DC Dual):

RFC 6146 (Stateful NAT64), sección 5.1:

   Any protocols that protect IP header information are essentially
   incompatible with NAT64.  This implies that end-to-end IPsec
   verification will fail when the Authentication Header (AH) is used
   (both transport and tunnel mode) and when ESP is used in transport
   mode.  This is inherent in any network-layer translation mechanism.
   End-to-end IPsec protection can be restored, using UDP encapsulation
   as described in [RFC3948].  The actual extensions to support IPsec
   are out of the scope of this document.

Hasta donde yo sé, estas extensiones no han sido definidas. Jool
definitivamente no las implementa.

RFC 7915 (SIIT), sección 5.1:

   Some translated protocols will fail at the receiver for
   various reasons: some are known to fail when translated (e.g.,
   IPsec Authentication Header (51)), ...

Sección 8:

   The IPsec Authentication Header [RFC4302] cannot be used for NAT44 or
   NAT64.

 

Igualmente funciona, no tengo idea como o porque.

 

El tema es que con estas limitantes, y la necesidad de salir ya con el servicio en un pequeño ISP, hacen que probablemente use IPV4, en el peor de los casos con NAT44 (en el que si funciona IPSec y PPTP y SIP), que es un animal conocido y probado.

El único limitante, es cuando quieren acceder desde afuera a unas cámaras IP por ejemplo, pero estimo que el mismo problema lo voy a tener poniendo el doble NAT44 y encima agregando IPV6 en el medio (464).

 

Saludos y muchas gracias !

 

Demian

 

 



2018-03-12 19:22 GMT-06:00 Demian Pecile <dpecile at sietecapas.com.ar>:


Hola
Estoy testeando Jool.
De un lado tengo Jool en LEDE, por el otro el cliente 464XLAT (CLAT) en LEDE
también.
El único problema que encontré (por ahora) es que no logro conectarme a VPNs
de tipo PPTP.
Probe con otros traductores (Tayga), y ahí pude conectarme a VPNs PPTP, pero
no IPSec.
Si agrego los helpers de NAT a LEDE, sigo sin conectarme a PPTP, y deja de
funcionar SIP.
Tienen alguna idea si funcionan las cosas que necesitan nat helpers ?
En un principio supuse que el problema era del lado del CLAT, pero lo que me
hizo sospechar de Jool, es que con Tayga funciona PPTP, pero no funciona
IPSec, y con Jool al revés.

Saludos

--
Demian Pecile
Siete Capas S.R.L.
Periodistas Neuquinos 136
Piso 4 - Dpto. A - 8300 Neuquen
Argentina
Tel +54-299-4479172
Cel. +549-299-5833500


_______________________________________________
Jool-list mailing list
Jool-list at nic.mx
https://mail-lists.nic.mx/listas/listinfo/jool-list

 

--

Demian Pecile

Siete Capas S.R.L.

Periodistas Neuquinos 136

Piso 4 - Dpto. A - 8300 Neuquen

Argentina

Tel +54-299-4479172 

Cel. +549-299-5833500

 

_______________________________________________ Jool-list mailing list Jool-list at nic.mx https://mail-lists.nic.mx/listas/listinfo/jool-list 



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail-lists.nic.mx/pipermail/jool-list/attachments/20180314/9bbf0e64/attachment-0001.html>


More information about the Jool-list mailing list