Multi-servicing VPN server/router a feasible idea?

  • Thread starter Thread starter Aaron Seet
  • Start date Start date
A

Aaron Seet

We have an existing DC/VPN server that allows us to access the office LAN
from home. It has only one network card, sits behind a ADSL router, but
works pretty fine.

Now we're opening a second branch office, which will need to access the
file/print server here seamlessly. This looks like a router-router VPN
solution to bridge the 2 offices via the Internet. The other site should
therefore sport a similarly configured DC/VPN server.

The new office ain't ready yet, so there's no play chance for what I'm to
ask: It is a good idea to have the VPN server service both a router-router
interface between the office as well as connecting home workers?
 
These two services work quite happily together. They do not interfere
with each other. The client-server connections use the default internal
interface on the server. The router-to-router connection uses a demand-dial
interface, and the additional routing required to route between subnets is
linked to this demand-dial interface. When the router-to-router connection
is up, this extra route is added to the routing table, and only affects
traffic for the branch subnet.

The routing is unlikely to be disrupted. The "dialup" type clients use
the "virtual" IPs they receive at connection time, and the server sets up a
host route for each one. The branch clients use their branch private IPs,
which are routed by the static route descibed above.
 
Right, i believe there has to be a change in DHCP settings - to get the
office LAN workstations to use the VPN router as the default gateway instead
of the usual ADSL router?

That way it get can determine if traffic is bound for the public Internet
(and re-route to the ADSL router), or pass it through VPN tunnel if bound
for remote office. Now is the RRAS smart enough to do this automatically
once demand-dial is setup automatically, or is there a need to place a new
forwarding route in its routing table?



--
The melody of logic will always play out the truth.
- Narumi Ayumu, Spiral

"Bill Grant" <bill_grant at bigpond dot com> wrote in message

These two services work quite happily together. They do not interfere
with each other. The client-server connections use the default internal
interface on the server. The router-to-router connection uses a demand-dial
interface, and the additional routing required to route between subnets is
linked to this demand-dial interface. When the router-to-router connection
is up, this extra route is added to the routing table, and only affects
traffic for the branch subnet.

The routing is unlikely to be disrupted. The "dialup" type clients use
the "virtual" IPs they receive at connection time, and the server sets up a
host route for each one. The branch clients use their branch private IPs,
which are routed by the static route descibed above.
 
Not really. You can still use the router as the default gateway. All
you need is extra routing on the gateway router to "bounce" the VPN traffic
to the VPN server.

For instance, if your branch is using 192.168.121.0/24 , your VPN server
will have a subnet route for this subnet using the VPN link. If you add a
similar subnet route to the gateway router using the VPN server as the
target, it will bounce this traffic to the VPN server. This ensures that the
packets are encrypted and encapsulated before being sent back to the router
with a public IP address.

Without this route, the privately addressed packets would try to go
directly through the Internet and be dropped.

You can reconfigure your LAN to use the RRAS server as the default
gateway, but that requires other changes as well. You would need two NICs in
the RRAS server, and a link between the RRAS server and the router. The LAN
machines and this link must be in different IP subnets.
 
Thanks, I have configured the broadband router (192.168.252.1) with a static
route to forward packets destined for 192.168.251.0/24 (locally it's
192.168.252.0) over to the VPN server (192.168.252.4). Sure enough when you
traceroute it will bounce between 192.168.252.1 and 192.168.252.4 since the
VPN server still doesn't know what to do with it. So on to the next step....

I am trying to configure a new demand-dial interface in RRAS and can't find
the option to specify the address of the remote VPN site to connect to. In
the General properties the only device I can select is Direct Parallel
(LPT1)???

Well I certain don't want to use the parallel port, and this seems to
suggest I won't be able to configure the demand-dial interface properly to
connect to a public IP address until I install a second network card? Even
when both network cards would be belonging to the same private LAN?

The Microsoft document "Deploying Router-to-Router VPNs" keeps talking about
internal and public interfaces with assumption your servers will be laced
with 2 network cards and having a direct Internet connection with the public
one. Is there a workaround for only one network card?


Regards,
--
The melody of logic will always play out the truth.
- Narumi Ayumu, Spiral

"Bill Grant" <bill_grant at bigpond dot com> wrote in message
Not really. You can still use the router as the default gateway. All
you need is extra routing on the gateway router to "bounce" the VPN traffic
to the VPN server.

For instance, if your branch is using 192.168.121.0/24 , your VPN server
will have a subnet route for this subnet using the VPN link. If you add a
similar subnet route to the gateway router using the VPN server as the
target, it will bounce this traffic to the VPN server. This ensures that the
packets are encrypted and encapsulated before being sent back to the router
with a public IP address.

Without this route, the privately addressed packets would try to go
directly through the Internet and be dropped.

You can reconfigure your LAN to use the RRAS server as the default
gateway, but that requires other changes as well. You would need two NICs in
the RRAS server, and a link between the RRAS server and the router. The LAN
machines and this link must be in different IP subnets.
 
Please ignore this particular bit - for some reason i was given an option to
choose how exactly i wanted to initiate this deman-dial connection. I
deleted it and tried again and this time round it allowed to specify using
VPN/PPTP for this interface.

Now in order to test this i'll have to transport the new machine (configured
as DC for new AD tree + VPN router) back home where i have a broadband
network. We'll see if this setup works out.

If you spot any things I've missed out, please do point them out. Thank you!

Aaron
--
The melody of logic will always play out the truth.
- Narumi Ayumu, Spiral


I am trying to configure a new demand-dial interface in RRAS and can't find
the option to specify the address of the remote VPN site to connect to. In
the General properties the only device I can select is Direct Parallel
(LPT1)???
 
I have brought the machine for the branch office home, set my home router to
redirect requests for 192.168.252.0/24 (main office LAN) to 192.168.1.12
(VPN router). Now, when I initiate the demand-dial connection, the VPN
router itself can access the main office LAN no problem.

The problem comes with other PCs in my home - packets will travel from DSL
router to VPN router, and disappear there. I am assuming this is because the
VPN router at the main office can't make a second connection back to allow
bi-directional traffic. I have configured that VPN RRAS settings to match,
but it somehow cannot succeed in the connection. it will always throw

"An error occurred during connection of the interface. The connection was
closed."

Initially i thought it was failed credentials but I have set it correctly.
If i tried it with just a client VPN connection back to my home it won't
succeed either. What are other things I should look at?

Confused,
Aaron
 
UPDATE REPORT:

Yesterday morning, the main office VPN router _could_ connect reciprocally
to my branch VPN router (at home). Over the same PPTP tunnel apparently - it
didn't make a extra port 1723 connection back to my home public IP address.
In fact, it _can't_ as it will simply timeout in attempts, and for some
reason netstat doesn't reveal it making a 1723 connection out at all.

So I can only VPN from home to main office, but not the other way round. I
haven't confirmed this yet but perhaps my home ISP doesn't let incoming IP
protocol 47 GRE packets. Well at least I can connect one way and the
demand-dial interface in the main office VPN router kicks in automatically
to use the existing tunnel.

Next issue I should deal with is the static assignment of IP addresses on
either end - i was using DHCP to assign IP address so each time they
connected they were different. This will prove a minor problem for DNS and
WINS i believe. I tried to dish static IP by allocating it in the Dial-In
properties of the caller accounts.

Main office - domain1\site2router - 192.168.252.12
Branch office (home) - domain2\site1router - 192.168.1.4

I guess maybe it's the Branch VPN router that intiated the connection, thus
it does get 192.168.252.12 for its PPP interface. However on the other end
the Main VPN router is getting 192.168.1.196 or 193. So how can I stabilise
this assignment?


Aaron
 
The IP addresses which are allocate to the "virtual" interfaces of the
routers is not really of any consequence. You can set your RRAS server to
use a static pool and allocate addresses in a different subnet all together
if you like.

When a router to router VPN is set up, the machines in the two sites
reach machines in the other site by using their normal private IP addresses.
So branch machines access main office machines using their 192.168.252
addresses and main office machines access branch machines using their
192.168.1 addresses. These two subnets route through the VPN connection.

For this to work, each router needs a subnet route to the "other" subnet
through the VPN link. You accomplish this by linking the routes to
demand-dial interfaces. At the branch, the demand dial interface has an
associated static route for 192.168.252.0 . At the main office you have a
demand dial interface with an associated static route to 192.168.1.0 .

When you connect the router from the branch, you use as your username
the name of the demand dial interface at the main office. This binds the dd
interface to the connection, and the subnet route to the branch subnet is
added to the routing table. (You can set this up to allow connection from
either end if you so desire). Now the main office router has a route to
192.168.1.0 through the connection, and the branch has a route to
192.168.252.0 through the connection. So the VPN link works like a simple
(slow) IP router between the two subnets.

Once the routing works, you can modify your DNS to give you name
resolution as well.
 
Hi Bill,
All that you've stated has been done and worked. The only problems I have
now are

1. the main office VPN router's inability to initiate the dial to the branch
VPN router.
2. the main office VPN router's inability to grab the static IP addr
192.168.1.4 assigned to its caller account.

It is always the branch router calling in:
TCP 192.168.252.4:1723 220.255.68.154:2213 ESTABLISHED

It can _never ever_ call out, complaining "no answer". It never opens a
socket to the branch public IP at port 1723 anyway so I wonder how it even
attempted to connect. I cannot get a situation where it's

TCP 192.168.252.4:<ephemeral> 220.255.68.154:1723

EXCEPT until I disabled the demand-dial interface and tried a normal client
VPN connection back to branch and this was ok (and getting 192.168.1.4 to
boot). But just not the demand-dial.

Since the 2-way traffic is occuring on the same single PPTP tunnel, I
suspect that's why it can never get the stipulated static IP addr
192.168.1.4 for the deman-dial - technically it didn't dial in, it was the
branch which dialled in and got its static IP addr. It gets a
192.168.1.34-39 range as scoped by the branch DHCP server.

------------------------------------------------------------
C:\Documents and Settings\aaron.seet>ipconfig

Windows 2000 IP Configuration

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . : 192.168.252.4
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.252.1

PPP adapter RAS Server (Dial In) Interface:

Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . : 192.168.252.58
Subnet Mask . . . . . . . . . . . : 255.255.255.255
Default Gateway . . . . . . . . . :

PPP adapter {5B9BFBFF-EBD1-4924-887A-67591CF43944}:

Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . : 192.168.1.39
Subnet Mask . . . . . . . . . . . : 255.255.255.255
Default Gateway . . . . . . . . . :
------------------------------------------------------------

If I can uncover the mystery to these 2 points, I think I'll have an
excellent VPN solution for deployment. Any ideas?


Thanks,
--
The melody of logic will always play out the truth.
- Narumi Ayumu, Spiral


"Bill Grant" <bill_grant at bigpond dot com> wrote in message
The IP addresses which are allocate to the "virtual" interfaces of the
routers is not really of any consequence. You can set your RRAS server to
use a static pool and allocate addresses in a different subnet all together
if you like.

When a router to router VPN is set up, the machines in the two sites
reach machines in the other site by using their normal private IP addresses.
So branch machines access main office machines using their 192.168.252
addresses and main office machines access branch machines using their
192.168.1 addresses. These two subnets route through the VPN connection.

For this to work, each router needs a subnet route to the "other" subnet
through the VPN link. You accomplish this by linking the routes to
demand-dial interfaces. At the branch, the demand dial interface has an
associated static route for 192.168.252.0 . At the main office you have a
demand dial interface with an associated static route to 192.168.1.0 .

When you connect the router from the branch, you use as your username
the name of the demand dial interface at the main office. This binds the dd
interface to the connection, and the subnet route to the branch subnet is
added to the routing table. (You can set this up to allow connection from
either end if you so desire). Now the main office router has a route to
192.168.1.0 through the connection, and the branch has a route to
192.168.252.0 through the connection. So the VPN link works like a simple
(slow) IP router between the two subnets.

Once the routing works, you can modify your DNS to give you name
resolution as well.
 
It doesn't really matter which end initiates the connection. (Personally, I
prefer to have connections only initiate from the branch.) Once the
connection is up, either site can use it.

If the branch initiates the connection, the main office server will
never receive a 192.168.1.x address. Its "virtual" address will be
allocated by the main office RRAS server.
This is an "either/or" situation. If the branch office initiates the
connection, both ends will have 192.168.252 IP addresses. If the main
office initiates the connection, both ends will have branch office
(192.168.1.x) IP addresses. It really doesn't make any difference to the
routing. If you tie the routes to the demand dial interfaces, the system
looks after it all for you.
 
In that case, wouldn't it seem odd to have the main office VPN router still
get assigned a 192.168.1.3x IP address from the branch DHCP?


Aaron
 
Coming back today after new year, I _can_ connect from main to branch.
Finally. And also mysteriously. I cannot figure what prevented me from doing
so previously.

Anyway, sure enough my suspicion is confirmed - initiating the connection
this way certainly gains it the 192.168.1.4 IP address statically assigned
to the user account. Of course, that means the branch router doesn't get its
static allocation but the dynamic one.

I may have to shrug my shoulders on this one,
Aaron

--
The melody of logic will always play out the truth.
- Narumi Ayumu, Spiral



Since the 2-way traffic is occuring on the same single PPTP tunnel, I
suspect that's why it can never get the stipulated static IP addr
192.168.1.4 for the deman-dial - technically it didn't dial in, it was the
branch which dialled in and got its static IP addr. It gets a
192.168.1.34-39 range as scoped by the branch DHCP server.
 
Back
Top