cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1449
Views
0
Helpful
11
Replies

ASA-5506 NAT issues

ABaker94985
Beginner
Beginner

We have multiple ASA-5506s that are being used for compliance reasons. The first two went in just fine with no NAT statements, but the 3rd one drops around 25-30% packets both to and through the firewall. All firewalls are running 9.8(4) and were configured as an HA pair. The standby firewall had 100% ping rate to the firewall, but upon failover this would drop to around 75% success, which included packets to and through the firewall. For testing, failover config was removed, but this didn't change anything. This is not a perimeter firewall, and the IPs on the inside of the firewall need to appear on the outside of the firewall. 

The inside interfaces are bridged as shown below, and we have hosts plugged into all but one of the inside interfaces. As soon as I created a nat entry using "nat (any,outside) source static Center-Network Center-Network no-proxy-arp", we started seeing 100% success rate on the traffic. I tried other iterations than "any,outside" such as creating several nat statements similar to "nat (inside_1,outside) source static..." "nat (inside_2,outside) source static..." but much of the traffic would be blocked. Given it's not possible to do a "nat (inside,outside)..." statement because the ASA won't take "inside" but wants "inside_#", what is the proper way to NAT? I realize NAT shouldn't be required, but the firewall isn't working without NAT configuration, and unfortunately we don't currently have Smartnet on the firewall.

Thanks

 

interface GigabitEthernet1/2
bridge-group 1
nameif inside_1
security-level 100
!

...

!
interface GigabitEthernet1/3
bridge-group 1
nameif inside_2
security-level 100
!
interface GigabitEthernet1/7
bridge-group 1
nameif inside_6
security-level 100

!

...

!

interface BVI1
nameif inside
security-level 100
ip address 10.22.24.1 255.255.255.240 standby 10.22.24.2

1 Accepted Solution

Accepted Solutions

Here are some more details. Pinging an internal address (10.22.24.3) from an external source (10.52.20.29) showed that the ASA was trying to reroute the traffic to the outside interface and NOT the inside interface:

%ASA-3-106014: Deny inbound icmp src outside:10.52.20.29 dst outside:10.22.24.3 (type 8, code 0)

After hours of debugging, the problem appeared to be bug-related: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvg78080.  The bug shows random ICMP packets being dropped for ACLs applied to BVI interfaces. We had packet drops with data packets as well, which was causing the larger problem. Although this doesn't show it's only related to the ASA-5506, we've not had any problems with the ASA-5508. All ACLs have been moved to the outside interface. We'll run a full test tomorrow, but right now everything seems to be working.

View solution in original post

11 Replies 11

balaji.bandi
VIP Community Legend VIP Community Legend
VIP Community Legend

Do you need  BVI inside_1 - 6 interfaces, or look below : may be bug ?

 

https://www.petenetlive.com/KB/Article/0001422

BB

***** Rate All Helpful Responses *****

How to Ask The Cisco Community for Help

I'm very curious as to what you are saying, so I want to clarify if you are saying something other than what is configured. There are inside_1 through inside_6, which is shown in the bottom of the post. Are you referring to something else?

yes i am referreing the ASA  has some config issue, if the intention of your config not what you have done.

 

So you looking BVI ? with so many brindge interface ?

 

BB

***** Rate All Helpful Responses *****

How to Ask The Cisco Community for Help

Here is the desire interface config:

Gi1/1: outside

Gi1/2-1/7: inside, which requires a BVI interface

Gi1/8: stateful/failover (will be reapplied after the problem is resolved)

 

We don't have a switch on the inside of the firewall and are trying to use Gi1/2-1/7 for L2 connectivity.

Thank you for the confirmation, then your setup is correct. (just to clarify things)

BB

***** Rate All Helpful Responses *****

How to Ask The Cisco Community for Help

Hmmm. I still left with wondering why the firewall is dropping so much traffic. I just updated the firmware from 9.8(4) to 9.12(4) to see if this might resolve the issue, but as soon as I remove the nat configuration, the traffic starts dropping. I shouldn't need the nat statement.

is this traffifc NAT Drop inside to outside or outside to inside - Either case yes you need NAT configuration, since how RFC 1918 address reach over internet ?

BB

***** Rate All Helpful Responses *****

How to Ask The Cisco Community for Help

There is NO Internet access with this firewall - NAT to the outside world is done through the perimeter firewall. The inside of this firewall is RFC-1918 and the outside I'm concerned with are also RFC-1918 addresses. The outside interface of this firewall is plugged into our organizations internal network, and we need to segment the traffic on the inside of the firewall from the rest of our network.

Here are some more details. Pinging an internal address (10.22.24.3) from an external source (10.52.20.29) showed that the ASA was trying to reroute the traffic to the outside interface and NOT the inside interface:

%ASA-3-106014: Deny inbound icmp src outside:10.52.20.29 dst outside:10.22.24.3 (type 8, code 0)

After hours of debugging, the problem appeared to be bug-related: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvg78080.  The bug shows random ICMP packets being dropped for ACLs applied to BVI interfaces. We had packet drops with data packets as well, which was causing the larger problem. Although this doesn't show it's only related to the ASA-5506, we've not had any problems with the ASA-5508. All ACLs have been moved to the outside interface. We'll run a full test tomorrow, but right now everything seems to be working.

If this device is just act as Router (FW) some other device doing nat, then you need just routing you do not need NAT here.

if you can give us small diagram how your devices connected.

BB

***** Rate All Helpful Responses *****

How to Ask The Cisco Community for Help

I completely agree and even stated in my first paragraph that we had a couple other implementations that didn't use NAT, but by adding the NAT statement on this firewall, the problem significantly lessened. When looking at the logs, I had initially overlooked the problem that the ASA incorrect attempted to send the packets to the outside interface and not the inside interface. This is a bug, and I had to remove ACLs from the BVI interface to correct the problem.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: