error: 721 FINALLY RESOLVED! :)

[Frank]

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

 

[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]

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]

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

 

[ccgeek]

Additional Information on this

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.