Re: PIX VPN to both DMZ and INSIDE segments



In article <1129692794.915286.110310@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Tiffany <BradsKB@xxxxxxxxx> 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.
--
If you lie to the compiler, it will get its revenge. -- Eric Sosman
.