cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2598
Views
0
Helpful
1
Replies
alistair.cowan
Beginner

Site-to-Site VPN & NAT'ing behind 'outside' interface IP?

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

1 REPLY 1
alistair.cowan
Beginner

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.