pix vpn group access list

1) If you don't want your VPN users to go through the access lists configured on your PIX, you can use the "sysopt connection permit-ipsec" command.

If you don't, then the VPN users would have to go through the access lists. But which access list are we talking about? The one placed on the outside interface?

2) What if you have VPN users from the internal network (connecting to the inside of the PIX). Then which access list would they be concerned with? The inside one?

I would prefer to receive answers from someone who has verified the above in a lab or someone who is really confident of his views.
LVL 11
Who is Participating?
I'll make some first attempts to impart my (humbly - very experienced) understanding, then I will lab test it and post back..

1) Because of the security levels of the different intefaces, anything from a lower security interface (outside) to higher security interface (inside) is blocked by default, unless and until you create an acl.  The access-lists bypassed referrs to the inbound access-list. Instead of creating access-list entries to permit inbound IPSEC or inbound PPTP, plus the traffic from the client "through" the tunnel, like these that don't really make a lot of sense:
   access-list outside_in permit tcp any <interface ip> eq 1723
   access-list outside_in permit gre any <interface ip>
   access-list outside_in permit udp any <interface ip> eq 500
   access-list outside_in permit esp any <interface ip>
   access-list outside_in permit ip <client ip> <inside lan>  <== allow traffic in from client to inside lan
 access-group outside_in in interface outside

can all be replaced with
   sysopt connection permit-ipsec
   sysopt connection permit-pptp

The VPN traffic also bypasses the fixup protocol inspection as it traverses through the established tunnel.

2) would apply equally to any access-lists applied to the inside interface. I've never seen any instance where an internal client terminated a VPN on the inside interface, and can't think of any reason why you would want to. Theroetically you would not have to enable the sysopt if you did terminate VPn's on the inside interface because all traffic from high security to lower security (inside to outside) is permitted by default so there is nothing to bypass..

billwhartonAuthor Commented:
As for your answer to 2), I am faced with a situation whereby inside to dmz traffic is restricted to certain source hosts on the inside network. Hence, I would need to modify this access list to reflect the source IP (vpn pool in this case) and destination IP (dmz in this case).

I would appreciate if you could try this out in your lab.
Can you explain in more detail what you are trying to accomplish with your traffic restrictions between inside and other interfaces? Consider the VPN pool another interface. If you have a restrictive access-list applied to the inside interface, sysopt should not bypass that.
It may take a day or two to get my lab setup to test that theory...
Managing Security & Risk at the Speed of Business

Gartner Research VP, Neil McDonald & AlgoSec CTO, Prof. Avishai Wool, discuss the business-driven approach to automated security policy management, its benefits and how to align security policy management with business processes to address today's security challenges.

billwhartonAuthor Commented:
well, internal users need to ftp into a DMZ server and this has to be secure. That's all it is.

Unfortunately, I've suggested different methods of accomplishing this but the engineer i am helping out wants to stick to this.
So, only specific users on the inside can get to this FTP server in the DMZ?
How does this relate to the VPN users and sysopt? Just the fact that there is an acl on the inside interface?
billwhartonAuthor Commented:
I think I have to take one step back.

If an internal user vpn's into the pix successfullly, how does communication take place from that point onwards?

From the outside, you simply use the split-tunnel command that tells the vpn client which networks to talk to over the tunnel. How do i do it in this case? I want the VPN user to access everything over the tunnel which would include Internet(outside interface) and DMZ servers.
Make sure that the split-tunnel acl includes you local lan and the DMZ lan subnets.
You can't include internet access..

access-list split-tunnel permit ip <local LAN> mask <vpn pool> mask
access-list split-tunnel permit ip <DMZ LAN> mask <vpn pool> mask

Only traffic between the client and the two subnets will be encrypted within the tunnel between the client and the PIX.
All traffic from client to other Internet sites will go unencrypted out the client's own local Internet connection - the PIX will never see it.
You can use these acls to restrict further by only allowing access to one host on the DMZ, or even just one port...
   access-list split-tunnel permit ip host <dmz host> <vpn pool> mask

If security is paramount, then you may want to rethink the policy for remote users. Once connected, ALL traffic gets sent down the encrypted tunnel, and everything except traffic to/from these two subnets gets dropped. Else, you have to terminate the VPN users on a separate interface to enable their traffic to go out the outside interface.
billwhartonAuthor Commented:
Well, i cannot include local LAN as the pix would never allow a source and destination to reside on one physical interface. It wouldn't forward packets.

Think of the VPN client as a "pseudo" interface somewhere in the middle of the PIX.
It should have a subnet different from the local LAN. Many of the threads here in the firewalls TA of EE deal with users trying to use the same IP subnet for both the VPN users and the local LAN.

You have to include the local LAN in the access. This is passed on to the client to define the networks to which traffic must be encrypted. Use the client to connect, then open Status | Statistics | Route Details
That's where this information comes from...

What you can't do is re-direct Internet traffic from client, through the tunnel, decrypted in the interior of the PIX, then pushed back out the outside interface to a remote location.

The sysopt gets the traffic in/out of the outside interface - through the tunnel -
The split-tunnel acl provides route details information to the client and helps put restrictions on VPN clients
The nat-zero acl bypasses the nat process for LAN - VPN traffic
The access-list matched by the crypto map defines the "interesting traffic" that will be encrypted/decrypted
billwhartonAuthor Commented:
Trying stuff from your previous posts over this weekend on my PIX 501. A three-interface pix would have helped but I don't have one.
Any progress? Are you still working on this? Do you need more information?
billwhartonAuthor Commented:
Guess what.

I was successful at doing this today. There is one thing to be noticed though:

Supposing you are doing a regular VPN to the outside interface and VPN users need to access the DMZ network.
vpn pool:
dmz network:
inside network:

Your nat (0) access-list 101 would be 'access-list 101 permit ip'

However, when you are VPNining to the inside interface, your NAT statement would have to be a little different. It would be:
nat (0) access-list 101 &
''access-list 101 permit ip'

Do you see the access-list has the networks reversed in this case? This is how it worked for me. Why do you think it's the way it is?
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.