In article , none wrote: :I am in this scenario (PIX 6.3.4)
:I am not sure the order of the "nat (inside)" sine I do not get why the :"nat (inside) 0" should not be labelled "nat (inside) 1 or 2,3,4" since :it is processed first ... Or, is it not processed first? Because at that :stage of passing through the "nat (inside) 0", insie packets haven't :been nated.
:nat (inside) 0 access-list no-nat
nat 0 access-list is always processed first, no matter what other nat or static are in the configuration. (Note: nat 0 that does -not- have an "access-list" is not processed until a later stage.)
:nat (inside) 1 10.1.6.0 255.255.255.0 :nat (inside) 2 access-list net_outside
The next in priority order is "static", but you do not have any of those.
Third is nat with an access-list. Thus your nat (inside) 2 statement will be processed before your nat (inside) 1 statement.
Regular nat like your nat (inside) 1 statement are processed next. The order of the regular nat statements in the configuration is ignored, and the policy number of regular nat statements is ignored in determining priority: for regular nat statements, the one that takes priority is the one that is the longest match for the IP address.
-Except- for policy number 0, the only reason to have a policy number on the nat statement is to match it up with the corresponding global statement.
:global (outside) 1 192.168.10.1-192.168.10.33 netmask 255.255.255.0 :global (outside) 2 interface
The order of these is whatever falls out of the rules for nat. The policy number does not matter for global, other than to match the global with the corresponding nat statement.
:access-list no-nat permit ip 192.168.10.0 255.255.255.224 192.168.20.0
255.255.255.0
:access-list 5th-floor permit ip 192.168.10.0 255.255.255.224 192.168.20.0
255.255.255.0
:crypto map crypto-map-std 10 match address 5th-floor
crypto match ACLs are evaluated *after* any NAT. If you examine your nat 1 and global 1 statements, you will see that traffic other than that matched by net_outside is being nat'd into 192.168.10/24 -- which happens to be the source range for the crypto map match address.
Therefore, traffic that is not http/https/ftp/dns traffic, and which happens to be addressed to 192.168.20.*, will be pulled into your crypto map and sent across the IPSec link.
When those packets return from the other end of the IPSec link, they are going to be packets sourced from 192.168.20.* and destined for 192.168.10.* . That will match the crypto map ACL, so the packets will be decapsulated okay. But then those decapsulated packets go through the NAT process. The first thing looked at in the NAT process is the nat 0 access-list, and for incoming packets that ACL will be read "backwards", reversing source and destination. The "forward" reading has 192.168.10.* as the source, 192.168.20.* as the destination, so the backward reading will look for packets with 192.168.20.* as the source and 192.168.10.* as the destination. Which describes the packets that have made it back through the VPN.
The nat 0 access-list thus matches, so the packets returning from the VPN will *not* be translated back to the original IPs -- instead, the PIX will try to figure out where 192.168.10.* is, and send the packets on to there. There is no specific route statement for 192.168.10.* and
192.168.10.* is not the inside interface, so what would have an effect is the route 0.0.0.0 to the outside that you must have snipped off the posted config, so the PIX would want to send those packets outside. But since the packets just came in from the outside (via the VPN) the PIX will refuse to do that and will just drop the packets instead.
In short: your VPN doesn't work.