Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people, just like you, are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
Solved

pix vpn group access list

Posted on 2004-10-19
12
286 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
PRTG Network Monitor: Intuitive Network Monitoring

Network Monitoring is essential to ensure that computer systems and network devices are running. Use PRTG to monitor LANs, servers, websites, applications and devices, bandwidth, virtual environments, remote systems, IoT, and many more. PRTG is easy to set up & use.

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

Free Tool: Postgres Monitoring System

A PHP and Perl based system to collect and display usage statistics from PostgreSQL databases.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

When I upgraded my ASA 8.2 to 8.3, I realized that my nonat statement was failing!   The log showed the following error:     %ASA-5-305013: Asymmetric NAT rules matched for forward and reverse flows It was caused by the config upgrade, because t…
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…
Both in life and business – not all partnerships are created equal. As the demand for cloud services increases, so do the number of self-proclaimed cloud partners. Asking the right questions up front in the partnership, will enable both parties …
As a trusted technology advisor to your customers you are likely getting the daily question of, ‘should I put this in the cloud?’ As customer demands for cloud services increases, companies will see a shift from traditional buying patterns to new…

807 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