Problema com acesso remoto, L2L fixo e L2L IPSEC dinâmico trabalhando juntos no ASA 5540 8.2

Tenho um problema com uma mistura de acesso remoto, túneis L2L e L2L dinâmico em um ASA5540 executando 8.2

Aqui está um trecho da configuração relevante: -

crypto dynamic-map outside-crypto-dynamic-map 10 match address outside-crypto-dynamic-map-10
crypto dynamic-map outside-crypto-dynamic-map 10 set transform-set ESP-3DES-MD5
crypto dynamic-map outside-crypto-dynamic-map 20 set transform-set ESP-3DES-MD5
crypto map outside-crypto-map 201 match address outside-crypto-map-201
crypto map outside-crypto-map 201 set peer X.X.X.X
crypto map outside-crypto-map 201 set transform-set ESP-3DES-MD5
crypto map outside-crypto-map 202 match address outside-crypto-map-202
crypto map outside-crypto-map 202 set peer Y.Y.Y.Y
crypto map outside-crypto-map 202 set transform-set ESP-AES256-SHA
crypto map outside-crypto-map 65535 ipsec-isakmp dynamic outside-crypto-dynamic-map
crypto map outside-crypto-map interface outside

Eu tenho vários sites remotos que usam IPs dinâmicos. As sub-redes da LAN para elas estão em uma ACL "outside-crypto-dynamic-map-10".

Eles correspondem bem com base nesta linha: -

crypto dynamic-map outside-crypto-dynamic-map 10 match address outside-crypto-dynamic-map-10

Eu tenho outros túneis L2L "estáticos" que funcionam bem por 201 e 202 na configuração acima.

Com meus usuários de acesso remoto (Cisco VPN Client), a menos que eu tenha a seguinte linha, eles não se conectam: -

crypto dynamic-map outside-crypto-dynamic-map 20 set transform-set ESP-3DES-MD5

Se eu tentar adicionar uma instrução "endereço de correspondência" a essa sequência (como abaixo), o acesso remoto deixará de funcionar (onde "vpc-client-subnet" é uma ACL que contém a sub-rede do pool IP usado para os clientes de acesso remoto) pois não consegue encontrar um local / remoto correspondente.

crypto dynamic-map outside-crypto-dynamic-map 20 match address vpc-client-subnet

O problema é que tenho vários pontos de extremidade L2L por aí (que não quero mais conectar, mas não tenho controle) que ainda estão configurados (na extremidade remota) com o PSK usado pelos pares L2L dinâmicos. Eu removi as sub-redes da LAN do "outside-crypto-dynamic-map-10" (como eu não as quero mais conectadas) para que não correspondam mais no mapa dinâmico seq 10, no entanto, elas ainda podem concluir com êxito a fase 2 contra o "mapa dinâmico fora da criptografia 20" e parece que esse fim aceita apenas o que o controle remoto propõe como local / remoto para a SA.

Não estou em condições de alterar o PSK. Não consigo adicionar um "endereço de correspondência" ao "mapa dinâmico fora da criptografia 20", pois impedirá a conexão de clientes de acesso remoto; no entanto, se não o fizer, ele funcionará como um atrativo para outros pares. que de outra forma conhecem o PSK.

Idealmente, eu poderia adicionar "endereço de correspondência" à seq 20, para que os usuários de acesso remoto correspondam a ela, mas os pares "antigos" da seq 10 não. Como alternativa, existe uma maneira de impedir que o ASA aceite a idéia de pares remotos do local / remoto para o SA quando ele corresponder a um mapa que não possui uma declaração de "endereço de correspondência"?

EDITAR:

A configuração relevante do grupo de túneis: -

tunnel-group DefaultL2LGroup ipsec-attributes
 pre-shared-key *****
 peer-id-validate nocheck
 isakmp keepalive threshold 30 retry 5

tunnel-group x.x.x.x type ipsec-l2l
tunnel-group x.x.x.x ipsec-attributes
 pre-shared-key *****
 isakmp keepalive threshold 30 retry 5

tunnel-group ravpn type remote-access
tunnel-group ravpn general-attributes
 address-pool ip-pool-ravpn
 authentication-server-group Edirectory
 default-group-policy ravpn
tunnel-group ravpn ipsec-attributes
 pre-shared-key *****
 isakmp keepalive threshold 30 retry 2

tunnel-group-map default-group DefaultL2LGroup

Existem vários grupos de túneis para os túneis "estáticos" (conforme o exemplo xxxx acima). Os usuários de acesso remoto acessam o grupo de túneis "ravpn" e os dinâmicos correspondem ao "DefaultL2LGroup". O PSK não é o mesmo entre estes.

Sugiro criar um segundo grupo de túneis de acesso remoto para todos os usuários de acesso remoto. Comece a migrá-los, um por um e, quando terminar, você pode excluir o Grupo L2L padrão existente ou alterar o PSK.

Se você encontrar alguns usuários que não desejam alterar, poderá impor uma versão específica do VPN Client e informá-los de que está fazendo uma grande atualização de segurança.

Normalmente, os usuários remotos da VPN precisam apenas de duas linhas no mapa criptográfico dinâmico que permite a conexão correta. Algo assim:

mapa dinâmico criptográfico DYN_CRY_MAP 65535 conjunto de transformação ESP-AES-128-SHA

mapa de criptografia OUTSIDE_map 65535 dinâmico ipsec-isakmp DYN_CRY_MAP

Isso pressupõe que você já tenha o conjunto de transformações correspondente apropriado especificado.

Suas sub-redes VPN de usuário remoto não precisam ser especificadas no mapa de criptografia, pois são pontos de extremidade dinâmicos. O ASA sabe disso e ajusta as tabelas de criptografia de acordo. Seus terminais L2L dinâmicos também não precisam ser especificados no mapa criptográfico e funcionarão da mesma maneira. Além disso, um "recurso" é que a última das duas linhas acima DEVE ser aplicada no final do seu mapa de criptografia. Você já o tem lá, mas só queria que você soubesse.

Esta linha é o que permite que a Fase 1 se conecte a partir de um terminal L2L dinâmico:

ipsec-atributos DefaultL2LGroup do grupo de túneis

 Chave Pré-Compartilhada *****

 verificação de id de ponto-validação

 limiar de manutenção de atividade isakmp 30 nova tentativa 5

A fase 2 é tratada pelas entradas do seu mapa criptográfico.

Receio que a maneira mais fácil e eficaz de fazer isso seja alterar o PSK no grupo de túneis DefaultL2LGroup e alterá-lo em todos os dispositivos que você ainda deseja conectar. Como são pontos de extremidade dinâmicos, você não pode realmente filtrar por IP na interface externa e não tem controle sobre eles estabelecendo um túnel se eles conhecem o PSK.

Se você tiver alguma dúvida, não hesite em perguntar.

Ian

@aleks - Se você sabe quais dispositivos L2L você não deseja mais permitir e conhece seus intervalos de IP privados, não pode negar esses IPs privados na sua ACL de entrada (a aplicada à interface externa do seu ASA). Isso pode não impedir a instalação da Fase 2, mas com certeza não permitiria a passagem do tráfego. Apenas um pensamento (deparei-me com essa pergunta enquanto pesquisava um assunto diferente).