error: 721 FINALLY RESOLVED! :)

Discussion in 'Microsoft Windows 2000 RAS Routing' started by Frank, Aug 26, 2003.

  1. Frank

    Frank Guest

    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

    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.


    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, Aug 26, 2003
    1. Advertisements

  2. Frank

    Frank Guest

    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: => assigned as the router's public IP => => ** doesn't like this ** => => => => =>

    And so on, up to 16 static IPs for each router. I would give the router the
    first IP address ( 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
    to an internal IP on port 80. I had, as an example, routed
    ( 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 to 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, - 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, Aug 26, 2003
    1. Advertisements

  3. Frank

    Bill Grant Guest

    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.
    Bill Grant, Aug 27, 2003
  4. Frank

    Frank Guest

    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, Aug 27, 2003
  5. Frank


    Sep 24, 2009
    Likes Received:
    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.
    Last edited: Sep 24, 2009
    ccgeek, Sep 24, 2009
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.