Crypto maps on PIXes inside or outside i/f?

[phaddad]

According to the PIX VPN documentation, one can apply a crypto map to any interface, however the only examples given are the outside interface.

I have an environment where a number of individual customers each have their own virtual "inside" interfaces via vlans. They each would like to implement VPNs back their home networks, but I'd like to avoid having one large shared crypto map on the outside interface. The main reason for this is that the frequency of changes is likely to be high, and I don't want to have to impose outages on all customer VPNs for each change.

So I was thinking about having a per-customer crypto map applied to each of their virtual "inside" interfaces.

Any reason to avoid this strategy? I would assume you'd need to modify the acl_out to allow incoming ipsec/isakmp from the remote PIXes.

thanks,

Peter

[brad]

Hi Peter

There are some problems with this approach. This first is simply that this would require using public address on each of the "private interfaces". While possible, it may be challanging to configure the routing with you ISP and properly subnet your address space.

Assuming you have a solution for this or all addresses are routed privately anyway, I am still not sure this works. I tried a similar configuration and was unsuccessful.

I seem to remember that it worked sometimes, but not others making the solution unreliable.

If I recall correctly, the crypto engine failed to catch the packets as they were effectively exiting the same interface as they arrived on which is not allowed by the pix.

This is difficult to get your head around, but I think the idea is the same as the reason why VPN connections from the software client could not access the Internet without split tunneling enabled. Internet traffic arriving through the VPN could not be forwarded back out the public interface to the Internet.

Having said all that, the VPN client issue has a work around in PIX OS 7, so maybe terminating VPNs on Internal interfaces would work as well.

[phaddad]

Using public address space is not a problem in this situation. But just wondering, couldn't you use private address space for the inside interfaces and do static nat to the outside

i/f subnet. Then set up the remote end of the tunnel to point at the natted global IP.

I may mock this up with a few PIXes to see if I can get it to work reliably. I'll post the results. Thanks for the info.

Peter