In article , John wrote: :Quick question. If I upgrade a PIX506 from v6.2(2) to v6.3(4), will this :impact in any way the configuration of a PIX-PIX VPN that we have :established?
If you are currently using 'alias' with respect to traffic over the VPN, then you could potentially find that the stability of 'alias' has sufficiently corroded to affect the link.
If on one of the two sides, the transform set lists AH first and the other does not, and if AH is presently not actually in use because the other end does not list it first and so they negotiate it away, -and- if you have NAT inbetween or if AH is blocked inbetween, -and- if both points end up with NAT-T (isakmp nat-traversal) turned on: then you may run into difficulty. In this set of circumstances, asymmetric transforms can end up being negotiated, with one side not using AH and the other side thinking the connection isn't working because it isn't getting the AH it expects. It's a long chain of circumstances, but I learned this one in the School Of Hard Knocks.
:I do NOT have access to the PIX on the other end of the :VPN. I'm trying to setup a second site-site VPN with a 3rd 506e, and :when I typed in the commands taken from the PIX running v6.2(2), I got a :message that a couple have been depreciated.
By 6.3(4), the only thing I can recall that is deprecated to the point of disapperance, is the 'dnat' sysopt. Everything else will either be grudgingly supported or else automatically upgraded to newer forms.
I do, though, warn that 'alias' should not be counted on in conjunction with any new 6.3 feature such as policy nat. Unfortunately, some people have been reporting difficulties in getting the replacement, the 'dns' keyword on 'static', to work properly. The other half of 'alias', reverse nat, seems to work, but it can be confusing to configure.
Note: if you are using 'alias' for overlapping networks shared over the VPN, and you replace it with 'reverse nat' aka 'bidirectional nat', aka 'nat outside', then be advised that the crypto map 'match address' ACL must match the transformed IP addresses, not the internal versions of them. 'crypto map match address' ACLs are evaluated *after* NAT has taken place.