[Webinar] Streamline your web hosting managementRegister Today

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 310
  • Last Modified:

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.
0
billwharton
Asked:
billwharton
  • 6
  • 6
1 Solution
 
lrmooreCommented:
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
 
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.
0
 
lrmooreCommented:
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
The Firewall Audit Checklist

Preparing for a firewall audit today is almost impossible.
AlgoSec, together with some of the largest global organizations and auditors, has created a checklist to follow when preparing for your firewall audit. Simplify risk mitigation while staying compliant all of the time!

 
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.
0
 
lrmooreCommented:
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
 
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.
0
 
lrmooreCommented:
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
 
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.

0
 
lrmooreCommented:
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
 
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.
0
 
lrmooreCommented:
Any progress? Are you still working on this? Do you need more information?
0
 
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: 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

Turn Raw Data into a Real Career

There’s a growing demand for qualified analysts who can make sense of Big Data. With an MS in Data Analytics, you can become the data mining, management, mapping, and munging expert that today’s leading corporations desperately need.

  • 6
  • 6
Tackle projects and never again get stuck behind a technical roadblock.
Join Now