Client VPN to 2 organizations

SLR
Building a reputation

Client VPN to 2 organizations

In our current Meraki Environment, we have two organizations : test and production. One of my team members would like a work from home user be able to use the Client VPN for test and production. My only concern is if they do this, since the IP addressing schemes are pretty similar, what if they confuse test for production and vice versa when making changes? Do you think there a way to separate the two? Maybe supply the user with a test laptop and have them access the test organization and then use normal laptop for production? I don't even know if that will even work. The team member would like the user to be able to copy files from production into test...

 

Are there other ways to do this? Maybe I am also explaining it incorrectly because I am even confusing myself. The only people currently able to access the test network are myself and the people here in office via a port configured for test network access only. I have a separate laptop connected to that. 

 

I am not sure how it would work for a user remotely working from home and using the client vpn authorization to the MX

8 REPLIES 8
SoCalRacer
Kind of a big deal

Just to understand better, you have 2 organizations, 2 physical MXs, and 2 different WAN connections?

SLR
Building a reputation

Correct. 

SLR
Building a reputation

yes, that is correct. 

SoCalRacer
Kind of a big deal

You can create multiple Client VPN profiles on a laptop. Name them appropriately, and educate the user/team.

 

Here is some basic Powershell to create the profiles

 

$ServerAddress = "MerakiVPNDomainorPublicIP"
$ConnectionName = "VPNProfileName"
$PreSharedKey = "YourClientVPNKey"
Add-VPNConnection -Name "$ConnectionName" -ServerAddress "$ServerAddress" -TunnelType Lt2p -AllUserConnection -L2tpPsk "$PreSharedKey" -AuthenticationMethod Pap -Force
SLR
Building a reputation

thank you, I will propose that option and see what happens. 

Nash
Kind of a big deal

Assuming Win10, you can access either VPN as a split tunnel. Might help keep from flooding the test environment with all of your user's internet traffic.

 

You need to know the subnets that your end user needs access to. I'll use 192.168.5.0/24 and 10.10.37.0/27 as examples below.

 

Add this to @SoCalRacer's codeblock: 

 

Set-VpnConnection -Name $ConnectionName -SplitTunneling

Add-VpnConnectionRoute -ConnectionName $ConnectionName -DestinationPrefix "192.168.5.0/24"

Add-VpnConnectionRoute -ConnectionName $ConnectionName -DestinationPrefix "10.10.37.0/27"
SLR
Building a reputation

Someone from my team came up with the idea to rdp into the test network but only allowing specific IP addresses to be able to remote in. Is this something that can be done?

 

also had this request: 

Please enable client VPN on the test network so we can use it to connect to the Test network from the internet.  This will allow us to test various things on the test network while remote as well as give **** and **** access to the Test Network (which they currently do not have).  Work with team to assign the “accounts” to the test network VPN only. 

 

NOTE:   No one…  Repeat…  NO ONE should be using a corporate domain joined machine to access the test network.  That could end up being VERY bad!    If someone needs to access the test network… they should use a test network specific computer or a Non- domain joined computer…  even if VPNing into the test network. 

 

Any questions on any of this please let me know.

Nash
Kind of a big deal

Oh please don't do that. You're talking RDPing in from the outside world (Internet) into your test network? IP addresses can be spoofed fairly easily. Using a non-standard port means nothing in these days of port scanners.

 

I know devs demand RDP access all the time, but I strongly believe that requiring use of a client VPN is a reasonable security stance to take. It's not that hard to setup, and it's pretty simple to use. 

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels