Questions on "sysopt connection permit-ipsec"

I think you mix two things .

1- You can terminate an IPSEC tunnel on a PIX , for example in a lan-to-lan VPN between two PIX. 2- Or you can allow IPSEC traffic to cross a PIX ,for example if you have a third PIX between the two mentionned in the first example.

In the fist case, when the PIX act as the VPN peer , you don't need to allow IPSEC traffic through the access-list. In the second case, when the PIX act as a barrier between two VPN devices then you have to allow IPSEC traffic , the same way you would allow http traffic if the PIX act as a barrier between a Webserver and a browser.

--If you want to do a lan-to-lan VPN using your PIX as one of the peer , you need first to define the IP addresses that will be part of the tunnel. On one side i can see that you have the hosts

10.1.1.3 and 10.1.1.4, but on the other side it's not a good idea to use the word " any". You should know the IP subnet of the other side . So you would have the following crypto ACL access-list ipsectraffic permit ip host 10.1.1.3 [other lan subnet or host] access-list ipsectraffic permit ip host 10.1.1.4 [other lan subnet or host]

note also that you cannot specified a protocol in a Crypto ACL , so you need to "permit ip" and not "permit tcp"

--Now you have to tell the PIX not to translate the traffic that have to be part of the tunnel. Remember that the NAT rules are applied before the crypto maps, that's why you have to explicitely tell the PIX not to NAT this traffic .It's a good practice to use a different acl for that , it will be usefull if you have more than one tunnel.

access-list nonat permit ip host 10.1.1.3 [other lan subnet or host] access-list nonat permit ip host 10.1.1.4 [other lan subnet or host] nat (inside) 0 access-list ipsectraffic

--Now you have the choice of allowing all traffic that is part of the tunnel with the command sysotp connection permit-ipsec , or if you want to be more granular you can remove the command and give the permissions you want through the acl. And since the traffic is decrypted before going through the acl , you can use the real ip address of the other side without problem. No translation is involved.

In article , Cen wrote: :Some questions regarding the above command.

:From my understanding this command implicitly generates the following for an :interface enabled for IPSEC, say the outside interface: :access-list permit 50 any host :access-list permit 51 any host :access-list permit udp any host eq 500 :Is this understanding correct?

No, ACLs never have any effect on traffic to the PIX itself.

:- The the sysopt command is enabled, the ACL tied to the crypto map will be :implicitly trusted, allowing the decrypted IPSEC packets to be permitted :even if the outside interface ACL does not explicitly allow for it. Does :this mean that there's potential security issue with this? For example the :following is the ACL tied to the crypto map:

:Crypto map ACL: :access-list ipsectraffic permit tcp host 10.1.1.3 any :access-list ipsectraffic permit tcp host 10.1.1.4 any

:Outside interface ACL: :access-list outsideACL deny ip any any

:Effective outside interface ACL:

:access-list outsideACL permit any host 10.1.1.3 :access-list outsideACL permit any host 10.1.1.4 :access-list outsideACL deny ip any any

Not really.

When an IPSec packet is received and successfully decoded, the packet source and destination are checked against the active crypto map ACL for that tunnel. If the packet does not match the ACL, the packet is dropped. Then, if permit-ipsec is NOT in effect, the decoded packet is checked against the interface ACL; if permit-ipsec IS in effect, the decoded packet is allowed through without the interface ACL check.

In your example, -any- packet destined for 10.1.1.3 would be allowed through the "effective" ACL that you list if permit-ipsec is in effect, but the real situation is that only IPSec packets are given the special exemption, and even then only if they match the ACL for their tunnel. Something like,

access-list outsideACL permit any in tunnel OutsideMap policy 1100 host 10.1.1.3

As the other poster indicated, you never want "any" as the destination of a crypto map ACL entry. In your example, *all* traffic from 10.1.1.3 would be sent to the tunnel, no matter where that traffic was destined. Sometimes, particularily for crypto dynamic maps, it is acceptable to have any as the -source- in the crypto map ACL entry.