Cisco ASA: Activating The AnyConnect License
How to activate an anyconnect mobile license key on the Cisco ASA.
ASA(config)# activation-key 9f9k7747 38hghfd5 kf74jhtr 9ceffc1c 7764e4a6
Validating activation key. This may take a few minutes...
Licensed features for this platform:
Maximum Physical Interfaces : Unlimited
Maximum VLANs : 150
Inside Hosts : Unlimited
Failover : Active/Active
VPN-DES : Enabled
VPN-3DES-AES : Enabled
Security Contexts : 2
GTP/GPRS : Disabled
SSL VPN Peers : 2
Total VPN Peers : 750
Shared License : Disabled
AnyConnect for Mobile : Enabled
AnyConnect for Cisco VPN Phone : Disabled
AnyConnect Essentials : Disabled
Advanced Endpoint Assessment : Disabled
UC Phone Proxy Sessions : 2
Total UC Proxy Sessions : 2
Botnet Traffic Filter : Disabled
This platform has an ASA 5520 VPN Plus license.
Both running and flash activation keys were updated with the requested key.
ASA(config)#
ASA(config)# activation-key 9f9k7747 38hghfd5 kf74jhtr 9ceffc1c 7764e4a6
Validating activation key. This may take a few minutes...
Licensed features for this platform:
Maximum Physical Interfaces : Unlimited
Maximum VLANs : 150
Inside Hosts : Unlimited
Failover : Active/Active
VPN-DES : Enabled
VPN-3DES-AES : Enabled
Security Contexts : 2
GTP/GPRS : Disabled
SSL VPN Peers : 2
Total VPN Peers : 750
Shared License : Disabled
AnyConnect for Mobile : Enabled
AnyConnect for Cisco VPN Phone : Disabled
AnyConnect Essentials : Disabled
Advanced Endpoint Assessment : Disabled
UC Phone Proxy Sessions : 2
Total UC Proxy Sessions : 2
Botnet Traffic Filter : Disabled
This platform has an ASA 5520 VPN Plus license.
Both running and flash activation keys were updated with the requested key.
ASA(config)#
Cisco ASA: 5505 ASA Config Template
Below is a template I created while doing an ASA 5505 (directly out of box) for a remote site. It had one VPN and the rest was a just plane Jane config. Below is my template for such a config. Its a pre8.3 config. Make sure you upgrade something like this before you send it onsite:
ASA(config)# username shane pass password
ASA(config)# enable pass apasswordthatissecret
ASA(config)# hostname ASA
ASA(config)# aaa authentication ssh con LOCAL
ASA(config)# crypto key generate rsa mod 1024
INFO: The name for the keys will be: <Default-RSA-Key>
Keypair generation process begin. Please wait...
ASA(config)# ssh 0.0.0.0 0.0.0.0 outside
WARNING: This command will not take effect until interface 'outside' has been assigned an IPv4 address
ASA(config)# route outside 0.0.0.0 0.0.0.0 7.8.9.106
ASA(config)# int vlan 2
ASA(config-if)# ip add 7.8.9.105 255.255.255.252
ASA(config-if)# no shut
ASA(config)# no dhcpd enable inside
ASA(config)# no dhcpd address 10.10.1.5-10.10.1.254 inside
ASA(config)#
ASA(config)# no dhcpd enable inside
ASA(config)# no dhcpd address 10.10.1.5-10.10.1.254 inside
ASA(config)# interface Vlan1
ASA(config-if)# no ip add
ASA(config-if)# ip add 10.10.199.1 255.255.255.0
ASA(config-if)# no shut
ASA(config-if)# route inside 10.10.4.0 255.255.255.0 10.10.199.2
ASA(config)# route inside 10.10.14.0 255.255.255.0 10.10.199.2
ASA(config)#
ASA(config)# aaa authentication serial console LOCAL
ASA(config)# crypto isakmp policy 10
ASA(config-isakmp-policy)# authentication pre-share
ASA(config-isakmp-policy)# encryption aes-256
ASA(config-isakmp-policy)# hash sha
ASA(config-isakmp-policy)# group 2
ASA(config-isakmp-policy)# lifetime 86400
ASA(config-isakmp-policy)# crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
ASA(config)# access-list 2HQ permit ip 10.10.4.0 255.255.255.0 10.10.2.0 255.255.255.0
ASA(config)# access-list 2HQ permit ip 10.10.14.0 255.255.255.0 10.10.12.0 255.255.255.0
ASA(config)# access-list 2HQ permit ip 10.10.14.0 255.255.255.0 10.10.13.0 255.255.255.0
ASA(config)# access-list 2HQ permit ip 10.10.14.0 255.255.255.0 10.10.11.0 255.255.255.0
ASA(config)# access-list nonat permit ip 10.10.4.0 255.255.255.0 10.10.2.0 255.255.255.0
ASA(config)# access-list nonat permit ip 10.10.14.0 255.255.255.0 10.10.12.0 255.255.255.0
ASA(config)# access-list nonat permit ip 10.10.14.0 255.255.255.0 10.10.13.0 255.255.255.0
ASA(config)# access-list nonat permit ip 10.10.14.0 255.255.255.0 10.10.11.0 255.255.255.0
ASA(config)# nat (inside) 0 access-list nonat
ASA(config)# tunnel-group 20.30.40.55 type ipsec-l2l
ASA(config)# tunnel-group 20.30.40.55 ipsec-attributes
ASA(config-tunnel-ipsec)# pre-shared-key veryprivatevpnkeynothisisnotwhatiuse
ASA(config-tunnel-ipsec)# exit
ASA(config)# crypto map outside_map 10 match address 2HQ
ASA(config)# crypto map outside_map 10 set peer 20.30.40.55
ASA(config)# crypto map outside_map 10 set transform-set ESP-3DES-SHA
ASA(config)# crypto map outside_map interface outside
ASA(config)# crypto isakmp enable outside
ASA(config)# username shane pass password
ASA(config)# enable pass apasswordthatissecret
ASA(config)# hostname ASA
ASA(config)# aaa authentication ssh con LOCAL
ASA(config)# crypto key generate rsa mod 1024
INFO: The name for the keys will be: <Default-RSA-Key>
Keypair generation process begin. Please wait...
ASA(config)# ssh 0.0.0.0 0.0.0.0 outside
WARNING: This command will not take effect until interface 'outside' has been assigned an IPv4 address
ASA(config)# route outside 0.0.0.0 0.0.0.0 7.8.9.106
ASA(config)# int vlan 2
ASA(config-if)# ip add 7.8.9.105 255.255.255.252
ASA(config-if)# no shut
ASA(config)# no dhcpd enable inside
ASA(config)# no dhcpd address 10.10.1.5-10.10.1.254 inside
ASA(config)#
ASA(config)# no dhcpd enable inside
ASA(config)# no dhcpd address 10.10.1.5-10.10.1.254 inside
ASA(config)# interface Vlan1
ASA(config-if)# no ip add
ASA(config-if)# ip add 10.10.199.1 255.255.255.0
ASA(config-if)# no shut
ASA(config-if)# route inside 10.10.4.0 255.255.255.0 10.10.199.2
ASA(config)# route inside 10.10.14.0 255.255.255.0 10.10.199.2
ASA(config)#
ASA(config)# aaa authentication serial console LOCAL
ASA(config)# crypto isakmp policy 10
ASA(config-isakmp-policy)# authentication pre-share
ASA(config-isakmp-policy)# encryption aes-256
ASA(config-isakmp-policy)# hash sha
ASA(config-isakmp-policy)# group 2
ASA(config-isakmp-policy)# lifetime 86400
ASA(config-isakmp-policy)# crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
ASA(config)# access-list 2HQ permit ip 10.10.4.0 255.255.255.0 10.10.2.0 255.255.255.0
ASA(config)# access-list 2HQ permit ip 10.10.14.0 255.255.255.0 10.10.12.0 255.255.255.0
ASA(config)# access-list 2HQ permit ip 10.10.14.0 255.255.255.0 10.10.13.0 255.255.255.0
ASA(config)# access-list 2HQ permit ip 10.10.14.0 255.255.255.0 10.10.11.0 255.255.255.0
ASA(config)# access-list nonat permit ip 10.10.4.0 255.255.255.0 10.10.2.0 255.255.255.0
ASA(config)# access-list nonat permit ip 10.10.14.0 255.255.255.0 10.10.12.0 255.255.255.0
ASA(config)# access-list nonat permit ip 10.10.14.0 255.255.255.0 10.10.13.0 255.255.255.0
ASA(config)# access-list nonat permit ip 10.10.14.0 255.255.255.0 10.10.11.0 255.255.255.0
ASA(config)# nat (inside) 0 access-list nonat
ASA(config)# tunnel-group 20.30.40.55 type ipsec-l2l
ASA(config)# tunnel-group 20.30.40.55 ipsec-attributes
ASA(config-tunnel-ipsec)# pre-shared-key veryprivatevpnkeynothisisnotwhatiuse
ASA(config-tunnel-ipsec)# exit
ASA(config)# crypto map outside_map 10 match address 2HQ
ASA(config)# crypto map outside_map 10 set peer 20.30.40.55
ASA(config)# crypto map outside_map 10 set transform-set ESP-3DES-SHA
ASA(config)# crypto map outside_map interface outside
ASA(config)# crypto isakmp enable outside
Cisco ASA: Configuring Redundant VPN Configuration On The Remote End
I have a customer where voice services is a high priority. They are a hosted customer of ours, and the customer asked me about VPN failover. They have two ISPs at their site. I have two locations for my hosted voice. But for this scenario, we want them to reach one site in particular. So on my Cisco ASA that Im using at this point for VPN connections, I'm going to configure two tunnel groups. One for ISP 1 IP address and one for ISP 2 IP address. Its the normal VPN config on the ASA with one exception. The exception is below. See line two. It has two IP addresses in that command instead of only one. The first is the primary. The second is the secondary. Its a pretty easy setup. In fact, most of the work is done on the remote end of the VPN.
crypto map outside_map 110 match address 190
crypto map outside_map 110 set peer 12.16.6.154 12.15.22.29
crypto map outside_map 110 set ikev1 transform-set ESP-3DES-MD5
crypto map outside_map 110 match address 190
crypto map outside_map 110 set peer 12.16.6.154 12.15.22.29
crypto map outside_map 110 set ikev1 transform-set ESP-3DES-MD5
Cisco Pix 501: Password Recovery Procedure
Can you believe that I had to do this??? I was asked to put in a Cisco Pix 501 for an internet connection. Yes, a Pix. Oh well. I didnt know the password, so I had to do a recovery. I downloaded a file from Cisco (or somewhere) and went through the process below. Have a TFTP server ready.
CISCO SYSTEMS PIX-501
Embedded BIOS Version 4.3.200 07/31/01 15:58:22.08
Compiled by morlee
16 MB RAM
PCI Device Table.
Bus Dev Func VendID DevID Class Irq
00 00 00 1022 3000 Host Bridge
00 11 00 8086 1209 Ethernet 9
00 12 00 8086 1209 Ethernet 10
Cisco Secure PIX Firewall BIOS (4.2) #6: Mon Aug 27 15:09:54 PDT 2001
Platform PIX-501
Flash=E28F640J3 @ 0x3000000
Use BREAK or ESC to interrupt flash boot.
Use SPACE to begin flash boot immediately.
Flash boot interrupted.
0: i8255X @ PCI(bus:0 dev:17 irq:9 )
1: i8255X @ PCI(bus:0 dev:18 irq:10)
Using 1: i82557 @ PCI(bus:0 dev:18 irq:10), MAC: 0013.c340.f24f
Use ? for help.
monitor> address 10.10.10.2
address 10.10.10.2
monitor> server 10.10.10.1
server 10.10.10.1
monitor> file np63.bin
file np63.bin
monitor> tftp
tftp np63.bin@10.10.10.1.....................................................................................................................................................................................
Received 92160 bytes
Cisco Secure PIX Firewall password tool (3.0) #0: Thu Jul 17 08:01:09 PDT 2003
Flash=E28F640J3 @ 0x3000000
BIOS Flash=E28F640J3 @ 0xD8000
Do you wish to erase the passwords? [yn] y
The following lines will be removed from the configuration:
enable password Zo5xMCqMemyT4GaK encrypted
passwd Zo5xMCqMemyT4GaK encrypted
Do you want to remove the commands listed above from the configuration? [yn] y
Passwords and aaa commands have been erased.
Rebooting...
CISCO SYSTEMS PIX-501
Embedded BIOS Version 4.3.200 07/31/01 15:58:22.08
Compiled by morlee
16 MB RAM
PCI Device Table.
Bus Dev Func VendID DevID Class Irq
00 00 00 1022 3000 Host Bridge
00 11 00 8086 1209 Ethernet 9
00 12 00 8086 1209 Ethernet 10
Cisco Secure PIX Firewall BIOS (4.2) #6: Mon Aug 27 15:09:54 PDT 2001
Platform PIX-501
Flash=E28F640J3 @ 0x3000000
Use BREAK or ESC to interrupt flash boot.
Use SPACE to begin flash boot immediately.
Flash boot interrupted.
0: i8255X @ PCI(bus:0 dev:17 irq:9 )
1: i8255X @ PCI(bus:0 dev:18 irq:10)
Using 1: i82557 @ PCI(bus:0 dev:18 irq:10), MAC: 0013.c340.f24f
Use ? for help.
monitor> address 10.10.10.2
address 10.10.10.2
monitor> server 10.10.10.1
server 10.10.10.1
monitor> file np63.bin
file np63.bin
monitor> tftp
tftp np63.bin@10.10.10.1.....................................................................................................................................................................................
Received 92160 bytes
Cisco Secure PIX Firewall password tool (3.0) #0: Thu Jul 17 08:01:09 PDT 2003
Flash=E28F640J3 @ 0x3000000
BIOS Flash=E28F640J3 @ 0xD8000
Do you wish to erase the passwords? [yn] y
The following lines will be removed from the configuration:
enable password Zo5xMCqMemyT4GaK encrypted
passwd Zo5xMCqMemyT4GaK encrypted
Do you want to remove the commands listed above from the configuration? [yn] y
Passwords and aaa commands have been erased.
Rebooting...
Cisco ASA: Troubleshooting With Logs
I was having to troubleshoot a VPN between a Check Point and an ASA the other day. I came up with this message in the ASA logs:
%ASA-7-713222: Group = 5.8.15.51, IP = 5.8.15.51, Static Crypto Map check, map = BHM, seq = 30, ACL does not match proxy IDs src:5.8.15.51 dst:192.168.2.10
%ASA-7-713221: Group = 5.8.15.51, IP = 5.8.15.51, Static Crypto Map check, checking map = BHM, seq = 40...
It appears that the Check Point is trying to use the public address instead of the non-NAT'ed address. My point here is that the ASA logs are very important for troubleshooting issues. Maybe you can look at the config and just find the solution. Maybe you need the logs. Either way, setting the appropriate log levels in troubleshooting is important. It helped me determine that the ASA was fine and that the Check Point needed some work.
%ASA-7-713222: Group = 5.8.15.51, IP = 5.8.15.51, Static Crypto Map check, map = BHM, seq = 30, ACL does not match proxy IDs src:5.8.15.51 dst:192.168.2.10
%ASA-7-713221: Group = 5.8.15.51, IP = 5.8.15.51, Static Crypto Map check, checking map = BHM, seq = 40...
It appears that the Check Point is trying to use the public address instead of the non-NAT'ed address. My point here is that the ASA logs are very important for troubleshooting issues. Maybe you can look at the config and just find the solution. Maybe you need the logs. Either way, setting the appropriate log levels in troubleshooting is important. It helped me determine that the ASA was fine and that the Check Point needed some work.
Packet Capture: More Proving What is There
More packet captures on the ASA. Sometimes you just have to know how far the packet is getting. This time its across a VPN. I need to see what the packets actually are getting across, and not just look at the counters. Im trying to see if one DNS server is sending traffic back. Yep, the 192.168.1.100 DNS server is sending traffic back. I see this on the inside interface of the ASA. Looks good.
ASA# sh capture
capture capin type raw-data access-list 191 interface inside [Capturing - 28987 bytes]
ASA# sh capture capin
143 packets captured
1: 14:03:29.546663 192.168.1.100.53 > 192.168.5.64.54137: udp 373
2: 14:24:47.714761 192.168.5.64.61552 > 192.168.1.100.53: udp 55
3: 14:24:47.717064 192.168.1.100.53 > 192.168.5.64.61552: udp 55
4: 14:24:47.931943 192.168.5.64.53348 > 192.168.1.100.53: udp 35
5: 14:24:47.932340 192.168.1.100.53 > 192.168.5.64.53348: udp 90
6: 14:24:47.970271 192.168.5.64.50397 > 192.168.1.100.53: udp 32
7: 14:24:47.970683 192.168.1.100.53 > 192.168.5.64.50397: udp 79
8: 14:24:48.015196 192.168.5.64.63238 > 192.168.1.100.53: udp 45
9: 14:24:48.015853 192.168.1.100.53 > 192.168.5.64.63238: udp 98
10: 14:24:48.059841 192.168.5.64.64395 > 192.168.1.100.53: udp 39
11: 14:24:48.090159 192.168.1.100.53 > 192.168.5.64.64395: udp 39
12: 14:24:48.135307 192.168.5.64.62142 > 192.168.1.100.53: udp 42
13: 14:24:48.136025 192.168.1.100.53 > 192.168.5.64.62142: udp 111
14: 14:24:48.172140 192.168.5.64.52743 > 192.168.1.100.53: udp 35
15: 14:24:48.174566 192.168.1.100.53 > 192.168.5.64.52743: udp 110
...
143 packets shown
ASA#
ASA# sh capture
capture capin type raw-data access-list 191 interface inside [Capturing - 28987 bytes]
ASA# sh capture capin
143 packets captured
1: 14:03:29.546663 192.168.1.100.53 > 192.168.5.64.54137: udp 373
2: 14:24:47.714761 192.168.5.64.61552 > 192.168.1.100.53: udp 55
3: 14:24:47.717064 192.168.1.100.53 > 192.168.5.64.61552: udp 55
4: 14:24:47.931943 192.168.5.64.53348 > 192.168.1.100.53: udp 35
5: 14:24:47.932340 192.168.1.100.53 > 192.168.5.64.53348: udp 90
6: 14:24:47.970271 192.168.5.64.50397 > 192.168.1.100.53: udp 32
7: 14:24:47.970683 192.168.1.100.53 > 192.168.5.64.50397: udp 79
8: 14:24:48.015196 192.168.5.64.63238 > 192.168.1.100.53: udp 45
9: 14:24:48.015853 192.168.1.100.53 > 192.168.5.64.63238: udp 98
10: 14:24:48.059841 192.168.5.64.64395 > 192.168.1.100.53: udp 39
11: 14:24:48.090159 192.168.1.100.53 > 192.168.5.64.64395: udp 39
12: 14:24:48.135307 192.168.5.64.62142 > 192.168.1.100.53: udp 42
13: 14:24:48.136025 192.168.1.100.53 > 192.168.5.64.62142: udp 111
14: 14:24:48.172140 192.168.5.64.52743 > 192.168.1.100.53: udp 35
15: 14:24:48.174566 192.168.1.100.53 > 192.168.5.64.52743: udp 110
...
143 packets shown
ASA#
Cisco ASA: VPN Lifetime Count
Did you know that VPNs resend their information after a certain amount of time? Yep, its true. After the lifetime expires, they resend their SA info. You can see the remaining times when you do a show crypto isakmp sa detail on the Cisco ASA.
asa# sh cryp isa sa det
Active SA: 2
Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 2
1 IKE Peer: 4.4.4.164
Type : L2L Role : initiator
Rekey : no State : MM_ACTIVE
Encrypt : 3des Hash : SHA
Auth : preshared Lifetime: 86400
Lifetime Remaining: 42302
2 IKE Peer: 5.5.5.104
Type : user Role : responder
Rekey : no State : AM_ACTIVE
Encrypt : aes Hash : SHA
Auth : preshared Lifetime: 86400
Lifetime Remaining: 28616
asa# sh cryp isa sa det
Active SA: 2
Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 2
1 IKE Peer: 4.4.4.164
Type : L2L Role : initiator
Rekey : no State : MM_ACTIVE
Encrypt : 3des Hash : SHA
Auth : preshared Lifetime: 86400
Lifetime Remaining: 42302
2 IKE Peer: 5.5.5.104
Type : user Role : responder
Rekey : no State : AM_ACTIVE
Encrypt : aes Hash : SHA
Auth : preshared Lifetime: 86400
Lifetime Remaining: 28616
Cisco ASA: Capture ASP-DROP Command
There are times when you just have to take advantage of some cool troubleshooting tools that these companies put out. Cisco has a pretty cool CLI command that I like when I just cant seem to see the config problem with my eyes. Its the below capture command. I used this when trying to troubleshoot why I couldnt get packets across the VPN. I could see it on the interface in a packet capture, but going back, it was getting dropped. How do I know that? First, my packet capture told me when I looked on the inside interface of the ASA. I saw it. I also saw the packet coming back on the inside interface as well. But, it turns out that there was an ACL dropping it, as shown below. Once I saw this, I immediately took off the ACL (to test) and the packets went through the VPN just fine after that. Then, I modified the ACL to resolve the issue.
ASA# capture asp-drop type asp-drop acl-drop
ASA# show capture asp-drop
32 packets captured
...
27: 14:05:42.770162 802.1Q vlan#15 P0 10.10.15.25 > 10.10.50.127: icmp: echo reply Drop-reason: (acl-drop) Flow is denied by configured rule
...
32 packets shown
ASA#
ASA# capture asp-drop type asp-drop acl-drop
ASA# show capture asp-drop
32 packets captured
...
27: 14:05:42.770162 802.1Q vlan#15 P0 10.10.15.25 > 10.10.50.127: icmp: echo reply Drop-reason: (acl-drop) Flow is denied by configured rule
...
32 packets shown
ASA#
Cisco ASA: "Removing peer from peer table failed, no match!" For VPN
My customer says that the VPN to a certain customer of theirs is down on the ASA. Nothing change on our side. So the obvious answer is that something changed on their side. So I get him to run a constant ping to the remote side network where he is trying to get to. But, I see the below message when doing a "show cryp isa"
6 IKE Peer: 4.2.26.166
Type : user Role : initiator
Rekey : no State : MM_WAIT_MSG2
I also see this in the logs:
Nov 09 11:02:44 [IKEv1]: IP = 4.2.26.166, Removing peer from peer table failed, no match!
Nov 09 11:02:44 [IKEv1]: IP = 4.2.26.166, Error: Unable to remove PeerTblEntry
As it turns out, their Internet connection is down. When it came back up, so did the VPN.
6 IKE Peer: 4.2.26.166
Type : user Role : initiator
Rekey : no State : MM_WAIT_MSG2
I also see this in the logs:
Nov 09 11:02:44 [IKEv1]: IP = 4.2.26.166, Removing peer from peer table failed, no match!
Nov 09 11:02:44 [IKEv1]: IP = 4.2.26.166, Error: Unable to remove PeerTblEntry
As it turns out, their Internet connection is down. When it came back up, so did the VPN.
Cisco ASA: Allowing ICMP Through The Firewall
I cant believe I have not done this post yet. I had a customer call me up on an ASA I configured remotely. He went up to put it in place and told me that although he could get on the Internet, he could not ping anything beyond the firewall. No worries. We can setup a policy for that. This should do it:
ASA(config)#
ASA(config)# class-map icmp-class
ASA(config-cmap)# match default-inspection-traffic
ASA(config-cmap)# exit
ASA(config)# policy-map icmp_policy
ASA(config-pmap)# class icmp-class
ASA(config-pmap-c)# inspect icmp
ASA(config-pmap-c)# exit
ASA(
ASA(config)#
ASA(config)# class-map icmp-class
ASA(config-cmap)# match default-inspection-traffic
ASA(config-cmap)# exit
ASA(config)# policy-map icmp_policy
ASA(config-pmap)# class icmp-class
ASA(config-pmap-c)# inspect icmp
ASA(config-pmap-c)# exit
ASA(
Cisco Firewall: How To Copy The Config To A TFTP Location Directly
Here is a quick post on how to send the config to a TFTP in CLI on the ASA. I typically just log it in my Tera Term session. But this works too.
ASA# copy running-config tftp
Source filename [running-config]?
Address or name of remote host []? 10.1.1.30
Destination filename [running-config]?
Cryptochecksum: 0d26cd13 fe9f6f96 d8c80803 2ff55825
!!!!!!!!!!!!
46613 bytes copied in 3.330 secs (15537 bytes/sec)
ASA# copy running-config tftp
Source filename [running-config]?
Address or name of remote host []? 10.1.1.30
Destination filename [running-config]?
Cryptochecksum: 0d26cd13 fe9f6f96 d8c80803 2ff55825
!!!!!!!!!!!!
46613 bytes copied in 3.330 secs (15537 bytes/sec)
ASA#config-pmap)# service-p icmp_policy interface outside
Firewalls And NAT'ing And The Traveling Packet
Its an interesting thing to me, that NAT'ing takes place before routing does on most firewalls. So, if your public IP address space was 10.10.10.X/24, and you decided that you wanted to NAT your internal 192.168.1.10 server to the public IP address of 10.4.4.4, you could. Now, you might start to think that "you cant do that" because your 10.4.4.4 is not on your 10.10.10.X/24 address space, right? Well, actually, that is wrong. You actually CAN have a public IP address that is not on your public IP range and have it NAT through to your internal server. Routing at the upstream router certainly poses a problem, but if a packet can make it to your firewall, then you can NAT your traffic to any public IP address you want to, even if its not part of your IP range on your firewall interface.
I actually went through this recently on a certain problem I was having on a Check Point firewall. You see, it was the same thing really. I had a public range of, lets say, 40.40.40.0/25. This gives us 126 usable IP addresses (1-126). However, in the config, they had some NATs that were outside of that range. Now, just so you know, they actually owned the whole /24 of 40.40.40.0. But, on the firewall interface, they had split up this subnet and were not using anything above this range (40.40.40.0/25).
In our example, they had a static NAT translation of 40.40.40.200 pointing to a webserver inside the network at 192.168.1.200. I thought that since it was not on the subnet of the public facing NIC on the firewall, the firewall would try to route it out its default gateway (the upstream router), which would try to send it back and ultimately the TTL would hit 0 and the packet would drop. But, this is NOT what happens. What actually happens is that NAT is checked FIRST.
Below, I have the best explanation (from Cisco) of the process the packet actually takes going through the firewall from the outside to the inside. This process also applies to Check Point as well. Notice that first, the ACL is checked to see if the packet is allowed, then NAT. Notice its not until step 7 and 8 where routing comes into place. Its a very interesting process for sure. Take a walk through the steps below. Its a really good read through.
Steps
1. The packet is reached at the ingress interface. Once the packet reaches the internal buffer of the interface, the input counter of the interface is incremented by one.
2. Cisco ASA first looks at its internal connection table details in order to verify if this is a current connection. If the packet flow matches a current connection, then the Access Control List (ACL) check is bypassed and the packet is moved forward.If packet flow does not match a current connection, then the TCP state is verified. If it is a SYN packet or UDP (User Datagram Protocol) packet, then the connection counter is incremented by one and the packet is sent for an ACL check. If it is not a SYN packet, the packet is dropped and the event is logged.
3. The packet is processed as per the interface ACLs. It is verified in sequential order of the ACL entries and if it matches any of the ACL entries, it moves forward. Otherwise, the packet is dropped and the information is logged. The ACL hit count is incremented by one when the packet matches the ACL entry.
4. The packet is verified for the translation rules. If a packet passes through this check, then a connection entry is created for this flow and the packet moves forward. Otherwise, the packet is dropped and the information is logged.
5. The packet is subjected to an Inspection Check. This inspection verifies whether or not this specific packet flow is in compliance with the protocol. Cisco ASA has a built-in inspection engine that inspects each connection as per its pre-defined set of application-level functionality. If it passed the inspection, it is moved forward. Otherwise, the packet is dropped and the information is logged.Additional security checks will be implemented if a Content Security (CSC) module is involved.
6. The IP header information is translated as per the Network Address Translation/ Port Address Translation (NAT/PAT) rule and checksums are updated accordingly. The packet is forwarded to Advanced Inspection and Prevention Security Services Module (AIP-SSM) for IPS related security checks when the AIP module is involved.
7. The packet is forwarded to the egress interface based on the translation rules. If no egress interface is specified in the translation rule, then the destination interface is decided based on the global route lookup.
8. On the egress interface, the interface route lookup is performed. Remember, the egress interface is determined by the translation rule that takes the priority.
9. Once a Layer 3 route has been found and the next hop identified, Layer 2 resolution is performed. The Layer 2 rewrite of the MAC header happens at this stage.
10. The packet is transmitted on the wire, and interface counters increment on the egress interface.
11. The packet is transmitted on the wire, and interface counters increment on the egress interface.
I actually went through this recently on a certain problem I was having on a Check Point firewall. You see, it was the same thing really. I had a public range of, lets say, 40.40.40.0/25. This gives us 126 usable IP addresses (1-126). However, in the config, they had some NATs that were outside of that range. Now, just so you know, they actually owned the whole /24 of 40.40.40.0. But, on the firewall interface, they had split up this subnet and were not using anything above this range (40.40.40.0/25).
In our example, they had a static NAT translation of 40.40.40.200 pointing to a webserver inside the network at 192.168.1.200. I thought that since it was not on the subnet of the public facing NIC on the firewall, the firewall would try to route it out its default gateway (the upstream router), which would try to send it back and ultimately the TTL would hit 0 and the packet would drop. But, this is NOT what happens. What actually happens is that NAT is checked FIRST.
Below, I have the best explanation (from Cisco) of the process the packet actually takes going through the firewall from the outside to the inside. This process also applies to Check Point as well. Notice that first, the ACL is checked to see if the packet is allowed, then NAT. Notice its not until step 7 and 8 where routing comes into place. Its a very interesting process for sure. Take a walk through the steps below. Its a really good read through.
Steps
1. The packet is reached at the ingress interface. Once the packet reaches the internal buffer of the interface, the input counter of the interface is incremented by one.
2. Cisco ASA first looks at its internal connection table details in order to verify if this is a current connection. If the packet flow matches a current connection, then the Access Control List (ACL) check is bypassed and the packet is moved forward.If packet flow does not match a current connection, then the TCP state is verified. If it is a SYN packet or UDP (User Datagram Protocol) packet, then the connection counter is incremented by one and the packet is sent for an ACL check. If it is not a SYN packet, the packet is dropped and the event is logged.
3. The packet is processed as per the interface ACLs. It is verified in sequential order of the ACL entries and if it matches any of the ACL entries, it moves forward. Otherwise, the packet is dropped and the information is logged. The ACL hit count is incremented by one when the packet matches the ACL entry.
4. The packet is verified for the translation rules. If a packet passes through this check, then a connection entry is created for this flow and the packet moves forward. Otherwise, the packet is dropped and the information is logged.
5. The packet is subjected to an Inspection Check. This inspection verifies whether or not this specific packet flow is in compliance with the protocol. Cisco ASA has a built-in inspection engine that inspects each connection as per its pre-defined set of application-level functionality. If it passed the inspection, it is moved forward. Otherwise, the packet is dropped and the information is logged.Additional security checks will be implemented if a Content Security (CSC) module is involved.
6. The IP header information is translated as per the Network Address Translation/ Port Address Translation (NAT/PAT) rule and checksums are updated accordingly. The packet is forwarded to Advanced Inspection and Prevention Security Services Module (AIP-SSM) for IPS related security checks when the AIP module is involved.
7. The packet is forwarded to the egress interface based on the translation rules. If no egress interface is specified in the translation rule, then the destination interface is decided based on the global route lookup.
8. On the egress interface, the interface route lookup is performed. Remember, the egress interface is determined by the translation rule that takes the priority.
9. Once a Layer 3 route has been found and the next hop identified, Layer 2 resolution is performed. The Layer 2 rewrite of the MAC header happens at this stage.
10. The packet is transmitted on the wire, and interface counters increment on the egress interface.
11. The packet is transmitted on the wire, and interface counters increment on the egress interface.
Below is Check Points explanation in the CP documentation. Very similar.
Cisco Firewall: What Is That "passwd" In CLI?
I was tasked to clear up an issue on an ASA running 9.4 code. The issue? There was a default password left on the ASA, that should be deleted out. In CLI, you will see a command "passwd ...". That is the default password for telnet and ssh. See from Cisco's documentation below:
The login password is used for Telnet and SSH connections. By default, the login password is "cisco." To change the password, enter the following command:
hostname(config)# {passwd | password} password
You can enter passwd or password. The password is a case-sensitive password of up to 16 alphanumeric and special characters. You can use any character in the password except a question mark or a space.
The login password is used for Telnet and SSH connections. By default, the login password is "cisco." To change the password, enter the following command:
hostname(config)# {passwd | password} password
You can enter passwd or password. The password is a case-sensitive password of up to 16 alphanumeric and special characters. You can use any character in the password except a question mark or a space.
The password is saved in the configuration in encrypted form, so you cannot view the original password after you enter it. Use the no password command to restore the password to the default setting.
Cisco ASA: How To Immediately Block An External IP From Coming Through Your Firewall
Have you ever had an intruder coming through your firewall, and you needed to block that IP address immediately? I recently saw this very thing coming through a Cisco ASA. Even though we didn't see this in our logs (still working on why this didn't happen), it was reported to us from our server team. And because we didn't see it coming through our log, we decided to do a packet capture on the ASA to verify that it was actually coming through. Well, the capture proved that it was. So, our immediate solution was to add this public IP address to our block list. However, because he was already coming through to a particular NAT translation (an internal server accessed from the outside), adding this in to the ACL did not work. Now this, to me, is unacceptable in a firewall! So as I'm writing this post, I think Ill do a post coming up on how the ASA works regarding this concept. I'm not sure its widely published.
Back to this post though. So I put the public IP address to be blocked and that did not stop them. So, what to do?
There is a command called "shun" on the ASA. Its intended to block the IP from coming through. So, after the packet capture, I verified with another command:
ASA# sho conn add 159.203.83.32
TCP outside 159.203.83.32:37044 inside 10.10.10.10:443, idle 0:00:00, bytes 903237461, flags UIOXB
You can see above, the connection is active. So lets shun it:
ASA# shun 159.203.83.32
Shun 159.203.83.32 added in context: single_vf
Shun 159.203.83.32 successful
Now to verify that its actually stopped. We did a show capture, to verify that the packet count was not increasing, as it was before:
ASA# sh capture
capture capin type raw-data access-list 189 interface outside [Buffer Full - 524058 bytes]
ASA# sh capture
capture capin type raw-data access-list 189 interface outside [Buffer Full - 524058 bytes]
ASA# sh capture
capture capin type raw-data access-list 189 interface outside [Buffer Full - 524058 bytes]
Done, shunned for now.
Back to this post though. So I put the public IP address to be blocked and that did not stop them. So, what to do?
There is a command called "shun" on the ASA. Its intended to block the IP from coming through. So, after the packet capture, I verified with another command:
ASA# sho conn add 159.203.83.32
TCP outside 159.203.83.32:37044 inside 10.10.10.10:443, idle 0:00:00, bytes 903237461, flags UIOXB
You can see above, the connection is active. So lets shun it:
ASA# shun 159.203.83.32
Shun 159.203.83.32 added in context: single_vf
Shun 159.203.83.32 successful
Now to verify that its actually stopped. We did a show capture, to verify that the packet count was not increasing, as it was before:
ASA# sh capture
capture capin type raw-data access-list 189 interface outside [Buffer Full - 524058 bytes]
ASA# sh capture
capture capin type raw-data access-list 189 interface outside [Buffer Full - 524058 bytes]
ASA# sh capture
capture capin type raw-data access-list 189 interface outside [Buffer Full - 524058 bytes]
Done, shunned for now.
Cisco ASA: Why Adding To Your ACL Does Not Block The Connection You Want To Block
In yesterday's post about shunning in the ASA, I said something about how I added an IP address to the ACL to block an IP address from getting through to a server. I also mentioned that because the connection was already active, that adding his IP into the ACL did not stop him from coming through at that point. So, why?
There is this concept in the ASA called "slow path" and "fast path". When a connection is initiated, the ASA will use the "slow path", which means it checks the packet against the incoming ACL that is in place, to verify if its allowed or not. If allowed through, then the packets from then on take the "fast path" for that particular connection. Taking the "fast path" means that the packets are no longer checked against the ACL to verify if its allowed or not, allowing for better performance. However, I personally am not a fan of this method. My stance would be to add performance to the gear, instead of skimping on security for the sake of performance.
There is this concept in the ASA called "slow path" and "fast path". When a connection is initiated, the ASA will use the "slow path", which means it checks the packet against the incoming ACL that is in place, to verify if its allowed or not. If allowed through, then the packets from then on take the "fast path" for that particular connection. Taking the "fast path" means that the packets are no longer checked against the ACL to verify if its allowed or not, allowing for better performance. However, I personally am not a fan of this method. My stance would be to add performance to the gear, instead of skimping on security for the sake of performance.
Cisco ASA: Dropping Remote Access After A Certain Timeframe
Quick post here, but you really should drop remote-access connections after a certain time. Or they will stay connected forever. Here is how to set it to 12 hours.
ASA/act/pri# config t
ASA/act/pri(config)# group-policy DfltGrpPolicy attributes
ASA/act/pri(config-group-
ASA/act/pri(config-group-
ASA/act/pri(config)# exit
ASA/act/pri# wr men
VPN: IKEv1 And IKEv2
While configuring some VPNs today, the question came up about using IKEv1 vs IKEv2. I don't want to get into the technical details about the differences in the two (I'll do that in the next post), but I do want you to know that the two are not compatible with each other. So if you use IKEv2 on one side, you have to use it in the other side.
Cisco Firewall: How A Cisco ASA L2 Firewall Works (Transparent Mode)
I'd like to explain how the Cisco ASA L2 firewall works. I find that most people really don't understand how this works, so I'm going to attempt to explain as best I can.
How A L2 Firewall Works (Transparent Mode)
How A L2 Firewall Works (Transparent Mode)
As a packet comes into the Aggregation switch, destined for Server IP address of 10.10.1.30, that packet is destined for Vlan1273 on the Agg switch. As the Agg switch sends out an ARP request to get the MAC address of the Server 10.10.1.30, the ARP is sent out all ports with Vlan 1273 configured. As the ARP comes into the ASA, it then broadcasts over across its bridge-group 30, and the destination is then within the Layer2 Vlan of 273. It traverses back to the Agg switch, in Vlan 273, and all ports with Vlan 273. The Leaf switch sees the ARP request, and forwards it out all ports with Vlan 273 (L2) on the Leaf switch. The server gets the ARP request, and responds with its MAC address, traversing back across the Leaf switch, through the Agg switch on Vlan 273, and to the ASA on Vlan 273. When the ASA receives the ARP reply, it forwards it back across the bridge-group 30 to Vlan 1273, and on to the Agg switch in Vlan 1273. There is now two way communication, from Vlan 1273 across to Vlan 273, and vice versa.
Notice that in the ASA configuration, the ACL allows all traffic GLOBALLY, for simplicity for our example.
Meraki Install
I don't know that I've ever really commented on the Meraki installs that I've done. I did an install for a company out of Nashville recently. Meraki does make some things easy to configure. But it also leaves out some really important threat prevention features. I should probably do a comparison list between firewall vendors.
Referenence: https://www.shanekillen.com/search/label/Cisco%20Firewall
