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
    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, Aug 26, 2003
    #1
    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:

    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" <> wrote in message
    news:%...
    > 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" <> wrote in message
    > news:...
    > > 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, Aug 26, 2003
    #2
    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.

    "Frank" <> wrote in message
    news:eN#...
    > 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" <> wrote in message
    > news:%...
    > > 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" <> wrote in message
    > > news:...
    > > > 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
    > > >
    > > >

    > >
    > >

    >
    >
     
    Bill Grant, Aug 27, 2003
    #3
  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

    "Bill Grant" <> wrote in message
    news:...
    > 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" <> wrote in message
    > news:eN#...
    > > 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" <> wrote in message
    > > news:%...
    > > > 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" <> wrote in message
    > > > news:...
    > > > > 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, Aug 27, 2003
    #4
  5. Frank

    ccgeek

    Joined:
    Sep 24, 2009
    Messages:
    1
    Likes Received:
    0
    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
    #5
    1. Advertisements

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Dave Roth

    RRAS + NAT + VPN == 721 error...Yikes!

    Dave Roth, Jul 10, 2003, in forum: Microsoft Windows 2000 RAS Routing
    Replies:
    1
    Views:
    3,139
    Bill Grant
    Jul 11, 2003
  2. Todd Gallina

    PPTP CONNECTION ERROR 721

    Todd Gallina, Jul 14, 2003, in forum: Microsoft Windows 2000 RAS Routing
    Replies:
    3
    Views:
    8,919
    Dave Roth
    Jul 15, 2003
  3. Rajendra Rait

    Error:721

    Rajendra Rait, Jul 31, 2003, in forum: Microsoft Windows 2000 RAS Routing
    Replies:
    2
    Views:
    8,081
    Carl DaVault [MSFT]
    Aug 4, 2003
  4. Carlos Gomez

    VPN Client error 721

    Carlos Gomez, Aug 5, 2003, in forum: Microsoft Windows 2000 RAS Routing
    Replies:
    3
    Views:
    9,869
    Marc Reynolds [MSFT]
    Aug 9, 2003
  5. Basil Copeland

    Error 721 and PPTPPING

    Basil Copeland, Aug 8, 2003, in forum: Microsoft Windows 2000 RAS Routing
    Replies:
    3
    Views:
    4,013
    Marc Reynolds [MSFT]
    Aug 9, 2003
Loading...

Share This Page