How to use Network Address Translation (NAT) for incoming Remote Access connections on the same Routing and Remote Access server (310888)

MORE INFORMATION

If you have one Routing and Remote Access server that acts as both a remote access server for dial-in or VPN clients and as a NAT for LAN clients, the LAN clients can access the Internet, but remote access clients have no Internet connectivity.

This occurs because the Routing and Remote Access server treats the incoming Remote Access connections as an external connection and tries to route these packets to the Internet. This does not work if the incoming Remote Access connections are using a private IP address range. These addresses are not routable on the Internet.

You can use either of the following two methods to work around this behavior:

• Use separate servers. Use one Routing and Remote Access server for incoming VPN or dial-up Remote Access connections and a different Routing and Remote Access server for NAT connectivity to the Internet.
• Routing and Remote Access uses the interface named "Internal" as an endpoint for the incoming Remote Access connections and can be used as a private interface under NAT in Routing and Remote Access. However, using the Routing and Remote Access MMC, you cannot add the "Internal" interface to NAT. To correct this problem, run the following command from the command prompt:

  netsh routing ip nat add interface internal private

  This command adds the interface (named "Internal" in this example) to NAT as a private interface. After you run this command, you should be able to refresh the Routing and Remote Access administration tool and see that the interface named "Internal" has been added to NAT as a private interface. This change allows the incoming Remote Access connections to be treated as private interfaces. Then, the Routing and Remote Access server would use NAT for those connections.
  
  Note When you run this commend, you may receive the following error message:
  NAT must be installed first.
  To work around this problem, manually stop the Routing and Remote Access service, run the command again, and then restart Routing and Remote Access. You can use the Routing and Remote Access administration tool to confirm that the "Internal" interface is present in NAT as a private interface.