We have a vpn tunnel from our Amazon AWS footprint to our ASA 5500 which currently sends traffic from our AWS servers in 10.200.12.0/24 to our on premise network, there's also a 172.27.1.0/24 in the ACLs and crypto maps which works but is no longer used.
I am trying to add a new range, 172.31.1.0/24 which is a partner network out a different tunnel (terminating at another CI) and is distributed through the network via OSPF. This works fine on-premise, our production on-premise LAN can see this great, but the ASA is dropping traffic bound for 172.31.1.0/24 at this end (v the AWS end) of the tunnel, the behaviour looks similar to when crypto ACLs don't match between VPN devices.
Result: input-interface: outside input-status: up input-line-status: up output-interface: inside output-status: up output-line-status: up Action: drop Drop-reason: (acl-drop) Flow is denied by configured rule
I'd normally expect to see this if ACLs don't match, but the crypto map shows the new range correctly. Also the AWS side has correct ACL rules that allow this and correct routes (otherwise the traffic wouldn't enter the tunnel right?)
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...