Hi Dennis,
1. To the best of my knowledge, the ip pool for the vpn clients has to
come from its own subnet. If it overlaps, how will the PIX know which
traffic to encrypt and send through the VPN tunnel? Once you have the
pool setup, you need to have an access list that defines interesting
traffic for the VPN, so it knows which traffic should not be NAT'ed and
instead should be encrypted and sent through the VPN tunnel (again,
having these addresses overlap with another subnet is bound to cause
problems as traffic is looked at by this acl).
2. Honestly, I'm surprised it works at all, so I don't know why your
vpn clients are getting any access to your boxes unless it's outside of
the vpn tunnel.
3. The acl you create to bypass NAT just applies to NAT and not really
an interface on your machine, so you don't have to worry about it
allowing spoofed Internet traffic into your network. Also, you don't
need an access list permitting traffic from the VPN to the inside
applied to your outside interface, because when traffic initially hits
the outside interface it is encapsulated in a valid Internet IP datagram
(with the valid source IP of the client). I think the only time you
would require an additional acl entry to specifically allow traffic
between the vpn-tunneled devices and your internal network is when you
are doing egress filtering. In that case, the acl should be on your
inside interface and again does not pose a threat of allowing spoofed
Internet traffic into your internal network.
Good Luck!
Bob Bunting
PhD, CISSP, CCNA, MCSE(NT4), MCP, Net+
Director of Information Systems
Families and Youth, Inc.
-----Original Message-----
From: Dennis Dimka [mailto:dennis.dimka@manna.com]
Sent: Monday, November 29, 2004 4:06 PM
To: Dennis Dimka; 'Firewalls Securityfocus'
Subject: RE: PIX PPTP - Nat bypass?
I should also note that I did issue the sysopt command to
generally allow PPTP traffic (sysopt permit-pptp)
_____
From: Dennis Dimka
Sent: Monday, November 29, 2004 5:04 PM
To: Firewalls Securityfocus
Cc: Dennis Dimka
Subject: PIX PPTP - Nat bypass?
Hello all;
I recently configured PPTP on our PIX 515E, and am able to
successfully establish a PPTP VPN connection from the outside. My
problem is this: it appears as though logically PPTP clients are coming
from the "outside" interface, as they can only access IP addresses and
ports that I allow into the outside interface (web, smtp, the usual).
While this makes sense from the perspective that the packets are
technically coming from the outside... shouldn't VPN clients have more
access, since they've authenticated?
My setup is pretty simple:
Outside int: x.x.x.x (public routable IP address)
DMZ int: 10.0.1.1/24
Inside int: 10.0.0.1/24
I've assigned an ip pool for PPTP clients of 10.0.0.40-10.0.0.44
(ip local pool mypool 10.0.0.40-10.0.0.44 mask 255.255.255.0)
In the couple of configuration examples I find on Cisco.com, the
IP pool for PPTP clients is always different than the inside interface
IP block. Where as in my current configuration, they're one in the same
(10.0.0.0/24)... or more accurately, my PPTP IP Pool is within the
subnet that the inside interface resides on. Cisco's online examples
use a completely different IP subnet for the PPTP pool (192.168.x.x, in
their examples), and (apparently) set up a NAT bypass (nat 0) from
internal/private network to PPTP pool subnet.
So... my questions to anyone who might know are:
1. Is having a completely separate subnet (as in cisco's
examples) the preferred way of doing it?
2. Is the reason I did not put the PPTP pool on its own
subnet perhaps the reason that authenticated PPTP VPN clients only have
the same access levels as someone coming in from the outside interface?
3. If I create an access list along the lines of 'permit ip
10.0.0.0 255.255.255.0 any' (to allow VPN users access to internal IP
addresses and ports-doesn't that open my network up to spoof attacks
(where users could spoof a source address of 10.0.0.x and effectively
bypass my firewall)?
Hope these questions make sense. Thanks in advance to anyone
who has any answers.
Dennis Dimka
Network Administrator
MFS, Inc.
dennis.dimka@manna.com
Desk: 651-905-7591
Mobile: 612-616-0817
Fax: 651-994-6594
