Hi,

I've run into a bit of a problem, I hope someone with more PIX experience
then myself can help out.

Situation: A small LAN (about 20 PCs, file server, 2 or 3 printers and an
"information server" users on the LAN telnet into) connected to the internet
via cable and a PIX 506e.  The PIX is also setup as a PPTP VPN endpoint so
users can access the information server from home.  That's the idea anyway.
When I connect via PPTP, I can access the file server with no problems (both
ping and by mapping a drive).  I can access each PC on the LAN, each print
server.  Everything except....the information server.  Which was the whole
point to begin with.  I don't want to simply forward port 23 TCP because
that's...well you know.

The LAN subnet is 10.1.1.0 /24.  PPTP users are assigned addersses from
10.1.2.1-10.1.2.10.  The PIX is 10.1.1.1.  All the PCs are assigned
addresses via DHCP from the PIX.  The information server was setup by a 3rd
party.

My best guess is that the info server does not have a default gateway set.
I don't have admin access to this server.

I'm not all too familiar with the PIX CLI...can I setup a static NAT for the
server so the PPTP users can gain access?  Something along the lines of
10.1.2.2 translating to 10.1.1.2.  Would this even have a chance of working?

I tried changing the PPTP address pool to 10.1.1.150-10.1.1.160 but I have a
feeling that will either just not work or I f'd up the syntax.  Maybe I was
on the right track?

Any help is greatly appreciated.

rrfield

In article <fxynd.360928$wV.140549@attbi_s54>,
Richard R. Field <rrfield@NOSPAM.alumni.indiana.edu> wrote:
:via cable and a PIX 506e.  The PIX is also setup as a PPTP VPN endpoint so

:When I connect via PPTP, I can access the file server with no problems (both
:ping and by mapping a drive).  I can access each PC on the LAN, each print
:server.  Everything except....the information server. 

:The LAN subnet is 10.1.1.0 /24.  PPTP users are assigned addersses from
:10.1.2.1-10.1.2.10.  The PIX is 10.1.1.1.

:My best guess is that the info server does not have a default gateway set.

Sounds plausible.

:can I setup a static NAT for the
:server so the PPTP users can gain access?  Something along the lines of
:10.1.2.2 translating to 10.1.1.2.  Would this even have a chance of working?

I haven't worked with PPTP, so I'm not sure. I seem to recall that each
PPTP address is assigned with a 255.255.255.255 netmask, so that
(for example) broadcasts that happen to be needed for one PPTP user don't
get sent to another PPTP user. If this is true, then the PPTP users are
effectively each on separate networks, and 10.1.2.2 would be
foreign to each of them.


If the traffic that needs to be carried between the PPTP users and the
information server is pure UDP and TCP (icmp -might- work as well
but I wouldn't count on it) then it seems to me that in theory you could
set up reverse NAT. That is, you would set up:

nat (outside) 20 10.1.2.1 255.255.255.255
nat (outside) 20 10.1.2.2 255.255.255.255
nat (outside) 20 10.1.2.3 255.255.255.255
....
nat (outside) 20 10.1.2.10 255.255.255.255

global (inside) 20 10.1.1.2

This would do Port Address Translation on all of the TCP and UDP traffic
from each of the outside IP addresses defined in a 'nat 20' rule,
translating the source IP into 10.1.1.2 as it went towards your LAN.
Your information server should then see that IP as local and should
thus be able to reply to it; the replies would get un-PAT'd and sent to
the appropriate PPTP user.

If the traffic to some of the other systems doesn't fit the TCP + UDP
only model, then you could get creative with "policy nat".
-- 
   I've been working on a kernel
   All the livelong night.
   I've been working on a kernel
   And it still won't work quite right.      -- J. Benson & J. Doll

"Walter Roberson" <roberson@ibd.nrc-cnrc.gc.ca> wrote in message
news:cnmd47$kgv$1@canopus.cc.umanitoba.ca...
> In article <fxynd.360928$wV.140549@attbi_s54>,
> Richard R. Field <rrfield@NOSPAM.alumni.indiana.edu> wrote:
> :via cable and a PIX 506e.  The PIX is also setup as a PPTP VPN endpoint
so
>
> :When I connect via PPTP, I can access the file server with no problems
(both
> :ping and by mapping a drive).  I can access each PC on the LAN, each
print
> :server.  Everything except....the information server.
>
> :The LAN subnet is 10.1.1.0 /24.  PPTP users are assigned addersses from
> :10.1.2.1-10.1.2.10.  The PIX is 10.1.1.1.
>
> :My best guess is that the info server does not have a default gateway
set.
>
> Sounds plausible.
>
> :can I setup a static NAT for the
> :server so the PPTP users can gain access?  Something along the lines of
> :10.1.2.2 translating to 10.1.1.2.  Would this even have a chance of
working?
>
> I haven't worked with PPTP, so I'm not sure. I seem to recall that each
> PPTP address is assigned with a 255.255.255.255 netmask, so that
> (for example) broadcasts that happen to be needed for one PPTP user don't
> get sent to another PPTP user. If this is true, then the PPTP users are
> effectively each on separate networks, and 10.1.2.2 would be
> foreign to each of them.
>
>
> If the traffic that needs to be carried between the PPTP users and the
> information server is pure UDP and TCP (icmp -might- work as well
> but I wouldn't count on it) then it seems to me that in theory you could
> set up reverse NAT. That is, you would set up:
>
> nat (outside) 20 10.1.2.1 255.255.255.255
> nat (outside) 20 10.1.2.2 255.255.255.255
> nat (outside) 20 10.1.2.3 255.255.255.255
> ...
> nat (outside) 20 10.1.2.10 255.255.255.255
>
> global (inside) 20 10.1.1.2
>
> This would do Port Address Translation on all of the TCP and UDP traffic
> from each of the outside IP addresses defined in a 'nat 20' rule,
> translating the source IP into 10.1.1.2 as it went towards your LAN.
> Your information server should then see that IP as local and should
> thus be able to reply to it; the replies would get un-PAT'd and sent to
> the appropriate PPTP user.
>
> If the traffic to some of the other systems doesn't fit the TCP + UDP
> only model, then you could get creative with "policy nat".
> -- 
>    I've been working on a kernel
>    All the livelong night.
>    I've been working on a kernel
>    And it still won't work quite right.      -- J. Benson & J. Doll

Thanks for the suggestion Walter.  The problem was what I suspected, the
server had the default gateway wrong.  I called tech support, they walked me
through the process and all is well.  I didn not get a chance to try your
sugestions, but thanks for the reply.

rf