VPN from Branch with NAT

R

rt

Hello,

Having a problem completing my VPN/NAT setup using RRAS. This is what I
have:

Corporate Office at address CorpIp (public)
Branch Office at address BranchIp (public)

Branch Office server has two NICS one at BranchIp and the the other at
BranchPrivateIp (192.168.1.1)
NIC at BranchIp connected to DSL/Modem
NIC at 192.168.1.1 to local hub
Branch Office has DHCP and DNS and all clients get there gate as 192.168.1.1

I only have one public IP at the branch office and I've entered that single
IP by setting the Address Pool under the properties for the public interface
by selecting Server_Name - IP_Routing - NAT/Basic_Firewall.

I've created a demand dial interface and one IP static route. From the
BranchIp server everything works fine. The client machines have a problem.
They can see the internet but when I ping the corporate server I get
"Request timed out". I'm sure I'm missing another static route but I've not
been able to enter it correctly.

Thanks,

Rick
 
B

Bill Grant

Everything will work from the branch server because it will access the
corporate network using its public IP. The corporate router will have a
route back to it. But the branch clients need to access the corporate LAN
using their private IP addresses (ie their 192.168.1 addresses).

For this to work, the router at the corporate end needs to know how to
reach the private addresses at the branch. The best way to achieve this is
to use a demand-dial interface (called something like "frombranch1" ) on the
corporate VPN server. Then set up a static route linked to this interface
(using the static route wizard) to route to the branch subnet. (That is,
192.168.1.0 subnet 255.255.255.0 interface "frombranch1" ) .

When the branch connects to corporate, the username for the connection
should match the demand-dial interface name (eg frombranch1). This binds the
interface to the VPN connection, and thus the static route to 192.168.1.0 is
bound to the VPN connection. The corporate router now has a route to
192.168.1.0 through the VPN tunnel.

You now have routes at both ends to send traffic for the "other" subnet
through the VPN link, and routing should work from the workstations.
 
R

rt

Bill,

Well it worked partially. When the corporate server was connected, the
clients could get to it but not to the internet. In addition, I'm not sure
they used the VPN connection because some of the ports that our open on the
server, but shutdown through the ISP, could not be accessed. That implies to
me the route wasn't via the VPN. When the branch server connects it can use
the ports fine.

Here is a more detailed run down of my setup.

Corporate server is running AD for company.com, DNS (AD integrated) and RRAS
with the domain being company.com. The available address, which have not
been put into RRAS are x.y.68.32 through 47. I've only bound .32 and .47 to
the NIC. .32 is the "real" public ip and I use .47 for VPN connections.

The branch server has AD for company.com, DNS for private IPs (not AD
integrated) and the name is branch1.company.local with a reverse lookup zone
for 192.168.1.0. Also DHCP for range 192.168.1.50 to 150 and WINS. The
branch IP is 192.168.1.1 and I have scope values for DHCP of gate:
192.168.1.1, DNS: 192.168.1.1, WINS: 192.168.1.1, Domain:
branch1.company.local.

For the local (private) NIC I don't register with DNS. I make a manual entry
for the AD integrated zone in company.com of the public IP and for zone
branch.company.local I add the local IP of 192.168.1.1.

When I installed RRAS on the branch server I did the following:

1) Selected VPN access and NAT

2) Selected NIC at set to public IP for the internet interface and left
checked basic firewall.

3) Selected DHCP for client ips

4) Did not use RADIUS server

5) Configured DHCP relay agent

At this point the clients see the corporate server (not via VPN since it is
not set up yet) and they see the internet.

Now, for the VPN setup on the branch server:

Add new dial demand dial interface named ToCorporateServer

1) Accept defaults

2) Enter IP of x.y.68.47

3) Add static route of x.y.68.0, subnet 255.255.255.0 (Routes more that I
need but doesn't matter)

4) Take remaining defaults

Now, once connected the clients can still "see" the net but no longer the
server.



On the server I did as you suggested.

Added demand dial with ip of x.z.72.212 (Public IP at branch) and route of
192.168.1.0 subnet 255.255.255.0.

Clients can now see corporate server but not internet and it doesn't appear
clients actually use a VPN connection as indicated above.

One more thing, when I installed RRAS on the server I just did private
network connection.

Hope this helps,

Thanks,

Rick
 
B

Bill Grant

You have a strange hybrid system here, and you will have lots of
problems. (Not just with routing).

Connecting two sites by a router-to-router VPN connection is usually
done when both sites are running private addresses. The VPN connection makes
a connection through the Internet which you then use to route the private
addresses.

If your corporate LAN is running public addresses, you will have a few
extra problems. You have to ensure that the public IPs at corporate are
actually accessed through the VPN, not directly through the Internet using
NAT. So you will need to make the VPN connection persistent and ensure that
the subnet routes bind to the VPN tunnel endpoints.

AD is a further complication. I would not attempt to set up AD at the
branch until routing and name resolution were working perfectly. Here again
you have the problem that AD at the corporate site uses public IPs, but AD
at the branch site should be integrated with the private IP addresses.

I am not sure why you are allocating IP addresses to your demand-dial
interfaces. I prefer to let DHCP and the RRAS servers look after that. It is
very easy to lose track of what you are doing. As far as routing is
concerned, tie your static routes to the demand-dial interfaces. The system
will then ensure that the routes are bound to the connection. The routes
must bind to the IP addresses actually allocated by the RRAS server when the
connection is set up. Let the system do that for you. Just regard the
demand-dial interfaces as the symbolic names of the VPN connection
endpoints.
 

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. After that, you can post your question and our members will help you out.

Ask a Question

Top