PPTP and NAT

Hi All,
Here is the scenario:

PPTP Server -> Firewall -> Internet -> Firewall -> Client
192.168.x.x
192.168.y.y

I want to be able to NAT PPTP from one internal net to another after it had
been NAT'ed to and from the Internet. Can this protocol cope with this
scenario?

Thanks,
Pair

Yes, this works. PPTP doesn't have any problem with this. IPSec has problems
with NAT -- but even that has been solved with NAT-T.

Mike

"TwistedPair" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hi All,
> Here is the scenario:
>
> PPTP Server -> Firewall -> Internet -> Firewall -> Client
> 192.168.x.x
> 192.168.y.y
>
> I want to be able to NAT PPTP from one internal net to another after it
had
> been NAT'ed to and from the Internet. Can this protocol cope with this
> scenario?
>
> Thanks,
> Pair
>
>

In theory yes.

There is no relationship between what happens "outside" the Tunnel vs what
happens "inside" the Tunnel. They are two separate and distinct logical
datastreams. One connection "creates" the Tunnel while the other runs
"inside" the Tunnel after it is created.

The session inside the Tunnel only sees the Client at one end and the PPTP
Server at the other end,...it does not "see" either Firewall or the Internet
because those exist "outside" the Tunnel. Likewise the Firewalls or the
Internet can not "see" what is inside the Tunnel nor act upon it.


--

Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com


"TwistedPair" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hi All,
> Here is the scenario:
>
> PPTP Server -> Firewall -> Internet -> Firewall -> Client
> 192.168.x.x
> 192.168.y.y
>
> I want to be able to NAT PPTP from one internal net to another after it
had
> been NAT'ed to and from the Internet. Can this protocol cope with this
> scenario?
>
> Thanks,
> Pair
>
>

I need to clairify something besides my other post. You are not NATing
anything twice. The "second" NAT is occuring on the *decapsulated* traffic
after it is no longer part of the VPN Session. VPN only goes as far as the
"termination point" of the Tunnel,...beyond that VPN no longer exists. The
data stream is decapsulated at the end of the Tunnel and is just normal LAN
traffic from that point.

--

Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com


"TwistedPair" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hi All,
> Here is the scenario:
>
> PPTP Server -> Firewall -> Internet -> Firewall -> Client
> 192.168.x.x
> 192.168.y.y
>
> I want to be able to NAT PPTP from one internal net to another after it
had
> been NAT'ed to and from the Internet. Can this protocol cope with this
> scenario?
>
> Thanks,
> Pair
>
>

Hmm . . . Yeah, that is definitely a good point. But now that I know it can
be done, I need to figure out why it isn't working for me. I am doing port
forwarding from my firewall into the VPN server. A client on the outside
connects to the firewall, and gets to the "verifying username and password"
and it times out, and errors out. I have done a ton of searching for ways
to resolve the issue. The only things I found was to be sure that I am
forwarding TCP port 1723, and IP GRE protocol 47. Would there be anything
else I am missing?

Thanks,
Pair


"Phillip Windell" <@.> wrote in message
news:(E-Mail Removed)...
> I need to clairify something besides my other post. You are not NATing
> anything twice. The "second" NAT is occuring on the *decapsulated* traffic
> after it is no longer part of the VPN Session. VPN only goes as far as the
> "termination point" of the Tunnel,...beyond that VPN no longer exists. The
> data stream is decapsulated at the end of the Tunnel and is just normal
LAN
> traffic from that point.
>
> --
>
> Phillip Windell [MCP, MVP, CCNA]
> www.wandtv.com
>
>
> "TwistedPair" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > Hi All,
> > Here is the scenario:
> >
> > PPTP Server -> Firewall -> Internet -> Firewall -> Client
> > 192.168.x.x
> > 192.168.y.y
> >
> > I want to be able to NAT PPTP from one internal net to another after it
> had
> > been NAT'ed to and from the Internet. Can this protocol cope with this
> > scenario?
> >
> > Thanks,
> > Pair
> >
> >
>
>

If you get an error 721 it is probably caused by GRE being blocked. Since
the tunnelled data has a GRE header, anything blocking GRE in either
direction causes a failure. So check that GRE is not blocked by either
firewall. Even a personal firewall on the client can do it.

"TwistedPair" <(E-Mail Removed)> wrote in message
news:#(E-Mail Removed)...
> Hmm . . . Yeah, that is definitely a good point. But now that I know it
can
> be done, I need to figure out why it isn't working for me. I am doing
port
> forwarding from my firewall into the VPN server. A client on the outside
> connects to the firewall, and gets to the "verifying username and
password"
> and it times out, and errors out. I have done a ton of searching for ways
> to resolve the issue. The only things I found was to be sure that I am
> forwarding TCP port 1723, and IP GRE protocol 47. Would there be anything
> else I am missing?
>
> Thanks,
> Pair
>
>
> "Phillip Windell" <@.> wrote in message
> news:(E-Mail Removed)...
> > I need to clairify something besides my other post. You are not NATing
> > anything twice. The "second" NAT is occuring on the *decapsulated*
traffic
> > after it is no longer part of the VPN Session. VPN only goes as far as
the
> > "termination point" of the Tunnel,...beyond that VPN no longer exists.
The
> > data stream is decapsulated at the end of the Tunnel and is just normal
> LAN
> > traffic from that point.
> >
> > --
> >
> > Phillip Windell [MCP, MVP, CCNA]
> > www.wandtv.com
> >
> >
> > "TwistedPair" <(E-Mail Removed)> wrote in message
> > news:(E-Mail Removed)...
> > > Hi All,
> > > Here is the scenario:
> > >
> > > PPTP Server -> Firewall -> Internet -> Firewall -> Client
> > > 192.168.x.x
> > > 192.168.y.y
> > >
> > > I want to be able to NAT PPTP from one internal net to another after
it
> > had
> > > been NAT'ed to and from the Internet. Can this protocol cope with
this
> > > scenario?
> > >
> > > Thanks,
> > > Pair
> > >
> > >
> >
> >
>
>