01-23-2012 06:24 AM - edited 03-04-2019 02:59 PM
Hi Folks,
I'm having difficulties getting the following setup to work. I could do with a second opinion, I'd really appreciate if someone could review my setup and let me know if I'm missing something obvious?
High level overview (corresponds to uploaded sanitised running configuration):
- Cisco ASA 5520 running 8.4(2) (in HA pair)
- Outside Interface: a.a.a.a (the VPN interface)
- Customer's VPN peer: c.c.c.c
- Packet Source: object-group network int_Customer1Access (a group of internal clients, e.g. object network int_APPa1 172.16.20.114)
- Packet Destination: object network cst_Customer1APIServer-Backup (the server at the far end of the VPN tunnel, 10.9.4.117)
- Traffic Type: tcp/3389,tcp/8080 (but for now, set to all 'ip' for troubleshooting purposes)
Now, I have a Dynamic NAT rule in place to NAT the source address, e.g. 172.16.20.114, behind the ASA's outside interface c.c.c.c, before sending the traffic down the tunnel. The tunnel has been established, however I can't seem to get the ASA to actually route traffic down that tunnel - the IPsec Site-to-Site "Bytes TX" counter always reads 0 after pings and repeated failed connection attempts to tcp/8080 or tcp/3389.
I've noticed some strange behaviour in Packet Tracer, if the tunnel has not yet been established...
If the tunnel is not yet up, the phases read ROUTE-LOOKUP, ROUTE-LOOKUP, ACCESS-LIST, IP-OPTIONS, FOVER, NAT, VPN (drop), RESULT
Run the trace a second time, the tunnel having established itself from the previous run, and the phases read:
ROUTE-LOOKUP, ROUTE-LOOKUP, ACCESS-LIST, IP-OPTIONS, FOVER, NAT, ACCESS-LIST (drop), RESULT
As you can see the VPN phase is replaced with the ACCESS-LIST phase. Eitherway, it always ends in a drop!
Many thanks,
Alistair
01-24-2012 10:51 AM
Solved.
Turned out to be a problem with those pesky vpn-filters, as explained here:
http://www.routerdiscussions.com/viewtopic.php?f=17&t=13894
and here:
http://www.cisco.com/en/US/docs/security/asa/asa84/configuration/guide/vpn_groups.html#wp1093578
Just had to reverse the extended ACL applied to the tunnel, it now looks like:
object-group service Customer1APIPorts-Source tcp
port-object eq 3389
port-object eq 8080
access-list acl_vpn_Customer1Backup extended permit tcp object cst_Customer1APIServer-Backup object-group Customer1APIPorts-Source interface outside
Also, the behaviour from Packet Tracer was by design - it'll change its traces based on the current state of the appropriate tunnel.
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