05-05-2021 06:36 AM - edited 05-05-2021 06:50 AM
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
Solved! Go to Solution.
05-05-2021 02:34 PM
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.
05-05-2021 07:12 AM
Do you need BVI inside_1 - 6 interfaces, or look below : may be bug ?
05-05-2021 08:12 AM
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?
05-05-2021 08:25 AM
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 ?
05-05-2021 08:28 AM
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.
05-05-2021 08:51 AM
Thank you for the confirmation, then your setup is correct. (just to clarify things)
05-05-2021 08:55 AM
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.
05-05-2021 09:39 AM
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 ?
05-05-2021 09:42 AM
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.
05-05-2021 02:34 PM
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.
05-06-2021 02:18 AM
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.
05-06-2021 06:59 AM
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.
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