In article , Darren Green wrote: :Can someone clarify this for me.
:Having read & re-read various bits of Cisco literature I am confused over :the 'sysopt connection pl-compatible' command.
Don't use it!
:When configuring the PIX to accept VPN clients am I to understand that where :the remote IP address is known (i.e. static) the above statement is not :needed as you would use Nat 0 between the Internal LAN and the IP subnet for :the address pool. Alternatively where the IP address isn't known i.e. :dynamic, you would use the above statement.
You've overlooked these parts:
Note The sysopt ipsec pl-compatible command is deprecated. In its place, we recommend using the nat 0 access-list command to exempt IPSec from NAT. [...]
The sysopt ipsec pl-compatible command enables the IPSec feature to simulate the Private Link feature supported in PIX Firewall Version 4. The Private Link feature provides encrypted tunnels to be established across an unsecured network between Private-Link equipped PIX Firewall units. The sysopt ipsec pl-compatible command allows IPSec packets to bypass the NAT and ASA features and enables incoming IPSec packets to terminate on the sending interface.
If you want to exempt all IPSec traffic from ACLs, then use sysopt connection permit-ipsec .
If you are using a remote gateway device such as a PIX or 837, or Linksys BEFSVP41, then whether the outside IP of the device is static or dynamic doesn't matter: you write the nat 0 ACL and any interface ACLs in terms of the -internal- IP ranges, not in terms of the external IPs. If you are using a remote gateway device that has a dynamic outside IP, you can rely on the PIX to generate the crypto ACL itself, or you can put in your own crypto dynamic-map match-address statement.
If you are using a remote security client such as the VPN client, then you are configuring vpn groups and so on, and you specify the dynamic IP pool in those clauses. In such a case you wouldn't write a crypto map match-address or crypto dynamic-map match-address clause because vpdn doesn't go through that chain. You would nat 0 against the IP pool -- and that step isn't going to depend upon whether the public IP of the client is static or dynamic.
Static or dynamic public IPs only matter when you are building crypto maps or crypto dynamic-maps, and as noted above in such cases it is the internal IP range that matters for the nat 0, not the public IP.