billwharton
asked on
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.
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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...
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...
ASKER
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.
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?
How does this relate to the VPN users and sysopt? Just the fact that there is an acl on the inside interface?
ASKER
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.
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.
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.
ASKER
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
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
ASKER
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?
ASKER
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?
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?
ASKER
I would appreciate if you could try this out in your lab.