Tightly controlling Extranet VPN traffic terminating on a Pix

[m.laporta]

Hi all.

My Customer has an IPSec Extranet connection between their Pix and a Checkpoint firewall.

Everything is working fine but the current VPN interesting traffic is simply identified by source and destination addresses:

access-list nonat permit ip 192.168.128.0 255.255.255.0 host 192.168.2.68

access-list nonat permit ip 192.168.128.0 255.255.255.0 host 192.168.2.81

!

...

crypto map rtpmap 10 match address nonat

...

!

sysopt connection permit-ipsec

Now my Customer has asked me to tightly control the traffic by limiting access from the Extrenet to only some protocols/ports.

Well, I'm wondering about the best way to do this.

Changing the access-list nonat seems to be the *easiest* way but not the way recommended by the Cisco SAFE VPN blueprint:

"Normally the networks, hosts, and ports that are allowed to traverse the tunnels are defined in the Security Policy Database (SPD), as defined by the IPSec standard. This database is populated by the use of access control lists (ACLs). These ACLs are sometimes referred to as "crypto ACLs" or "network rules." You might consider using the cryptographic ACLs for rudimentary network security access control, but Cisco does not recommend this scenario because it complicates the configuration significantly. Rather, you should use inbound ACLs on the VPN devices for site-to-site traffic. "

Can someone give me some clarifications about this statement?

How can I possibly filter *decripted* traffic once it has been let in by the "sysopt connection permit-ipsec" when it was still encrypted?

Thank you very much.

[mostiguy]

IPSec Security Associations are one way. So, normally, for an IPSec connection, you need two, one for each direction. This gets waaaay more complicated if you start invoking individual ip protocols (tcp, udp, etc) or port numbers in your crypto acls. What happens is that an SA will need to be negotiated for each port/protocol pair = vastly increasing the # of SAs = vastly increasing troubleshooting headaches. Thus Cisco's recommendation not to do such things with crpyto ACLs.

Re: filtering decrypted traffic:

What you would be doing is more granular filtering at each router in crypto ACLs, before the data hits the IPSec pipe. This would cause tons more SAs though.

They mention inbound ACLs on vpn devices - you could have an inbounc ACL on the internal int of your pix, and filter there.