VPN for 3 Sites

[chuckbalogh]

I have 3 sites that I need to network together.  My primary reason for this is to allow anyone to print to any location from any location.  I am looking for the best practice for this.  My plan right now is to use an RV320 at each site  and have two VPN's  connected to the third site (like a hub).  Is this the correct and/best  way too  do this?  At one  point, I thought about adding a 3rd  VPN between the two satellite sites as well.   

Any guidance would be appreciated. 

[balaji.bandi]

RV320 - meant to be small business edge router(in cisco point of view) at branch office. 

But your task can be achived by doing mesh vpn so all sites can talk each other and share the resources.

[chuckbalogh]

Thank you for your response.  So for a mesh vpn config, I  would have 3 VPN's  as is shown  below. 

Site A to Site B (VPN #1)

Site B to Site C (VPN #2)

Site C to Site  A (VPN #3)

What difference will users experience if I don't  add the 3rd VPN (above).  Is it mainly the speed?  Maybe occasional congestion?  No site is actually a hub.  The hub is where the boss is on that day.  

In the end, it probably doesn't make any sense to NOT add the 3rd VPN as there  is no extra cost (other  than to configure it).

Please let me know if you concur?

[chuckbalogh]

A bit more about the application.  This is a 3 location real estate company.  In total they have about 25 agents but only 4 or 5 full time employees (1 or 2 at each site).  Their main goal in implementing this is to be able to  print to any printer from any location.  They have  no main database or  application. Their real estate apps are all web based and accessible from anywhere.  

I hope  this helps.

[fmarshall]

Yes, you have the right idea.  Add one VPN between the two satellite sites.  The RV320s support this nicely.

[chuckbalogh]

Thank you.  I just want to make sure I understood. 

The solution will have two VPN's

So site A is connected to Site B via VPN (VPN #1)

And site B is connected to Site  C via a VPN (VPN #2)

As long as I configure it for the Local Security Group as subnet (and not just one address) this config will have the look and feel of 1 network for all users.

I should have been clearer in my original post

[balaji.bandi]

if you like A like to talk to C, you can build another VPN with C. so all meshed, not required all the way go to B if you like to reach C.

[chuckbalogh]

Thanks for the input.  The sites are less than  10 miles apart so I  don't think that I have to worry too much about  delay. 

I guess my fear or concern is a looped connetion route.  With a simple hub-spoke topology, the path to any resource is clear and  there is no path for a looped connection (With Mesh, If A needs  a resource on C but goes through B to get to C.  I'm not even sure how that would manifest itself.  How can  this looped connection  scenario be managed  in a Mesh topology?

[fmarshall]

I don't know what kind of traffic you'd need to worry about looping.  These aren't switches.  

Traffic is *routed* from one site to another via one of the VPNs.  Once there, it has no reason to traverse to another site (and no address for doing so).  At least that's my understanding of how things work.

Even if you allow NetBIOS traffic, it goes from one site/subnet to another.  I've certainly done this and there were no problems other than having name service over NetBIOS was not something anyone could advise me on really.  So I abandoned it as not being supportable by the community.  But, while it was there, it worked.  These days, that kind of name service is going away.

With VPNs there should not be the type of path that you describe going from A to C through B.  The paths remain clear just as in a hub and spoke arrangement.  In fact, the paths from B to C and from C to B are *clearer* as A would not be involved by any mechanism.  In words, the routing looks like this example:

Subnet A 10.0.1.0/24  Public address: 1.1.1.1

Subnet B 10.0.2.0/24  Public address: 1.1.1.2

Subnet C 10.0.3.0/24 Public address: 1.1.1.3

VPN A-B from 1.1.1.1 to 1.1.1.2 with terminating subnets 10.0.1.0 and 10.0.2.0.  Nothing about C here.

VPN A-C from 1.1.1.1 to 1.1.1.3 with terminating subnets 10.0.1.0 and 10.0.3.0.  Nothing about B here.

VPN B-C from 1.1.1.2 to 1.1.1.3 with terminating subnets 10.0.2.0 and 10.0.3.0.  Nothing about A here.

A packet launched in subnet X and destined for subnet Y will be routed to the X-Y VPN and the packets will arrive at subnet Y and that is all.  Perhaps that's a bit of a simplification but I think that's all there is to it.  Well, except the return path has to be supported and that generally involved the recipient's local gateway.  If the gateways ARE the VPN devices then this isn't generally an issue.  If the VPN devices are separate from the gateways then the gateways have to know the local IP address for the VPN and route packets accordingly.