Solved

pix vpn group access list

Posted on 2004-10-19
12
267 Views
Last Modified: 2013-11-16
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.
0
Comment
Question by:billwharton
  • 6
  • 6
12 Comments
 
LVL 79

Accepted Solution

by:
lrmoore earned 250 total points
ID: 12353603
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..

0
 
LVL 11

Author Comment

by:billwharton
ID: 12354380
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.
0
 
LVL 79

Expert Comment

by:lrmoore
ID: 12360023
OK..
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...
0
 
LVL 11

Author Comment

by:billwharton
ID: 12361152
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.
0
 
LVL 79

Expert Comment

by:lrmoore
ID: 12361666
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?
0
 
LVL 11

Author Comment

by:billwharton
ID: 12363298
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.
0
Highfive Gives IT Their Time Back

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

 
LVL 79

Expert Comment

by:lrmoore
ID: 12363414
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.
0
 
LVL 11

Author Comment

by:billwharton
ID: 12363454
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.

0
 
LVL 79

Expert Comment

by:lrmoore
ID: 12363742
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
0
 
LVL 11

Author Comment

by:billwharton
ID: 12377433
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.
0
 
LVL 79

Expert Comment

by:lrmoore
ID: 12403488
Any progress? Are you still working on this? Do you need more information?
0
 
LVL 11

Author Comment

by:billwharton
ID: 12405865
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: 13.1.1.0
dmz network: 80.1.1.0
inside network: 10.1.1.0

Your nat (0) access-list 101 would be 'access-list 101 permit ip 80.1.1.0 255.255.255.0 13.1.1.0 255.255.255.0'
Agree?



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 13.1.1.0 255.255.255.0 80.1.1.0 255.255.255.0'


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?
0

Featured Post

Find Ransomware Secrets With All-Source Analysis

Ransomware has become a major concern for organizations; its prevalence has grown due to past successes achieved by threat actors. While each ransomware variant is different, we’ve seen some common tactics and trends used among the authors of the malware.

Join & Write a Comment

I recently updated from an old PIX platform to the new ASA platform.  While upgrading, I was tremendously confused about how the VPN and AnyConnect licensing works.  It turns out that the ASA has 3 different VPN licensing schemes. "site-to-site" …
This article will cover setting up redundant ISPs for outbound connectivity on an ASA 5510 (although the same should work on the 5520s and up as well).  It’s important to note that this covers outbound connectivity only.  The ASA does not have built…
This demo shows you how to set up the containerized NetScaler CPX with NetScaler Management and Analytics System in a non-routable Mesos/Marathon environment for use with Micro-Services applications.
Polish reports in Access so they look terrific. Take yourself to another level. Equations, Back Color, Alternate Back Color. Write easy VBA Code. Tighten space to use less pages. Launch report from a menu, considering criteria only when it is filled…

708 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

16 Experts available now in Live!

Get 1:1 Help Now