Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

ASA behaviour

Hello,

I am wondering how ASA 8.4 would handle following situation:

1. IPSEC L2L tunnel is in place

2. "No sysopt connection permit-vpn" is used, ACLs applied to outside inbound for the remote VPN hosts to filter VPN traffic

3. Public IP addresses are used for crypto-domain on both ends of L2L VPN

What happens if a packet intended to be encrypted (source and destination IP addresses are part of crypto domain) arrives on the outside interface of ASA unencrypted? Will ASA drop it, having looked at the crypto map deciding that this packet should have arrived encrypted or just permit it looking at the outside ACL (not crypto one)?

Thanks!

Everyone's tags (3)
1 ACCEPTED SOLUTION

Accepted Solutions
VIP Purple

ASA behaviour

The ASA will drop that packet. If the packet matches the reverse crypto-definition it has to arrive in an encrypted form. After decryption the packet is compared to the outside-interface.

This old behaviour (no sysopt connection permit-vpn) ) had a security-problem as a malicious service-provider was able to send traffic into your network:

If you had dynamic branches you needed a dynamic crypto-map. The dynamic crypto-map was completed on connection-time of the branch with the crypto proxy-IDs. And on the outside ACL the traffic (typically from RFC1918 to RFC1918) the traffic was allowed.

If the VPN-tunnel was not up, the PIX was not aware of the crypto-definition. But the plaintext-communication was still allowed in the interface ACL. If the service-provider would route packets with the right addresses to the PIX, the traffic had beed accepted but that was never intended to be received in cleartext.

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

1 REPLY
VIP Purple

ASA behaviour

The ASA will drop that packet. If the packet matches the reverse crypto-definition it has to arrive in an encrypted form. After decryption the packet is compared to the outside-interface.

This old behaviour (no sysopt connection permit-vpn) ) had a security-problem as a malicious service-provider was able to send traffic into your network:

If you had dynamic branches you needed a dynamic crypto-map. The dynamic crypto-map was completed on connection-time of the branch with the crypto proxy-IDs. And on the outside ACL the traffic (typically from RFC1918 to RFC1918) the traffic was allowed.

If the VPN-tunnel was not up, the PIX was not aware of the crypto-definition. But the plaintext-communication was still allowed in the interface ACL. If the service-provider would route packets with the right addresses to the PIX, the traffic had beed accepted but that was never intended to be received in cleartext.

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

229
Views
0
Helpful
1
Replies
CreatePlease to create content