IPSec configuration on ASA running 8.2.1

cisco24x7 · ‎11-03-2009

outside IP address of this ASA is 129.174.1.13

no sysopt connection permit-vpn

no nat-control

crypto isakmp key cciesec address 1.1.1.1 no-xauth no-config

crypto isakmp key cciesec address 2.2.2.2 no-xauth no-config

crypto isakmp enable outside

crypto isakmp identity address

access-list 100 permit ip 192.168.1.0 255.255.255.0 172.16.1.0 255.255.255.0

access-list 101 permit ip 192.168.1.0 255.255.255.0 10.0.1.0 255.255.255.0

crypto isakmp policy 10

auth pre

hash sha

encr 3des

group 2

life 86400

crypto ipsec trans cciesec esp-3des esp-sha-hmac

crypto map vpn 10 ipsec-isakmp

crypto map vpn 10 set peer 1.1.1.1

crypto map vpn 10 set trans cciesec

crypto map vpn 10 match address 100

crypto map vpn 10 set security life sec 3600

crypto map vpn 10 set pfs group2

crypto map vpn 20 ipsec-isakmp

crypto map vpn 20 set peer 2.2.2.2

crypto map vpn 20 set trans cciesec

crypto map vpn 20 match address 101

crypto map vpn 20 set security life sec 3600

crypto map vpn 20 set pfs group2

crypto map vpn interface outside

access-list external permit icmp any any log

access-list external deny udp host 2.2.2.2 host 129.174.1.13 eq 500 log

access-list external deny udp host 2.2.2.2 host 129.174.1.13 eq 4500 log

access-list external deny esp host 2.2.2.2 host 129.174.1.13 log

access-list external permit ip any any log

access-group external in interface outside

With this configuration, can host 2.2.2.2 initiate IPSec with my ASA device?

If so, is there a way to block host 2.2.2.2 from initiating IPSec with this

ASA device? The solution must be done on the ASA itself and no-where else.

Can anyone help me?

Herbert Baerten · ‎11-04-2009

It's a bit of a strange question so I hope I'm interpreting it correctly (is it a CCIE lab prep exercise or something like that?).

The answer is yes, 2.2.2.2 can build a tunnel with this ASA if it knows the correct ISAKMP PSK (pre-shared key) [and assuming that ACL 101 exists and is the mirror of the crypto ACL on the peer].

So the ACL does not block traffic destined to the ASA itself (similarly you can also not block SSH traffic to the ASA itself, for that you use the "ssh" command).

To prevent 2.2.2.2 from establishing a tunnel:

- remove the PSK

- remove "crypto map vpn 20"

It will still be able to send ISAKMP packets, and the ASA will still process them, but ISAKMP phase 1 will fail because it does not have a PSK for this peer.

cisco24x7 · ‎11-04-2009

Thank you for your response. I would like to take the question a step further:

Assume that I can NOT remove the PSK and "crypto map vpn 20" on the ASA. Are there any alternative to block 2.2.2.2 from establishing VPN to the ASA? Furthermore, are there any ways to block any hosts from establish VPN to the ASA other than host 1.1.1.1? For example, with the configuration I described, it CAN be done on the IOS router.

I am asking this is because if the ASA code has VPN vulnerabilities in the code itself, someone can perform a DOS or DDOS on the ASA because the ASA is designed to accept ISAKMP packet from EVERYWHERE, unlike IOS router, the ACL applies to the external interface of the router can prevent this.

Is that an accurate assesment?

Herbert Baerten · ‎11-04-2009

Again I find the question very strange, why would you want to keep a PSK and a crypto map entry for a peer that you do not want to connect? It seems absurd...

Anyway, after thinking about this a bit more I realized that as of 8.0 you should be able to achieve what you want with CPP (control plane policing), i.e. the "control-plane" keyword in the "access-group" command, e.g.

access-list cplane extended permit icmp any any

access-list cplane extended deny udp host 2.2.2.2 interface outside eq isakmp

access-list cplane extended deny udp host 2.2.2.2 interface outside eq 4500

access-list cplane extended deny esp host 2.2.2.2 interface outside

access-list cplane extended permit ip any any

access-group cplane in interface outside control-plane

cisco24x7 · ‎11-04-2009

Does this mean that this ACL applies to BOTH traffics going TO the ASA and THROUGH ASA? In other words, let say if I have this ACL:

static (i,o) 129.174.1.20 192.168.1.20 netmask 255.255.255.255

access-list cciesec permit icmp any any log

access-list cciesec permit udp host 1.1.1.1 interface outside eq 500 log

access-list cciesec permit udp host 1.1.1.1 interface outside eq 4500 log

access-list cciesec outside permit esp host 1.1.1.1 interface outside log

access-list cciesec deny udp any any eq 500 log

access-list cciesec deny udp any any eq 4500 log

access-list cciesec deny esp any any log

access-list cciesec permit ip any any log

access-group cciesec in interface outside control-plane

Assuming that 129.174.1.20 is ftp,smtp,dns,http/https servers, does it mean that anyone from Internet can connect to this host on these services, and that only host 1.1.1.1 can initiate isakmp to the ASA.

Does that sound right? Thanks.

Herbert Baerten · ‎11-04-2009

No, sorry for not being clearer in my previous post (I'm doing this in between my regular work :)

You have 2 separate ACLs, one for through traffic, and one for to-the-box (control-plane) traffic:

access-list cplane extended permit udp host 1.1.1.1 any eq isakmp

access-list cplane extended permit udp host 1.1.1.1 any eq 4500

access-list cplane extended permit esp host 1.1.1.1 any

access-list through extended permit tcp any host 129.174.1.20 eq www

access-list through extended permit tcp any host 129.174.1.20 eq smtp

access-list through extended permit tcp any host 129.174.1.20 eq ftp

access-list through extended permit udp any host 129.174.1.20 eq domain

access-group cplane in interface outside control-plane

access-group through in interface outside

cisco24x7 · ‎11-04-2009

Ah I see. This must be a "new" feature in 8.x code right?

In this scenario, I can protect the ASA if it is directly connected to the Internet from being DoS if there are vulnerabilities in the ISAKMP protocol.

Thanks again.