Create VPN Profile or Group for a vendor to access specific internal server

[colesch]

Hello all,

We snagged a PA820 to replace an old ASA 5510. 

I think I have everything set and I am almost ready to cut over to the new PA firewall, with one exception: I am drawing a blank on the best way to setup VPN access for a support vendor.

With our current Cisco solution, the vendor starts up Cisco AnyConnect, and selects a group from a drop-down menu.

By selecting this group, it tells the ASA to authenticate the user against a local database, rather than our Active DIrectory.  Additionally, we control their access, and narrow them down to 2 servers only. 

What I am currently doing instead is using an authentication sequence that tries the localDb profile first, and then if no match is found, it moves on to the RADIUS auth profile.   I am concerned this will cause a login delay for my regular network users while the firewall checks the local db for a match.  Is this the only way I can do this?  Plus, how can I then change the available routes/hosts the local user can connect to?

[Mick_Ball]

we used a second portal for our 3rd party support but you may not have this option, although some favour the loopback as a second option.

both portals could point to same gateway to save extra licenses...

if it works as is then I would set Radius to first in auth order and local DB second.

assuming the largest proportion of users are on Radius.... if not then reverse the order.

so your support vendor will be tested against Radius but this will happen in a flash...

select "Enable user Identification" on your VPN zone for manipulating user policies.

if you need to be more selective with routing then add gateway agent configs to suit users.

i would not allow custom access routes (split tunneling) but it's your network.

[colesch]

Hi MickBall,

When you say a second portal, are you referring to a completely separate device?  Or, just adding another portal configuration under "Portals" on the firewall?  We are using a single PA820 so it is both the portal device and the gateway. Additionally, you say that you do not recommend using split tunneling, is that because GlobalProtect cannot filter end user web traffic?  I was thinking about routing all traffic through the tunnel so that we could continue to filter/monitor web activity, but I was shutdown from "higher up".

You had mentioned enabling user identification for the VPN zone...my thoughts exactly...I was going to set a security policy to only allow that one user to "See" the two servers I need them to see.

Thank you for your time, it is appreciated.

[BPry · Accepted solution]

@colesch,

Correct, you just want to add another Portal configuration. As long as everything uses the same gateway this avoids additional licensing as @Mick_Ball mentioned. 

Personally I recommend running everything through the VPN when connected simply so you can tell what the user is actually doing; did they just download a file to their local desktop and then upload it to Dropbox, is that an allowed action? It simply adds a little bit of extra security. 

When setting up Vendor access I would definately limit there ability to only the resources they actually need to access. I would also ensure that they are granted there own seperate IP Pool and disallow that IP range from accessing any sensitive resources at all. Your vendor probably doesn't need access to your File Servers and stuff like that; so I block that all with an overarching rule just so I know it'll never have access and I can record if they try. 

[Mick_Ball · Accepted solution]

yes, network\portals\add

this will require a second ip address on the external interface.

if you do not have spare ip addresses then others have used a loopback address so you would have one portal address :-

portal.domain.com   for your users, and another one :- portal.domain.com:4433  for support peeps.

yes yesy yes force all traffic through VPN, allow from vpn zone to trusted... just the 2 servers.

from vpn zone to internet.. just add common sense filtering to cover your own ar*e.

[colesch]

@Mick_Ball

So if I were to use the loopback option, I would have to craete a NAT translation to translate the WAN IP:<port#> to the loopback:<port#>, right? Or something along those lines?  I am sure tha tis in the manual somewhere... I think I got this.

Thank you @BPry and @Mick_BallMickB.

[Mick_Ball]

ok no problem...

yes you've got it.  there are loads of stuff on loopback on the interweb...

seemed a bit clunky for me..

Laters...

[colesch]

@Mick_BallHa, yea I was looking at the loopback previously; definitely convoluted. I do have other WAN IPs I can assign, I think I will try that route (no pun intended) first.

Later.

[Mick_Ball]

Good choice i say...

easier for diags as well, if anything ever goes wrong you will neeed to go back and re invent the wheel to remember how you set it up in the first place...

perhaps thats an age thing...

you could also consider cookie authentication overide from the new portal to the shared gateway, this will save having an authentication order with your other users.