Can someone please help me clarify the following?
1. for a site to site VPN tunnel between two ASAs, does the NAT 0 statement have to exactly match on both sides? For example, the access list for NAT 0 on on ASA-A states: (where 10.20.0.0/16 is the network on this side, which needs to talk to 10.30.0.0/16 on the other side through this tunnel)
access-list inside_nat0_outbound extended permit ip 10.0.0.0 255.0.0.0 10.0.0.0 255.0.0.0
and the access list for NAT 0 on ASA-B for this same tunnel states: (where 10.30.0.0/16 is the network on this side)
acces-list inside_nat0_outbound extended permit 10.30.0.0 255.255.0.0 10.20.0.0 255.255.0.0
Will this work? shouldn't ASA-A have the mirror image of ASA-B's NAT0 statement?
2. For the above mentioned VPN tunnel, let's say the option 'enable inbound ipsec session to bypass interface access list' is enabled on both ASAs. Then, if machine-A (IP - 10.20.0.2, behind ASA-A) initiates traffic to machine -B (IP - 10.30.0.2 behind ASA-B), I assume this traffic will traverse the tunnel just fine by passing all interface acess lists.
But what about the return traffic for this session, from machine -B to machine -A? That will reach back ASA-A and because it is an 'inbound' IPSec session as far ASA-A is concerned, it bypasses the interface access lists (if any) and everything works just fine. Is this how this option works?
What about the sitiation when machine-A initiates a traffic to an IP address 10.30.0.3 on the other side (which is on VLAN-2) which then gets NAT'd to an IP in a different VLAN (VLAN-3), both VLANs defined on the ASA? In such a case will the access-lists on the ASA between between VLAN-2 and VLAN3 come into play or will that also be bypassed as the result of the above mentioned option?
Your NAT 0 at site 1, should mirror your crypto ACLs at site 1.
Same rules for site 2.
Normally, we won't NAT the traffic between the 2 sites through the tunnel.
Following the above NAT 0 guidelines will prevent the NAT from operating on packets going over the tunnel.
Thank you for your reply Keith.
Presently they way it is now is what I have described above. My concern here is that NAT 0 on one side is more widely defined (10.0.0.0/8, as opposed to 10.20.0.0/16) and whether that will prevent it from working. Can you please comment on that?
Also, any thoughts on the second question regarding the option "enable inbound ipsec session to bypass access list"...?