PIX VPN to both DMZ and INSIDE segments
Bookmark this page:
 Yahoo!
 Google
 Windows Live
 del.icio.us
 digg
 Netscape
|
|
||||||||||||||||
|
Posted by Tiffany on October 18, 2005, 2:29 pm
Please log in for more thread options Without explaining why we are doing this, I would like to know if it can be done. I currently have a PIX515E/R and I have a DMZ card that I am about to install. What I would like to do is allow some users to VPN in via the Cisco client to the DMZ and other users to VPN into the DMZ segment using the Cisco Client as well. It's ok if the people on the inside interface can access the DMZ but I don't want users who VPN into the DMZ segment to be able to reach the inside segment (unless we poke holes.) Questions: 1) Can this be done 2) Do I need two external addresses or just one 3) If only one IP then how does it know who is destined for which segment? 4) Are there any examples on how to do this ore what is unique about the config over normal VPN configs? Thanks for any assistance. Tiffany Inside = 10.10.0.0/24 DMZ = 192.168.200.0/24 Outside = Public | ||||||||||||||||
|
Posted by Walter Roberson on October 18, 2005, 9:15 pm
Please log in for more thread options :Without explaining why we are doing this, I would like to know if it :can be done. :I currently have a PIX515E/R and I have a DMZ card that I am about to :install. What I would like to do is allow some users to VPN in via the :Cisco client to the DMZ and other users to VPN into the DMZ segment :using the Cisco Client as well. That looks redundant ;-) :It's ok if the people on the inside interface can access the DMZ but :I don't want users who VPN into the DMZ segment to be able to reach :the inside segment (unless we poke holes.) :Questions: :1) Can this be done More Yes than No. :2) Do I need two external addresses or just one :3) If only one IP then how does it know who is destined for which :segment? Your VPN clients can only terminate on the "closest" interface to them. If you want to be able to terminate VPN clients on the DMZ interface itself, then either they have to be internal clients (attached to the DMZ segment), or else you have to have the DMZ attached to the outside world with a public IP. However, if you want your external VPN clients to be able to access DMZ resources but not inside resources, then simply don't turn on "sysopt connection permit-ipsec", and use the ACL on the outside interface to control access. If you are turning off nat for the VPN clients, then it becomes relatively easy: just permit the private IP range to the IPs of the defined DMZ resources. When you have permit-ipsec turned off, then the IP packets *after decapsulation* are run through the normal procedures appropriate for the interface they arrived on, the same as if they weren't IPSec. If the problem is to permit different groups of users to different DMZ resources, then create different vpngroups for them and assign them into different private IP pools, and then use the IP pool to control where they can go. -- "It is important to remember that when it comes to law, computers never make copies, only human beings make copies. Computers are given commands, not permission. Only people can be given permission." -- Brad Templeton | ||||||||||||||||
|
Posted by Tiffany on October 18, 2005, 11:33 pm
Please log in for more thread options Walter,
OK, I think I understood some of this. To clarify my redundant part I meant to say that some people need access to the DMZ and some to the INSIDE segment. My Inside segment is 10.10.0.1/24 My DMZ area is 192.168.50.1/24 (technically it is not being used as a DMZ it's just another interface. I want my normal users to VPN to the inside as they do currently, but now I want to create a way for the second group to VPN to the DMZ Segment only. The reason that I am doing this is that I have a group of uncontrolled users that need to be able to VPN into me from the outside so that I can remotely control their PCs. I can not VPN into them (not an option) and it's very important that I isolate them from my Private network. I want to avoid buying a second appliance and plugging it into my public segment so I was planning to just setup a PC on the DMZ and once they VPN in, I can connect to them for remote control. If this can not be done, I may just set up a PC in my DMZ running Windows Server and RAS and just let them connect all the way into the PC using simple PPTP but it's not my first choice. Can you explain what you mean by "clients can only terminate on the 'closest' interface"? Thanks | ||||||||||||||||
|
Posted by Walter Roberson on October 19, 2005, 12:13 am
Please log in for more thread options :To clarify my redundant part I
:meant to say that some people need access to the DMZ and some to the :INSIDE segment. Ah, that's not hard to do. :My Inside segment is 10.10.0.1/24 :My DMZ area is 192.168.50.1/24 (technically it is not being used as a :DMZ it's just another interface. :I want my normal users to VPN to the inside as they do currently, but :now I want to create a way for the second group to VPN to the DMZ :Segment only. Can do. :Can you explain what you mean by "clients can only terminate on the :'closest' interface"? Suppose your PIX outside IP is 123.45.67.89. Suppose you tried to static your PIX DMZ IP to the outside world, say as 123.45.67.94, and you wanted users to be able to terminate their VPN connection on that IP... i.e., have them specify their "peer" as 123.45.67.94. If in order to reach that 123.45.67.94 IP, the traffic would have to pass through a different PIX interface (on the same PIX) (i.e, the outside interface, 123.45.67.89) then the PIX wouldn't allow that. Suppose, though, that you had a second LAN 192.168.50/24 with user machines on that IP address range -- possibly because there is a router there and link to another office. In that case, where the 192.168.50 interface is the -first- interface that the traffic would hit, you could have users VPN from anywhere on that LAN to that interface PIX. You might, for example, do this if the users didn't exactly trust one another not to snoop on regular traffic. Third scenario: you have two public IP networks (or subnets), and your DMZ interface -and- your outside interface are both connected to the Internet. In such a case, which interface the user would terminate at would depend on which of the interface IPs they specified: as long as you have the cooperation of your WAN router in such a case, the traffic would not have to go through the outside interface of the PIX to reach the DMZ interface: it could go directly from WAN router to DMZ interface. VPNs do not need to terminate on the outside interface, but they need to terminate on the interface that the relevant traffic first enters the PIX. Anyhow, as I said, all you need to do is turn off that sysopt, and create a second vpn group with a distinct name and password, use different IP pools for the different groups, and and set up the outside acl as appropriate. For example approximately something like this: names name 192.168.51.0 dmz_pool_net name 192.168.49.0 inside_pool_net name dmz_vnc_server 192.168.50.2 name inside_oracle_server 10.10.0.10 name inside_dns_server 10.10.0.3 ip address pool dmz_vpn_pool 192.168.51.17-192.168.51.31 netmask 255.255.255.0 ip address pool inside_vpn_pool 192.168.49.84-192.168.49.105 netmask 255.255.255.0 vpngroup dmz_vpn_group address pool dmz_vpn_pool vpngroup dmz_vpn_group name tiffsdmz password Excaliburr vpngroup inside_vpn_group address pool inside_vpn_pool vpngroup inside_vpn_group name tiffsclub password KnowsRainDear no sysopt connection permit-ipsec access-list Out2In permit ip dmz_pool_net 255.255.255.0 host dmz_vnc_server access-list Out2In deny ip dmz_pool_net 255.255.255.0 any access-list Out2In permit udp inside_pool_net 255.255.255.0 host inside_dns_server eq domain access-list Out2In permit tcp inside_pool_net host inside_oracle_server eq 1524 access-group Out2In in interface outside With this configuration, the members of the dmz vpn pool cannot reach anything on the inside interface because the IP address range they are in (192.168.51/24) is not permitted access to the other resources by the controlling access list (Out2In). There is no need of anything special to block access between the two VPN groups: just don't allow the unwanted accesses and they won't be able to get there. All done by discrimination based upon the IP address dynamically assigned, which is selected according to which vpn group name they log in to. -- If you lie to the compiler, it will get its revenge. -- Eric Sosman | ||||||||||||||||
| Similar Threads | Posted |
| PIX VPN to both DMZ and INSIDE segments | October 18, 2005, 2:29 pm |
| multicasting across segments | June 30, 2008, 2:10 pm |
| Configuring an inside nat group on inside interface | April 10, 2006, 4:38 pm |
| Cisco 837 - how to set up Inside to Inside NAT for DNS resolution? | May 23, 2006, 2:00 pm |
| PIX DMZ to the Inside. | February 10, 2005, 6:33 pm |
| DNS inside DMZ | September 30, 2005, 5:01 am |
| what does this mean ? (inside,outside) | October 2, 2006, 1:06 pm |
| PIX 7.0 ACL inside/outside help ! | December 22, 2006, 5:54 am |
| Inside to Inside NAT | April 11, 2007, 5:08 pm |
| help with pix inside->outside + dmz->outside + inside->outside->dmz | September 18, 2007, 9:57 pm |
| DNS inside the DMZ on an 877 | January 1, 2008, 3:25 am |
| NAT INSIDE | January 22, 2008, 7:50 pm |
| Ip NAT inside ... extendable. | September 6, 2005, 5:45 am |
| nat (inside) 0, global and VPN | September 22, 2005, 4:22 pm |
| ip nat inside and outside at the same time. | November 8, 2005, 6:42 pm |