If you have recently tried to setup SSH access on a new ASA, it might not have worked the way you wanted. That is because the RSA keys need to be generated first. To do that:
crypto key generate rsa
asa(config)# crypto key generate rsa
INFO: The name for the keys will be:
Keypair generation process begin. Please wait…
And then configure SSH to be allowed from the inside interface:
ssh 0.0.0.0 0.0.0.0 inside
Now you will be able to login using the default username and password of pix/cisco, Or you can configure AAA and setup your own usernames. Doing this will make the pix username no longer work for SSH.
First, a username needs to be created:
username cisco password c1sc0
And then configure AAA:
aaa authentication ssh console LOCAL
Done!
I was working on an ASA config and ran into an interesting error. I needed to not perform NAT on the traffic from the inside LAN to the DMZ. I configured an access-list:
access-list InsideNoNAT_ACL extended permit ip 10.10.10.0 255.255.255.0 10.10.48.0 255.255.255.0
access-list InsideNoNAT_ACL extended permit ip 10.10.10.0 255.255.255.0 10.10.49.0 255.255.255.0
access-list InsideNoNAT_ACL extended permit ip 10.10.10.0 255.255.255.0 172.31.3.0 255.255.255.0
access-list InsideNoNAT_ACL extended permit ip 10.10.10.0 255.255.255.0 172.31.4.0 255.255.255.0
And then specified to not perform NAT:
nat (inside) 0 access-list InsideNoNAT_ACL
nat (inside) 1 0.0.0.0 0.0.0.0
I then needed to add another line to the InsideNoNAT_ACL, and that is where I received the error.
(config)#access-list InsideNoNAT_ACL permit 10.0.0.0 255.0.0.0 172.31.3.0 255.255.255.0
Unable to download NAT policy for ACE
All this error message is saying is that the new line in the access-list was not added to the active NAT table, but was added to the access-list. Upon doing some searching, I read in several places that a reboot fixed the problem. While this is true, it is not necessary. All that needs to be done is to remove and reapply the nat statement.
(config)#no nat (inside) 0 access-list InsideNoNAT_ACL
(config)#nat (inside) 0 access-list InsideNoNAT_ACL
This rebuilds the NAT rules and applies all rules in the ACL. Much better than a reload!
As I am sure many of you who have ever worked with a Cisco firewall know, ICMP is not allowed through the firewall by default. If you are just configuring the device, this can make it very difficult to troubleshoot connectivity issues. Thankfully, there are several ways to get around this.
Solution 1: Use access-lists to allow pings from inside/DMZ to the outside.
To allow pinging from the inside to the outside interfaces, you will need to configure an access-list for the outside interface.
access-list OUTSIDE_IN_ACL permit icmp any any echo-reply
Then apply the access-list to the outside interface.
access-group OUTSIDE_IN_ACL in interface outside
This will allow only ping. If you would like to allow trace route, you will also need to allow time-exceeded.
access-list OUTSIDE_IN_ACL permit icmp any any time-exceeded
Solution 2: Use access-list to allow ping and trace route from the internet to your dmz/inside servers.
To do this, we are going to build off of what we did above, so you should already have this in the config.
Continue reading ‘Cisco ASA and ICMP Configurations’
Here are the relevant parts of the configuration to setup an etherchannel between an IOS device and a CatOS device. First lets start with the CatOS device, in this case a 6509. We will be using ports 3/9 and 3/10.
We first need to set the ports we want to use to be a trunk. Here we are forcing dot1q.
6509#set trunk 3/1-2 nonegotiate dot1q
Now we need to setup the port channels. These channels will be used as 1 and aggregate bandwidth between them.
6509#set port channel 3/9-10
Note: There is an option at the end of this command to specify the admin group. This is how the CatOS groups the ports. If you do not specify the admin group, the CatOS will automatically assign one. This is something to watch out for if you set each port separately.
Continue reading ‘Cisco IOS to CatOS Etherchannel Configuration’
While trying to setup Vista to connect to new client’s network using a VPN, I kept running into problems and could not get it to connect. I was attempting to connect to a PPTP VPN on a Pix 500 series firewall. The error I kept getting was “Failed to connect to VPN Connection”. I tested the connection with XP and was able to connect without any issues.
Continue reading ‘Vista VPN to Cisco Pix devices’