In article , Tiffany wrote: :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.