Foro en Español

Reply
New Contributor
Posts: 4
Registered: ‎08-31-2016

Fragmentación y reensamblado en escenarios de IAP-VPN

Escenario: IAP VPN con túnel Aruba GRE (L2 Centralized)

 image001.png

 

 

Ejemplo ping –l 1400 origen 192.168.103.201 destino 192.168.102.201

 

Captura en PC origen en la sede

image003.png

 

Captura tráfico túnel

 image005.png

Captura destino

 image007.png

Comentarios

Los paquetes de 1442 superan la MTU del IAP 205H para mandarlos por el túnel GRE de subida por lo que son fragmentados. El IAP 205H lo parte en un paquete de 1210 y otro de 308.

Por la VPN viaja un paquete con el flag de “more fragments” marcado con lo que debe de ser dejado pasar por posibles firewalls dentro la VPN.

La controladora encapsula  todo el paquete de vuelta de 1442 bytes en un paquete GRE sin necesidad de fragmentarlo ya que su valor por defecto de MTU de túnel así lo permite.

Los dos fragmentos del paquete de subida son reensamblados en la controladora por lo que al equipo de destino le llega el paquete original de 1442 bytes

 

Ejemplo ping –l 1500 origen 172.203.1.102 destino 10.0.0.146

 

Captura en PC origen en la sede

 image009.png

Captura tráfico túnel

 image011.png

Captura destino

 image013.png

Comentarios

Los ICMP de 1500 (junto con las cabeceras) superan la MTU standard del PC de 1514 con lo que ya son fragmentados cuando salen de los PCs.

El fragmento mayor debe ser vuelto a fragmentar para pasar por el túnel Aruba GRE y tanto IAP 205H (subida) como controller (bajada) los fragmentan.

El IAP 205H parte el paquete de 1512 en un paquete de 1210 y otro de 380. El fragmento de 1210 bytes lleva el bit “more fragments” activo mientras viaja por la VPN.

El fragmento original de 62 enviado por el PC es encapsulado y transmitido

En la controladora el fragmento grande de vuelta de 1512 bytes es vuelto a fragmentar en un paquete de 1210 y otro de 380 bytes. El fragmento de 1210 bytes lleva el bit “more fragments” activo mientras viaja por la VPN.

El fragmento original de vuelta de 62 bytes enviado por el PC es encapsulado y transmitido

La fragmentación que se realiza en los dispositivos finales se recompone en los dispositivos finales. La fragmentación realizada en IAP/controller se recompone en el extremo de salida del túnel con lo que los destinos ven los paquetes originales.

 

Conclusión:

Se utiliza mucho la fragmentación. Tanto los firewalls aguas arriba de la controladora como los de dentro de la VPN deben permitir fragmentos tanto en los flujos de subido como en los de bajada.

Si en todo el path del tráfico se permiten paquetes fragmentados no hay ningún problema para ningún tamaño de paquete.

 

 

 

Escenario: IAP VPN con túnel IPSEC (L3 Distributed)

 image015.png

 

 

 

 

Ejemplo ping –l 500 origen 172.203.1.102 destino 10.0.0.146

 

Captura en PC origen en la sede

 image017.png

Captura tráfico tunelado

 image019.png

Captura destino

 image021.png

Comentarios

n/a

 

Ejemplo ping –l 1400 origen 172.203.1.102 destino 10.0.0.146

 

Captura en PC origen en la sede

 image023.png

Captura tráfico tunel

 image025.png

Captura destino

 image027.png

Comentarios

Los paquetes de 1442 una vez cifrados no pasan por el túnel y tanto IAP con controller los fragmentan. El IAP 205H lo parte en paquete de 1310 y otro de 302. La controladora parte el paquete de vuelta en uno de 1454 y otro de 158.

Los paquetes que viajan por el túnel  son paquetes cifrados ESP y no llevan ninguna marca (en su cabecera exterior) que indique que se trata de un fragmento (“More fragements”=0) por lo que en principio estos paquetes no son potencialmente problemáticos para posibles firewalls por los que pase el trafico cifrado.

La fragmentación que se realiza a entrar al túnel no se recompone en la salida ni en IAP ni controller, se mandan directamente a destino para que sean recompuestos allí.

 

Ejemplo ping –l 1500 origen 172.203.1.102 destino 10.0.0.146

 

Captura en PC origen en la sede

 image029.png

Captura tráfico túnel

 image031.png

Captura destino

 image033.png

Comentarios

Los ICMP de 1500 (más cabeceras) superan la MTU standard del PC de 1514 con lo que ya son fragmentados cuando salen del PC.

El fragmento mayor debe ser vuelto a fragmentar para pasar por el por el túnel y tanto IAP con controller los fragmentan. El IAP 205H lo parte en un paquete de 1310 y otro de 382. La controladora parte el paquete de vuelta en uno de 1454 y otro de 238. Los fragmentos pequeños de 62 bytes se cifran y se envían de forma normal.

Los paquetes que viajan por el túnel  son paquetes cifrados ESP y no llevan ninguna marca (en su cabecera exterior) que indique que se trata de un fragmento (“More fragements”=0) por lo que en principio estos paquetes no son potencialmente problemáticos para posibles firewalls por los que pase el trafico cifrado.

La fragmentación que se realiza a entrar al túnel no se recompone en la salida ni en IAP ni controller, se mandan directamente a destino para que sean recompuestos allí.

 

Conclusión:

Se utiliza mucho la fragmentación. Los firewalls aguas arriba de la controladora deben permitir fragmentos tanto en los flujos de subida como en los de bajada. Los firewalls por los que pasa el trafico cifrado no ven ningún paquete fragmentado (con bit MoreFragments=1).

Si en todo el path del tráfico se permiten paquetes fragmentados no hay ningún problema para ningún tamaño de paquete.

Search Airheads
Showing results for 
Search instead for 
Did you mean: