Bit of a strange issue this evening. I have a wireless network which has just been re-subnetted using 172.16.x.x range across 9 vlans. All the subnets have internet connectivity with the exception of vlan 1 which is being dropped on the ASA with unicast reverse path error and IDS:2000 error.
Layer 3 (3560G)switch config:
int vlan 1 ip address 172.16.0.2 255.255.254.0 ip vrf forwarding red
int vlan 2 ip address 172.16.2.2 255.255.255.128 ip vrf forwarding red
int vlan 3 ip address 172.16.2.130 255.255.255.128 ip vrf forwarding red
int vlan 4 ip address 172.16.3.2 255.255.255.128 ip vrf forwarding red
int vlan 5 ip address 172.16.3.130 255.255.255.128 ip vrf forwarding red
int vlan 6 ip address 172.16.4.2 255.255.255.0 ip vrf forwarding red
int vlan 7 ip address 172.16.5.2 255.255.255.0 ip vrf forwarding red
int vlan 8 ip address 172.16.6.2 255.255.255.0 ip vrf forwarding red
int vlan 9 ip address 172.16.7.0 255.255.255.0
ip route vrf red 0.0.0.0 0.0.0.0 10.201.29.1 (routed interface to ASA)
ip vrf red rd 1:1
Controller addresses are corresponding dynamic interfaces using .1 address.
1 interface group configured (containing all interfaces) and applied to my SSID. Separate AP groups have been created with the SSID assigned a separate interface that belongs to the AP group.
Separate network objects for each subnet, and dynamic NAT created for each.
I can only assume that I have made a mistake on one of the interfaces (the configuration above is from memory and what it should look like) and overlapped one of the subnets as I am at a loss as to what the problem might be?
I assume that you have configured "ip verify reverse-path interface <interface nameif>" on your interfaces and this would be blocking the traffic.
Why it would be blocking the traffic is probably because you either are missing a "route" for the network which traffic is getting blocked or perhaps you have a "route" configuration that the problematic network is located behind some other interface than where the traffic is actually entering the ASA from. Maybe it might even be possible that some ASA interface holds an overlapping network?
I would start looking at the "route" configurations, routing table of the ASA with "show route" to confirm that there is no errors in the current routing configurations or that there is no overlap related to the network 172.16.0.0/23
Maybe you could share some logs/messages that the ASA is showing also.
route inside 172.16.0.0/16 (only 172 route on the ASA and initially a summary route ).
I disabled ip verify reverse-path on the inside and outside interface (the log message verified that the spoofing was being seen on the inside interface), but it was still problematic. I checked the logs when trying to ping 18.104.22.168 and looked at the log for this address as the source and it was also being blocked by spoofing error as well as the IDS:2000 error (the log description was empty for this event) which after a quick search shows that it may be related to threat detection on the ASA, so i will disable that tomorrow to retest.
There are three interface on the ASA:
outside - public address dmz - 10.201.29.19/30 inside - 10.201.29.1/30
Managed to get this working by removing the vrf on the layer 3 switch. Not sure how it stopped working though, looking through the config earlier my guess is that because the routed link between the ASA and the switch was not in the same vrf the traffic did not know where to go (and caused return route issues) as there would have been no route to 10.201.29.1 in the vrf red routing table? The only issue I have with that explanation is that it worked (with the exception of vlan 1) previously.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
[toc:faq]Introduction:This document describes details on how NAT-T
works.Background:ESP encrypts all critical information, encapsulating
the entire inner TCP/UDP datagram within an ESP header. ESP is an IP
protocol in the same sense that TCP and UDP are I...