Restrict VPN client with ACL on PIX

[mweiss]

I have many existing VPN groups setup on our 515E and everything is working fine. I have one person that needs access to only one specific server. I have read that since I'm using "sysopt connection permit-ipsec" all vpn traffic is permitted without checking the access lists. Other than removing this command, is there another way to go about this? What if I setup another ip pool with one ip address (192.168.1.33)and bind this pool to a new vpn group for this person? Can I modify my "nonat" access-list to only bypass traffic from the server ip (197.98.1.10) to this vpn client? For example:

access-list nonat permit ip 197.98.1.10 255.255.255.255 192.168.1.33 255.255.255.255

nat (inside) 0 access-list nonat

Would this work? Thanks in advance.

[ehirsel]

Doing what you propose will allow the client to reach the server by the true, internal, address, but it won't stop the client from connecting to other servers that are referenced by static statements that other vpn client can connect to. It just adds one more server to be seen, although by that particular client.

I believe you may be better off removing the sysopt permit-ipsec to allow finer access controls for this client as well as other ones. How are your existing vpn groups setup? Do they all use sperate pools, or a common one?

How are your existing static statements setup? If most or all vpn traffic is initiated by the remote client, then you can use policy-based nat/static so that existing clients can view existing servers, and the new client can view the new server, but not vice-versa. I.E., set up an acl as follows;

access-list acl_client_x permit ip host server1_ip client_x_subnet netmask client_x_mask

static (in, out) server1_ip access-list acl_client_x server1 - note read the static as (real, mapped) mapped real - the acl is how it it seen in the real/inside interface, the server1_ip is the address as seen on the mapped/outside interface that the vpn connections terminate on.

Where client_x and server1_ip are for the new connection that you wanted to use in the nonat acl - static overrides nat/global

While this won't provide for port/protocol specifics it does limit reachability to specified hosts. You can still use the policy based nat/static technique regardless of the sysopt permit-ipsec setting.

Let me know if this helps.

[mweiss]

First, thanks for your reply.

> Do they all use seperate pools, or a common one?

I currently have 2 pools setup and 3 VPN groups. 1 pool is used for our IT vpn group and the other is used by the other 2 vpn groups. I was planning on adding another pool and vpn group just for this 1 new client.

> How are your existing static statements setup?

Currently I am not using any static statements. Clients connect and have access to the local LAN only.

This PIX also has many site-to-site VPN connections to our other locations. Would removing the sysopt permit-ipsec command affect these connections as well?

I also assume I will have to create an access-list / static for each "pool" that I'm currently using as well, right?

Thanks again for your input.

[ehirsel]

Removing the sysopt permit-ipsec will affect all vpn connections as it is a global command, not one that is particular to a crypto map sequence entry.

Using policy-based nat means that you would create an access-list and static for each vpn pool that you are using. The one advantage of policy-based nat is that is allows you to reuse public ip addresses or can help in situations where an address conflict occurs due to overlapping name space between the vpn partner networks.

Note that you can use statics even if the ip address as seen by the partner is the true address of the internal/inside host/network.

Let me know if you need more help.