PC Review


Reply
Thread Tools Rating: Thread Rating: 1 votes, 1.00 average.

error: 721 FINALLY RESOLVED! :)

 
 
Frank
Guest
Posts: n/a
 
      26th Aug 2003
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


 
Reply With Quote
 
 
 
 
Frank
Guest
Posts: n/a
 
      26th Aug 2003
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
> >
> >

>
>



 
Reply With Quote
 
 
 
 
Bill Grant
Guest
Posts: n/a
 
      27th Aug 2003
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
> > >
> > >

> >
> >

>
>



 
Reply With Quote
 
Frank
Guest
Posts: n/a
 
      27th Aug 2003
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
> > > >
> > > >
> > >
> > >

> >
> >

>
>



 
Reply With Quote
 
New Member
Join Date: Sep 2009
Posts: 1
 
      24th Sep 2009
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.

Last edited by ccgeek; 24th Sep 2009 at 03:28 AM..
 
Reply With Quote
 
 
 
Reply

Thread Tools
Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
@#$% finally hits fan for Hotmail-in-OE users - FYI finally hits fan for Hotmail-in-OE users - FYI PA Bear [MS MVP] Microsoft Windows 2000 0 3rd Jun 2009 01:13 AM
@#$% finally hits fan for Hotmail-in-OE users - FYI finally hits fan for Hotmail-in-OE users - FYI PA Bear [MS MVP] Windows XP General 0 3rd Jun 2009 01:13 AM
Try...Catch...Finally not firing finally? David Lozzi Microsoft ASP .NET 12 11th May 2007 01:41 AM
try, catch, finally- whats the point of finally? Alan Paulk Microsoft C# .NET 7 11th May 2004 02:42 PM
Error Code 721 Erol Windows XP Help 1 26th Dec 2003 02:00 AM


Features
 

Advertising
 

Newsgroups
 


All times are GMT +1. The time now is 11:23 PM.