Hello everyone, I have FINALLY resolved an ongoing issue with our VPN
connections that we have been experiencing for over a year now. I will share
these findings with this forum in case others can benefit from our
situation. First let me explain the problem.

The Problem:

It can take up 6 retries for any remote user to successfully created a
remote PPTP connection to our servers. Whenever we try to connect it display
the following message:

Verifying username and password...

And it sit there displaying this message for about 30-40 seconds, then it
says: "error: 721 The remote computer did not respond."

Network Setup:

We have two netopia routers on our network. They both have their own
separate WAN connection (we use a lot of bandwidth, hence the need for two
WAN connections). One RAS server is configured to use one router as it's
gateway, and the other RAS server uses the second router as it's gateway.
When PPTP connections are made, the connection comes in and back out the
same router (this I made sure). We use a multi-NAT for routing service
request to internal servers. FTP, WWW, RDP, PCAnywhere, SSL, PPTP, MAIL,
etc...all these services are routed to internal servers/workstations. We
have approximately 32 public IP addresses, hence why we use Multi-NAT for
routing public services to internal servers. Everything works perfectly,
EXCEPT PPTP (VPN) connections. We have struggled with this for a year now.
For whatever reason, it struggles to make a successful connection to our RAS
servers. Like I said, it can take up to 6 retries to successfully connect to
our RAS servers (up to 30 retries if the remote user is behind a Linksys
router).

The Fix:

Today, I decided to try something different. I decided to use the router's
public IP address for PPTP requests, instead of one of the other public IP
addresses our ISP assigned us, and simply forward PPTP (TCP 1723 & IP 47)
requests to the internal servers. Therefore, the only difference is that I
am using a pingable IP address which happens to belong to the router instead
of using one of the public IP addresses I have NATed. For whatever reason,
this solved our problem with connecting to the RAS server. We no longer have
to retry up to 6 times to successfully connect.

Conclusion:

I have NO clue as to why I have to use the router's public IP address rather
than any of the other 31 public IP addresses our ISP assigned to us. This
was ONLY an issue with the PPTP service. All the other services work
perfectly with the router's Multi-NAT table. In the end I don't know whether
it's a router issue (ie, Netopia has problems routing PPTP requests), or a
protocol issue (PPTP has problems when NATed), or whatever. All I can tell
you is that our specific problem was resolved by using the router's public
IP address for PPTP requests and then forwarding that request to our RAS
servers rather than using NAT to forward PPTP requests on a specific public
IP assigned to us from our ISP.

If anyone cares to comment on why it works perfectly this way, and not when
using a NATed IP addresses, I'd be happy to read and learn. Can it be an ISP
related issue? The type of network they form with their clients is a Bridged
network. Can a Bridged network be the reason PPTP struggles when NATed to an
assigned IP rather than when using the router's IP? By the way, the router's
IP is the only pingable public IP, not that that should make any difference
at all. All comments welcomed.

~Frank

Thanks Bill, I can assure you it's a big relief.

However, I am having trouble understanding your reply. Just to clarify. We
have 32 "static" IP addresses from our ISP. For example, we would use IPs:

208.38.4.101 => assigned as the router's public IP
208.38.4.102 => mail.mydomain.com
208.38.4.103 => ras2.mydomain.com ** doesn't like this **
208.38.4.104 => www.mydomain.com
208.38.4.105 => ftp.mydomain.com
208.38.4.106 => node32.mydomain.com
208.38.4.107 => node33.mydomain.com
208.38.4.107 => node34.mydomain.com

And so on, up to 16 static IPs for each router. I would give the router the
first IP address (208.38.4.101) and the rest I would use to NAT various
services to internal servers (ftp, www, smtp, pop, rdp, pptp, etc). So for
example, I might use NAT to redirect WWW which would resolve to 208.38.6.104
to an internal IP on port 80. I had, as an example, routed ras2.mydomain.com
(208.38.4.103) to some internal IP for PPTP connections only (netopia
routers have PPTP predefined which takes care of TCP port 1723 & GRE IP type
47) using NAT. However, it doesn't like that, I have to use the router's IP
(meaning I have to point ras2.mydomain.com to 208.38.4.101 in our DNS
servers) and then forward PPTP to the RAS server's internal IP. If I use any
of the other static public IPs, 208.38.4.102 - 208.38.4.116 in a NAT, it
would take up to 6 retries for the connection to successfully connect. But
this issue is only for PPTP connections. Any other service will work
perfectly when NATed regardless from which IPs static public IP's they come
in. It's only the PPTP service that doesn't seem to like this in our
situation, forcing me to use the router's IP address instead of the other 15
static IPs. I am not sure if I am clear on this? Or was this exactly what
you had interpreted from my previous posting and I am simply missing what
you're stating? If so, I apologize.

~Frank

"Bill Grant" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> Hi,
>
> First off, I am glad to hear you sorted out the problem. From you
> original posting, I admit I couldn't see any reason for the problem you
were
> having.
>
> Now that I see you resolution, it triggers off some memory cells.
There
> have been a few problems with PPTP from time to time with funny error 721
> problems. Usually 721 just indicates that GRE is being blocked. But it can
> also result from a reply from the server came from a different IP (ie
> different from the IP address the client used to send). This is a safety
> measure to prevent spoofing a reply.
>
> So I suspect that, with your previous setup, the reply was coming from
a
> range of different IP in the server's pool, and the connection only
> succeeded when the reply actually came from the same IP. Now that you use
a
> fixed IP, it always works.
>
> Incidently, you do not need to forward port 47. This is a widely held
> belief (even router manufacturers use it in their documentation), but it
is
> false. Port 47 (tcp or udp) has nothing to do with VPN. What is required
is
> IP protocol 47, or GRE. A PPTP connection will definitely fail if GRE is
> blocked at the router. But you do not need tcp port 47.
>
> Best wishes,
> Bill
>
> "Frank" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > Hello everyone, I have FINALLY resolved an ongoing issue with our VPN
> > connections that we have been experiencing for over a year now. I will
> share
> > these findings with this forum in case others can benefit from our
> > situation. First let me explain the problem.
> >
> > The Problem:
> >
> > It can take up 6 retries for any remote user to successfully created a
> > remote PPTP connection to our servers. Whenever we try to connect it
> display
> > the following message:
> >
> > Verifying username and password...
> >
> > And it sit there displaying this message for about 30-40 seconds, then
it
> > says: "error: 721 The remote computer did not respond."
> >
> > Network Setup:
> >
> > We have two netopia routers on our network. They both have their own
> > separate WAN connection (we use a lot of bandwidth, hence the need for
two
> > WAN connections). One RAS server is configured to use one router as it's
> > gateway, and the other RAS server uses the second router as it's
gateway.
> > When PPTP connections are made, the connection comes in and back out the
> > same router (this I made sure). We use a multi-NAT for routing service
> > request to internal servers. FTP, WWW, RDP, PCAnywhere, SSL, PPTP, MAIL,
> > etc...all these services are routed to internal servers/workstations. We
> > have approximately 32 public IP addresses, hence why we use Multi-NAT
for
> > routing public services to internal servers. Everything works perfectly,
> > EXCEPT PPTP (VPN) connections. We have struggled with this for a year
> now.
> > For whatever reason, it struggles to make a successful connection to our
> RAS
> > servers. Like I said, it can take up to 6 retries to successfully
connect
> to
> > our RAS servers (up to 30 retries if the remote user is behind a Linksys
> > router).
> >
> > The Fix:
> >
> > Today, I decided to try something different. I decided to use the
router's
> > public IP address for PPTP requests, instead of one of the other public
IP
> > addresses our ISP assigned us, and simply forward PPTP (TCP 1723 & IP
47)
> > requests to the internal servers. Therefore, the only difference is that
I
> > am using a pingable IP address which happens to belong to the router
> instead
> > of using one of the public IP addresses I have NATed. For whatever
reason,
> > this solved our problem with connecting to the RAS server. We no longer
> have
> > to retry up to 6 times to successfully connect.
> >
> > Conclusion:
> >
> > I have NO clue as to why I have to use the router's public IP address
> rather
> > than any of the other 31 public IP addresses our ISP assigned to us.
This
> > was ONLY an issue with the PPTP service. All the other services work
> > perfectly with the router's Multi-NAT table. In the end I don't know
> whether
> > it's a router issue (ie, Netopia has problems routing PPTP requests), or
a
> > protocol issue (PPTP has problems when NATed), or whatever. All I can
tell
> > you is that our specific problem was resolved by using the router's
public
> > IP address for PPTP requests and then forwarding that request to our RAS
> > servers rather than using NAT to forward PPTP requests on a specific
> public
> > IP assigned to us from our ISP.
> >
> > If anyone cares to comment on why it works perfectly this way, and not
> when
> > using a NATed IP addresses, I'd be happy to read and learn. Can it be an
> ISP
> > related issue? The type of network they form with their clients is a
> Bridged
> > network. Can a Bridged network be the reason PPTP struggles when NATed
to
> an
> > assigned IP rather than when using the router's IP? By the way, the
> router's
> > IP is the only pingable public IP, not that that should make any
> difference
> > at all. All comments welcomed.
> >
> > ~Frank
> >
> >
>
>

Here is what I meant to say. (Always easier after you think about it!)

Most clients check that they receive the reply from the IP to which they
sent the PPTP request. Here's how I think it works.

1. Using the router's "real" IP and port forwarding works, because the
client sends the request to the router's IP. When the server replies, the
packet goes to the NAT router, is modified by NAT and gets the router's
public IP as the sender's IP. So the client is happy.

2. If you use IP mapping, the client sends the packet to a pool IP which is
mapped to the RRAS server's LAN IP. But the reply goes through the same
channel as above, so the reply doesn't have this IP in the packet. It has
the router's public IP, so it fails.

3. I don't really know why sometimes you managed to connect by method 2. I
would expect it to always fail. You would need to do a lot of tracing and
sniffing to see what actually happens.

"Frank" <(E-Mail Removed)> wrote in message
news:eN#(E-Mail Removed)...
> Thanks Bill, I can assure you it's a big relief.
>
> However, I am having trouble understanding your reply. Just to clarify. We
> have 32 "static" IP addresses from our ISP. For example, we would use IPs:
>
> 208.38.4.101 => assigned as the router's public IP
> 208.38.4.102 => mail.mydomain.com
> 208.38.4.103 => ras2.mydomain.com ** doesn't like this **
> 208.38.4.104 => www.mydomain.com
> 208.38.4.105 => ftp.mydomain.com
> 208.38.4.106 => node32.mydomain.com
> 208.38.4.107 => node33.mydomain.com
> 208.38.4.107 => node34.mydomain.com
>
> And so on, up to 16 static IPs for each router. I would give the router
the
> first IP address (208.38.4.101) and the rest I would use to NAT various
> services to internal servers (ftp, www, smtp, pop, rdp, pptp, etc). So for
> example, I might use NAT to redirect WWW which would resolve to
208.38.6.104
> to an internal IP on port 80. I had, as an example, routed
ras2.mydomain.com
> (208.38.4.103) to some internal IP for PPTP connections only (netopia
> routers have PPTP predefined which takes care of TCP port 1723 & GRE IP
type
> 47) using NAT. However, it doesn't like that, I have to use the router's
IP
> (meaning I have to point ras2.mydomain.com to 208.38.4.101 in our DNS
> servers) and then forward PPTP to the RAS server's internal IP. If I use
any
> of the other static public IPs, 208.38.4.102 - 208.38.4.116 in a NAT, it
> would take up to 6 retries for the connection to successfully connect. But
> this issue is only for PPTP connections. Any other service will work
> perfectly when NATed regardless from which IPs static public IP's they
come
> in. It's only the PPTP service that doesn't seem to like this in our
> situation, forcing me to use the router's IP address instead of the other
15
> static IPs. I am not sure if I am clear on this? Or was this exactly what
> you had interpreted from my previous posting and I am simply missing what
> you're stating? If so, I apologize.
>
> ~Frank
>
> "Bill Grant" <(E-Mail Removed)> wrote in message
> news:%(E-Mail Removed)...
> > Hi,
> >
> > First off, I am glad to hear you sorted out the problem. From you
> > original posting, I admit I couldn't see any reason for the problem you
> were
> > having.
> >
> > Now that I see you resolution, it triggers off some memory cells.
> There
> > have been a few problems with PPTP from time to time with funny error
721
> > problems. Usually 721 just indicates that GRE is being blocked. But it
can
> > also result from a reply from the server came from a different IP (ie
> > different from the IP address the client used to send). This is a safety
> > measure to prevent spoofing a reply.
> >
> > So I suspect that, with your previous setup, the reply was coming
from
> a
> > range of different IP in the server's pool, and the connection only
> > succeeded when the reply actually came from the same IP. Now that you
use
> a
> > fixed IP, it always works.
> >
> > Incidently, you do not need to forward port 47. This is a widely
held
> > belief (even router manufacturers use it in their documentation), but it
> is
> > false. Port 47 (tcp or udp) has nothing to do with VPN. What is required
> is
> > IP protocol 47, or GRE. A PPTP connection will definitely fail if GRE is
> > blocked at the router. But you do not need tcp port 47.
> >
> > Best wishes,
> > Bill
> >
> > "Frank" <(E-Mail Removed)> wrote in message
> > news:(E-Mail Removed)...
> > > Hello everyone, I have FINALLY resolved an ongoing issue with our VPN
> > > connections that we have been experiencing for over a year now. I will
> > share
> > > these findings with this forum in case others can benefit from our
> > > situation. First let me explain the problem.
> > >
> > > The Problem:
> > >
> > > It can take up 6 retries for any remote user to successfully created a
> > > remote PPTP connection to our servers. Whenever we try to connect it
> > display
> > > the following message:
> > >
> > > Verifying username and password...
> > >
> > > And it sit there displaying this message for about 30-40 seconds, then
> it
> > > says: "error: 721 The remote computer did not respond."
> > >
> > > Network Setup:
> > >
> > > We have two netopia routers on our network. They both have their own
> > > separate WAN connection (we use a lot of bandwidth, hence the need for
> two
> > > WAN connections). One RAS server is configured to use one router as
it's
> > > gateway, and the other RAS server uses the second router as it's
> gateway.
> > > When PPTP connections are made, the connection comes in and back out
the
> > > same router (this I made sure). We use a multi-NAT for routing service
> > > request to internal servers. FTP, WWW, RDP, PCAnywhere, SSL, PPTP,
MAIL,
> > > etc...all these services are routed to internal servers/workstations.
We
> > > have approximately 32 public IP addresses, hence why we use Multi-NAT
> for
> > > routing public services to internal servers. Everything works
perfectly,
> > > EXCEPT PPTP (VPN) connections. We have struggled with this for a year
> > now.
> > > For whatever reason, it struggles to make a successful connection to
our
> > RAS
> > > servers. Like I said, it can take up to 6 retries to successfully
> connect
> > to
> > > our RAS servers (up to 30 retries if the remote user is behind a
Linksys
> > > router).
> > >
> > > The Fix:
> > >
> > > Today, I decided to try something different. I decided to use the
> router's
> > > public IP address for PPTP requests, instead of one of the other
public
> IP
> > > addresses our ISP assigned us, and simply forward PPTP (TCP 1723 & IP
> 47)
> > > requests to the internal servers. Therefore, the only difference is
that
> I
> > > am using a pingable IP address which happens to belong to the router
> > instead
> > > of using one of the public IP addresses I have NATed. For whatever
> reason,
> > > this solved our problem with connecting to the RAS server. We no
longer
> > have
> > > to retry up to 6 times to successfully connect.
> > >
> > > Conclusion:
> > >
> > > I have NO clue as to why I have to use the router's public IP address
> > rather
> > > than any of the other 31 public IP addresses our ISP assigned to us.
> This
> > > was ONLY an issue with the PPTP service. All the other services work
> > > perfectly with the router's Multi-NAT table. In the end I don't know
> > whether
> > > it's a router issue (ie, Netopia has problems routing PPTP requests),
or
> a
> > > protocol issue (PPTP has problems when NATed), or whatever. All I can
> tell
> > > you is that our specific problem was resolved by using the router's
> public
> > > IP address for PPTP requests and then forwarding that request to our
RAS
> > > servers rather than using NAT to forward PPTP requests on a specific
> > public
> > > IP assigned to us from our ISP.
> > >
> > > If anyone cares to comment on why it works perfectly this way, and not
> > when
> > > using a NATed IP addresses, I'd be happy to read and learn. Can it be
an
> > ISP
> > > related issue? The type of network they form with their clients is a
> > Bridged
> > > network. Can a Bridged network be the reason PPTP struggles when NATed
> to
> > an
> > > assigned IP rather than when using the router's IP? By the way, the
> > router's
> > > IP is the only pingable public IP, not that that should make any
> > difference
> > > at all. All comments welcomed.
> > >
> > > ~Frank
> > >
> > >
> >
> >
>
>

Oh, now I see what you are saying. That totally makes sense. I never thought
of that possibility. When I have time I can going to research this a little
further. Thanks for the insight Bill. Cheers!

Frank

"Bill Grant" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Here is what I meant to say. (Always easier after you think about it!)
>
> Most clients check that they receive the reply from the IP to which they
> sent the PPTP request. Here's how I think it works.
>
> 1. Using the router's "real" IP and port forwarding works, because the
> client sends the request to the router's IP. When the server replies, the
> packet goes to the NAT router, is modified by NAT and gets the router's
> public IP as the sender's IP. So the client is happy.
>
> 2. If you use IP mapping, the client sends the packet to a pool IP which
is
> mapped to the RRAS server's LAN IP. But the reply goes through the same
> channel as above, so the reply doesn't have this IP in the packet. It has
> the router's public IP, so it fails.
>
> 3. I don't really know why sometimes you managed to connect by method 2. I
> would expect it to always fail. You would need to do a lot of tracing and
> sniffing to see what actually happens.
>
> "Frank" <(E-Mail Removed)> wrote in message
> news:eN#(E-Mail Removed)...
> > Thanks Bill, I can assure you it's a big relief.
> >
> > However, I am having trouble understanding your reply. Just to clarify.
We
> > have 32 "static" IP addresses from our ISP. For example, we would use
IPs:
> >
> > 208.38.4.101 => assigned as the router's public IP
> > 208.38.4.102 => mail.mydomain.com
> > 208.38.4.103 => ras2.mydomain.com ** doesn't like this **
> > 208.38.4.104 => www.mydomain.com
> > 208.38.4.105 => ftp.mydomain.com
> > 208.38.4.106 => node32.mydomain.com
> > 208.38.4.107 => node33.mydomain.com
> > 208.38.4.107 => node34.mydomain.com
> >
> > And so on, up to 16 static IPs for each router. I would give the router
> the
> > first IP address (208.38.4.101) and the rest I would use to NAT various
> > services to internal servers (ftp, www, smtp, pop, rdp, pptp, etc). So
for
> > example, I might use NAT to redirect WWW which would resolve to
> 208.38.6.104
> > to an internal IP on port 80. I had, as an example, routed
> ras2.mydomain.com
> > (208.38.4.103) to some internal IP for PPTP connections only (netopia
> > routers have PPTP predefined which takes care of TCP port 1723 & GRE IP
> type
> > 47) using NAT. However, it doesn't like that, I have to use the router's
> IP
> > (meaning I have to point ras2.mydomain.com to 208.38.4.101 in our DNS
> > servers) and then forward PPTP to the RAS server's internal IP. If I use
> any
> > of the other static public IPs, 208.38.4.102 - 208.38.4.116 in a NAT, it
> > would take up to 6 retries for the connection to successfully connect.
But
> > this issue is only for PPTP connections. Any other service will work
> > perfectly when NATed regardless from which IPs static public IP's they
> come
> > in. It's only the PPTP service that doesn't seem to like this in our
> > situation, forcing me to use the router's IP address instead of the
other
> 15
> > static IPs. I am not sure if I am clear on this? Or was this exactly
what
> > you had interpreted from my previous posting and I am simply missing
what
> > you're stating? If so, I apologize.
> >
> > ~Frank
> >
> > "Bill Grant" <(E-Mail Removed)> wrote in message
> > news:%(E-Mail Removed)...
> > > Hi,
> > >
> > > First off, I am glad to hear you sorted out the problem. From you
> > > original posting, I admit I couldn't see any reason for the problem
you
> > were
> > > having.
> > >
> > > Now that I see you resolution, it triggers off some memory cells.
> > There
> > > have been a few problems with PPTP from time to time with funny error
> 721
> > > problems. Usually 721 just indicates that GRE is being blocked. But it
> can
> > > also result from a reply from the server came from a different IP (ie
> > > different from the IP address the client used to send). This is a
safety
> > > measure to prevent spoofing a reply.
> > >
> > > So I suspect that, with your previous setup, the reply was coming
> from
> > a
> > > range of different IP in the server's pool, and the connection only
> > > succeeded when the reply actually came from the same IP. Now that you
> use
> > a
> > > fixed IP, it always works.
> > >
> > > Incidently, you do not need to forward port 47. This is a widely
> held
> > > belief (even router manufacturers use it in their documentation), but
it
> > is
> > > false. Port 47 (tcp or udp) has nothing to do with VPN. What is
required
> > is
> > > IP protocol 47, or GRE. A PPTP connection will definitely fail if GRE
is
> > > blocked at the router. But you do not need tcp port 47.
> > >
> > > Best wishes,
> > > Bill
> > >
> > > "Frank" <(E-Mail Removed)> wrote in message
> > > news:(E-Mail Removed)...
> > > > Hello everyone, I have FINALLY resolved an ongoing issue with our
VPN
> > > > connections that we have been experiencing for over a year now. I
will
> > > share
> > > > these findings with this forum in case others can benefit from our
> > > > situation. First let me explain the problem.
> > > >
> > > > The Problem:
> > > >
> > > > It can take up 6 retries for any remote user to successfully created
a
> > > > remote PPTP connection to our servers. Whenever we try to connect it
> > > display
> > > > the following message:
> > > >
> > > > Verifying username and password...
> > > >
> > > > And it sit there displaying this message for about 30-40 seconds,
then
> > it
> > > > says: "error: 721 The remote computer did not respond."
> > > >
> > > > Network Setup:
> > > >
> > > > We have two netopia routers on our network. They both have their own
> > > > separate WAN connection (we use a lot of bandwidth, hence the need
for
> > two
> > > > WAN connections). One RAS server is configured to use one router as
> it's
> > > > gateway, and the other RAS server uses the second router as it's
> > gateway.
> > > > When PPTP connections are made, the connection comes in and back out
> the
> > > > same router (this I made sure). We use a multi-NAT for routing
service
> > > > request to internal servers. FTP, WWW, RDP, PCAnywhere, SSL, PPTP,
> MAIL,
> > > > etc...all these services are routed to internal
servers/workstations.
> We
> > > > have approximately 32 public IP addresses, hence why we use
Multi-NAT
> > for
> > > > routing public services to internal servers. Everything works
> perfectly,
> > > > EXCEPT PPTP (VPN) connections. We have struggled with this for a
year
> > > now.
> > > > For whatever reason, it struggles to make a successful connection to
> our
> > > RAS
> > > > servers. Like I said, it can take up to 6 retries to successfully
> > connect
> > > to
> > > > our RAS servers (up to 30 retries if the remote user is behind a
> Linksys
> > > > router).
> > > >
> > > > The Fix:
> > > >
> > > > Today, I decided to try something different. I decided to use the
> > router's
> > > > public IP address for PPTP requests, instead of one of the other
> public
> > IP
> > > > addresses our ISP assigned us, and simply forward PPTP (TCP 1723 &
IP
> > 47)
> > > > requests to the internal servers. Therefore, the only difference is
> that
> > I
> > > > am using a pingable IP address which happens to belong to the router
> > > instead
> > > > of using one of the public IP addresses I have NATed. For whatever
> > reason,
> > > > this solved our problem with connecting to the RAS server. We no
> longer
> > > have
> > > > to retry up to 6 times to successfully connect.
> > > >
> > > > Conclusion:
> > > >
> > > > I have NO clue as to why I have to use the router's public IP
address
> > > rather
> > > > than any of the other 31 public IP addresses our ISP assigned to us.
> > This
> > > > was ONLY an issue with the PPTP service. All the other services work
> > > > perfectly with the router's Multi-NAT table. In the end I don't know
> > > whether
> > > > it's a router issue (ie, Netopia has problems routing PPTP
requests),
> or
> > a
> > > > protocol issue (PPTP has problems when NATed), or whatever. All I
can
> > tell
> > > > you is that our specific problem was resolved by using the router's
> > public
> > > > IP address for PPTP requests and then forwarding that request to our
> RAS
> > > > servers rather than using NAT to forward PPTP requests on a specific
> > > public
> > > > IP assigned to us from our ISP.
> > > >
> > > > If anyone cares to comment on why it works perfectly this way, and
not
> > > when
> > > > using a NATed IP addresses, I'd be happy to read and learn. Can it
be
> an
> > > ISP
> > > > related issue? The type of network they form with their clients is a
> > > Bridged
> > > > network. Can a Bridged network be the reason PPTP struggles when
NATed
> > to
> > > an
> > > > assigned IP rather than when using the router's IP? By the way, the
> > > router's
> > > > IP is the only pingable public IP, not that that should make any
> > > difference
> > > > at all. All comments welcomed.
> > > >
> > > > ~Frank
> > > >
> > > >
> > >
> > >
> >
> >
>
>

[ccgeek]

All -

Just some additional information on this issue as I had to tackle it as part of a project we have been working on. I implemented port forwarding (See Netopia - Server List (Port Forwarding) - NQG_025 for addtional detail) as the previous poster suggested. I should note that in my case I used an external address that was separate from the router external address. After that, I had to go in to the Netopia NAT translation menu - show/change MAP list and make sure that the static nat I had set up to translate between the external/internal address of the VPN server was above the PAT rule that was set up. Once I did that, worked like a charm.