11-03-2009 07:04 PM - edited 02-21-2020 04:22 PM
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?
11-04-2009 01:20 AM
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.
11-04-2009 02:15 AM
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?
11-04-2009 06:09 AM
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
11-04-2009 06:19 AM
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.
11-04-2009 06:28 AM
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
11-04-2009 07:02 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide