VPN Home Office and Customer

[AleMonteiro]

Hi guys.

I have an Cisco DPC3925 router at the Office which I use to close an VPN Tunnel with an customer.

Now, I want to close an VPN from my Home to the Office, so I'll be able to connect to the customer VPN from home.

Would this work? If so, is this model(Cisco DPC3925) up for the job? And in my Home, which router should I get?

Thanks!

[JorgeM]

Does the customer's VPN solution not allow you to connect to it using a VPN client (endpoint)? It sounds like you are trying to set up branch office tunnels instead.

[AleMonteiro]

JorgeM, the VPN with the customer is site to site.

[AleMonteiro]

Sorry, I was on the phone and couldn't take much time, so, to make it clear....

I'm using the Cisco DPC3925 to build an VPN Tunnel Site to Site (Lan in the Office to Lan in the Customer).

Now I want to make an VPN Tunnel Client to Site (My PC at home to the Lan in the Office).
I'm hopping that this way I'll be able to access the Customer Lan from my home.

Is it clear now? And more important, is it possible?

Thanks.

[JorgeM]

Yes of course its possible but it would depend on the ability to configure the network to allowing this routing to occur.

I'm not familiar with these specific devices but routing is routing. You'll need to look at the configuration on these VPN devices to see if there is a section for you to create the necessary routes so that traffic flows as you intend it to as reflected in the routing tables. Aside from the layer 2 tunnels created, these VPN devices/gateways can route as well.

I wish I can give you more specifics. Maybe someone else that may have more knowledge about these devices can be more specific.

[CimmerianX]

Typical hub and spoke VPN model.

Your office is the hub with the 2 b2b VPN tunnels terminated to it.

The trick to getting your home office to speak with the customer office is to have the customer's subnets included in your home office crypto maps for encapsulation. And vice versa, your customer's site must have your home office's subnet in it's tunnel spec so that packets from the customer site are encrypted over the b2b tunnel as well.

There is no routing involved here and the whole system would work based on the crypto map matches at each location's perimeter endpoints.

I've done these types of setups alot. It's not complicated until you run into issues with duplicate subnets at remote sites. If your home office, office, and customer office all use unique subnetting schemes, it's a snap. Otherwise you need to worry about natting the traffic before crypto map encapsulation.

[AleMonteiro]

JorgemM, CimmerianX, thanks for the knowlodge guys!

Now let's go into specifics...

My Customer subnet is 192.168.20.0
My Office subnet is 192.168.10.0
My Home subnet is 192.168.5.0

This way, for what I understood, my Customer VPN should allow 192.168.0.0 (or have two subnets .10 and .0). Right?

But this isn't my best scenario, because I don't want the customer to know (because he woulnd't allow it, it's a big company with lots of rules).

In my home, I don't need subnet, Is just one pc that needs access.

So, If I change my home subnet to 192.168.10 (same as office), and use an static IP on my pc, keeping it different from any IP in the Office (IE. Office DCHP goes from 10.1 to 10.120, Home IP would be 10.130).

Would this work? If not, is there any way that I can put my home pc in the same subnet of the office, so my customer doesn't have to change it's settings?

Thanks again =)

[CimmerianX]

It would not work like this.

First, if your customer won't allow it, should you really be doing this???

Use a jump host in your office. From any PC you can use something as simple a teamviewer to access a pc in your office which would then have access over VPN to your customer.

Or use a jump host. SSH to a host in your office, then ssh to the hosts at your customer site.

[AleMonteiro]

CimmerianX, I should probably ask permission first, but even if they allow it, it would be, with luck, for next year. Too many policies and rules. To allow the VPN to our Office, for a 6 month project, it took almost 3 months. The setup took 2 hours, but it took 3 months for the "approval".

About the jump host, I understand it would work, but it isn't a great solution for my use either.
The point of this VPN it's to access multiple projects(source code and spec) on SVN.
If I used a jump host, I would have to merge the versions on the host. I'd lost some of the SVN usefullness, or I'd have to install an SVN on the host to be able to use it well.
So, as far as I see, for now, using a jump host would be problematic.

Thanks for the suggestion anyway.

If it isn't asking too much, could you explain why my last ideas wouldn't work? Would it be because my home ip would be in the same subnet as the office? If this is the case, changing the mask or something could help?

Any other ideas in how to access a customer SVN from your home, through your office VPN with the customer?

Thanks again!

[CimmerianX]

You can't change your home subnet to match your office without new code to nat one or both sides before the crypto map evaluates the traffic.

From the customer side with a 192.168.20.0 subnet, you can't add a crypto for 192.168.0.0, that would cause problems.

What you could do is change your home network to a 192.168.11.0/24 leaving the office network at 192.168.10.0/24. From the client side, change the crypto map from 192.168.10.0/24 to 192.168.10.0/23 which would encrypt and tunnel both networks.

Your office vpn would need to change your home ACL from 192.168.5.0 to 192.168.11.0/24

Your Home vpn would need to encrypt traffic for 192.168.10.0/24 and 192.168.20.0/24

This is not the only way of doing it, but it is clean, easy to troubleshoot, involves no pre encryption NAT (yuch anyway), and is the smallest config change on the client side that I can think of.

[AleMonteiro]

Thanks CimmerianX!

I think I got your idea. I'm gonna prepar to and try it (I don't have a home router capable of VPN yet).

If I get stuck in the setup, I'll create another topic.

This one is solved.

Thanks once more!