Ele usa o UDP para passar por dispositivos NAT estúpidos. O que está acontecendo aqui é que o tráfego IPSec real está sendo encapsulado em UDP ( protocolo IP 17 ). O pacote IPSec nativo teria um valor de cabeçalho de protocolo IP de 50. Como 50 não é nem UDP (17) nem TCP (6), os gateways NAT estúpidos descartarão o pacote em vez de transmiti-lo.
Em segundo lugar, como o IPSec não é nem TCP nem UDP, ele não possui um número de porta. Portanto, se você estiver em uma conferência muito grande e oito de seus colegas de trabalho também estiverem indo, apenas um de vocês poderá ter sua VPN ativada a qualquer momento, já que o VPN Concentrator só faz a desambiguação no nível do IP. Ao encapsular dentro de um pacote UDP, ele permite vários pontos de extremidade VPN por trás de um dispositivo NAT.
Quanto ao porquê UDP? Isso é descrito em RFC 3715 . Seção 2.1.b:
Incompatibility between checksums and NAT. TCP and UDP checksums have a dependency on the IP source and destination addresses through inclusion of the "pseudo-header" in the calculation. As a result, where checksums are calculated and checked upon receipt, they will be invalidated by passage through a NAT or reverse NAT device.
As a result, IPsec Encapsulating Security Payload (ESP) will only pass through a NAT unimpeded if TCP/UDP protocols are not involved (as in IPsec tunnel mode or IPsec protected GRE), or checksums are not calculated (as is possible with IPv4 UDP). As described in [RFC793], TCP checksum calculation and verification is required in IPv4. UDP/TCP checksum calculation and verification is required in IPv6.
Isso pode acontecer porque a própria pilha IPSec tem verificação de integridade, portanto, usar um protocolo 'não confiável' para redes de trânsito não apresenta uma falha crítica na funcionalidade. Se um pacote for embaralhado em trânsito, ele não será desclipulado corretamente e o protocolo IPSec lidará corretamente com esse caso.
Alguns clientes suportam o modo TCP, mas a Cisco não é um deles.