PIX 506E, MTU, fragmentação de pacotes VPN e sistema telefônico Shoretel IP

3

Temos dois sites, um grande site do Sul e um pequeno site do Norte, que possuem uma VPN entre eles definida em dois Cisco PIX Firewalls. Sobre esta VPN Shoretel tráfego de telefone IP viaja, assim como todos os outros tráfegos de rede. Recentemente mudamos o menor escritório do norte para o Bt Infinity (fibra) e todos os sistemas funcionaram perfeitamente, isto é, funcionaram perfeitamente até a semana passada. Note, nada muda naquele dia.

O tráfego que vem da VPN de Manchester funciona em todas as frentes, além do sistema de telefonia. Nossos engenheiros de telefone da Shoretel dizem que tudo isso se deve aos pacotes do sistema de telefonia que têm o bit DF (não fragmentado) ligado ao tráfego e uma carga útil necessária de 1472, e com a sobrecarga IPSec, 1472 não ajustará o linhas MTU.

Se eu fizer um teste de MTU de ping do nosso escritório no sul para o nosso escritório no norte, recebo o seguinte:

C:\>ping <NorthernOfficeServerIP> -f -l 1472

Pinging <NorthernOfficeServerIP> with 1472 bytes of data:
Reply from <OutsideInterfaceOfSourthernPixIP>: Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

A configuração da VPN no PIX é a seguinte:

sysopt connection permit-ipsec
crypto ipsec transform-set chevelle esp-des esp-md5-hmac
crypto map transam 1 ipsec-isakmp
crypto map transam 1 match address 101
crypto map transam 1 set peer <Peer IP> 
crypto map transam 1 set transform-set chevelle
crypto map transam interface outside
isakmp enable outside
isakmp key ******** address <Peer IP> netmask 255.255.255.0
isakmp keepalive 10
isakmp nat-traversal 20
isakmp policy 1 authentication pre-share
isakmp policy 1 encryption des
isakmp policy 1 hash md5
isakmp policy 1 group 1
isakmp policy 1 lifetime 86400

A primeira coisa que eu tentei no PIX foi para limpar o marcador DF nos pacotes como abaixo:

pix(config)# crypto ipsec df-bit clear-df outside

Infelizmente, isso só dá:

ERRO: não reconhecido uso: [no] crypto ipsec {transform-set | associação de segurança} ... Digite help ou '?' para uma lista de comandos disponíveis.

Mas o nosso firmware PIX é bastante venerável, o show ver me dá:

Cisco PIX Firewall Version 6.3(5)
Cisco PIX Device Manager Version 3.0(4)

Compiled on Thu 04-Aug-05 21:40 by morlee

chathampix up 14 hours 54 mins

Hardware:   PIX-506E, 32 MB RAM, CPU Pentium II 300 MHz
Flash E28F640J3 @ 0x300, 8MB
BIOS Flash AM29F400B @ 0xfffd8000, 32KB

Eu tentei alterar o tamanho da MTU no PIX, eu tive a interface externa em 1500, 1492 (8 bytes para PPP) e BTs recomendação de 1458 para tentar atenuar o problema. A sobrecarga de 56 bytes da VPN significa que os pacotes com o bit DF configurado em 1472 bytes sempre serão descartados pela VPN.

Alguém sabe o comando equivalente para "pix (config) # crypto ipsec df-bit clear-df fora" para um PIX com este firmware? Ou você tem outras idéias?

ATUALIZAÇÃO:

O show crypto ipsec sa para o Northern PIX está abaixo:

interface: outside
    Crypto map tag: transam, local addr. <NorthernOutsideInterfaceIP>

   local  ident (addr/mask/prot/port): (192.168.16.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (192.168.0.0/255.255.255.0/0/0)
   current_peer: <SouthernOutsideInterfaceIP>:500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 107592, #pkts encrypt: 107592, #pkts digest 107592
    #pkts decaps: 114302, #pkts decrypt: 114302, #pkts verify 114302
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0
    #send errors 8, #recv errors 0

     local crypto endpt.: <NorthernOutsideInterfaceIP>, remote crypto endpt.: <SouthernOutsideInterfaceIP>
     path mtu 1492, ipsec overhead 56, media mtu 1492
     current outbound spi: 4ada0b77

     inbound esp sas:
      spi: 0xe7c2815(243017749)
        transform: esp-des esp-md5-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 1, crypto map: transam
        sa timing: remaining key lifetime (k/sec): (4516828/21982)
        IV size: 8 bytes
        replay detection support: Y


     inbound ah sas:


     inbound pcp sas:


     outbound esp sas:
      spi: 0x4ada0b77(1255803767)
        transform: esp-des esp-md5-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 2, crypto map: transam
        sa timing: remaining key lifetime (k/sec): (4598687/21980)
        IV size: 8 bytes
        replay detection support: Y


     outbound ah sas:


     outbound pcp sas:

E o MTU para o Southern PIX e o Northern PIX é:

mtu outside 1500
mtu inside 1500

O MTU é automaticamente definido menos os 8 bytes para PPP pelo PIX, acredito.

    
por MagicalArmchair 07.06.2012 / 14:55

1 resposta

2

Para o tráfego que excede a MTU da interface de saída após a adição da sobrecarga do IPSec, há vários PIX / ASA de "correções".

Mude o MTU no PIX / ASA para um número menor (1380 é comum) forçando as estações de envio a reagirem - nem sempre da maneira desejada.

Altere o MSS (somente TCP, não é útil para o UDP)

Deixe o fragmento PIX / ASA.

No caso em que df-bit é definido no cabeçalho IP interno e a fragmentação é necessária para ajustar através de um túnel IPSec, permitir que o PIX / ASA limpe o df-bit também é uma opção.

Note que limpar o df-bit requer o PIX / ASA OS 7.0 e superior . O "venerável" PIX 6.3 (5) não o cortará.

Uma pergunta mais importante é por que seu tráfego VoIP está desarmando a MTU? Todos os codecs VoIP que eu conheço (incluindo o muito comum G.711 e G.729) produzem por payloads de codec de "pacote" de menos de 160 bytes. Inclua sobrecarga de RTP, UDP e IP - aproximadamente 40 bytes no total e um tamanho de carga útil L2 de 200 bytes não maiores. Adicione outros 56 bytes para o IPSec ESP e ainda está longe de MTUs de interface Ethernet típica.

Quais são os seus administradores de VoIP empurrando o fio que requer uma carga útil de 1472 bytes L2?

Ref:

Voz sobre IP - Consumo de largura de banda por chamada

Informações técnicas - CODECs do VoIP

    
por 12.06.2012 / 02:00