We are trying to establish a two-way L2L VPN tunnel with a partner. VPN traffic is a many-to-many towards our partner, and from our partner they need a many-to-one towards us (they need to access just one host on our network). Furthermore, our partner has numerous VPNs, so they require us to use a separate NAT to two private host addresses, one for each direction of the tunnel.
My initial configuration of the tunnel on my side brought up Phase 1, but no IPSec. Partner ran debug which revealed that my host was not being NAT'd in the policy NAT. We are using a ASA5520, ver 7.0.
Here is the config:
####List of OUR hosts
object-group network OURHosts
network-object host 192.168.x.y
<additional host entries>
####List of PARTNER hosts
object-group network PARTNERHosts
network-object host 10.2.a.b
<additional host entries>
####ACL's for NAT
access-list NAT2 extended permit ip object-group OURHosts object-group PARTNERHosts
access-list NAT3 extended permit ip host 192.168.c.d object-group PARTNERHosts
nat (INSIDE) 2 access-list NAT2
nat (OUTSIDE) 2 172.20.n.0
nat (INSIDE) 3 access-list NAT3
nat (OUTSIDE) 3 172.20.n.1
####ACL for VPN
access-list VPN extended permit ip object-group OURHosts object-group PARTNERHosts
access-list VPN extended permit ip host 192.168.c.d object-group PARTNERHosts
tunnel-group <partner public IP> type ipsec-l2l
<IPSEC attributes - pre-shared-key>
crypto map <NAME> <#> match address VPN
crypto map <NAME> <#> set transform-set VPN
crypto map <NAME> <#> set peer <partner public IP>
I realize that the ACL for the VPN should read:
access-list VPN extended permit ip host 172.20.n.0 object-group PARTNERHosts
access-list VPN extended permit ip host 172.20.n.1 object-group PARTNERHosts
...if the NAT was working properly, but when this ACL is used, Phase 1 does not even negotiate, so I know the NAT is never being translated.
What am I missing in order to NAT our hosts to the 172.20 host addresses when trying to access their internal addresses via the VPN?
Thanks in advance.
Here is the order of operations for NAT on the firewall:
1. nat 0 access-list (nat-exempt)
2. Match existing xlates
3. Match static commands
a. Static NAT with and without access-list
b. Static PAT with and without access-list
4. Match nat commands
a. nat [id] access-list (first match)
b. nat [id] [address] [mask] (best match)
i. If the ID is 0, create an identity xlate
ii. Use global pool for dynamic NAT
iii. Use global pool for dynamic PAT
So you could try
1) a static NAT with an access-list which will take precendence over a dynamic NAT statement
2) As you can see from 4a it uses first match with NAT and access-list so in theory swapping them around should do the trick.
Can i think of any negative consequences ? - well yes you could lose all connectivity. I don't think this will happen but i can't promise so you absolutely would want to do this out of hours.