VPN client + authenticated user permissions
HI
Several of my users are allowed elevated permissions when they authenticate to the Firewall on port 4100. They receive this via a policy that specifies their user ID's.
I am finding that these same user are given the permissions automatically when they connect via a VPN client, be it SSL or IKEV2.
Is there a way to stop this?
0
Best Answer
-
james.carson
Moderator, WatchGuard Representative
Hi @Tess
It's also worth noting that you can make a more advanced policy that has a few -and- options in it.In the from field of your policy, if you go to:
-WebUI, Add -> Find Custom in the type drop down.
-Policy Manager, Add -> Add Other, choose Custom from the drop down.You can add something like the group -and- the interface the user needs to come from.
-James Carson
WatchGuard Customer Support5
Sign In to comment.
Answers
1) set policies for the client VPN connections above the ones for the 4100 access. Depending on what the elevated access is, you may need to add policies which deny this access for the VPN user group names (ie. SSLVPN-Users) following the above policies.
or
2) have different user IDs for these users for each authentication method - via 4100 and via client VPN connections
Hi Bruce.
Thanks for the quick reply
The 4100 policy is restricted to internal ip address range ie 10.0.0.0 to Firebox
The VPN clients connect on 10.6.0
The policies for the users is set above the 4100 policy. I did think that this may work in reverse, so I moved the policies below the 4100 policy, but no change in use.
The policy allows certain Marketing members access to social media websites, with a more relaxed 'application control' setting.
Should i be looking at a different way of giving them access? They dont receive the automatically, only when they authenticate
Do you have separate HTTP & HTTPS policies for the VPN clients?
If not, add those above the HTTP & HTTPS policies for the 4100 users.
No, there is no policy for the VPN clients as access needs to be just from the network, so anyone that can authenticate from the 10.0.0.0 address
ADD separate HTTP & HTTPS policies for the VPN clients From: SSLVPN-Users, IKEv2-Users
The 1st policy which matches a packet will be used & no other policies will be checked.
So, add a deny rule for the user when connecting from the 10.6.0 address and an allow for the same user at the 10.0.0.0 address?
I'm not sure how to do that
NO.
ADD separate HTTP & HTTPS policies for the VPN clients From: SSLVPN-Users, IKEv2-Users above your existing HTTP & HTTPS policies
Sorry, i think you are going to have to spell it out for me.
The IKEV2 user is named in the https policy and automatically receives the relaxed policy rules when connected via VPN.
When the same user is connected directly on the network to the internet, they need to authenticate to get the same relaxed rule.
If i add separate HTTP & HTTPS rule for the IKEV2 user, what would i put in the 'to' rule to stop them being allowed through the firewall and onto the internet with elevated permissions
To: Any-external.
You are totally missing the point.
As I said above "The 1st policy which matches a packet will be used & no other policies will be checked."
So for an IKEv2 user using HTTP/HTTPS, the 1st policy which is hit is the the one From: IKEv2-users and that will allow what it allows.
NO OTHER POLICY WILL BE CHECKED, so the relaxed policy will not apply as it is further down the policy list.
Ok, I think i see what you mean.
I will have another look tomorrow.
Thanks again
Sorry, I havent been back to look at this. I will try again on Monday
Hi Bruce
I don't seem to be getting anywhere with this. The problem is that the first policy that the Firewall sees with the user specified, is the 'relaxed' policy. The "IKEV2-User" policy has been disabled in favour of a more restrictive group policy
I think that the only way around this for us is to stop using Firebox-db as an authentication server for external connections and use solely the Authpoint.
Thanks anyway
What exactly is on the new policy that does not match one of these VPN users?
That is the point. The user authenticating to the Firebox on the VPN automatically receives the relaxed policy, as the policy names them as user@firebox-db. When logging in as user@radius-db, the policy obviously isnt applied.
I dont want the user to have the access from the VPN, the priviledge is only given from the PC that they RDP into, which sits on the network.
When a VPN user authenticates to the firewall, the user should also have VPN group name associated with them.
So if joe@Firefox-DB authenticates with SSLVPN, then SSLVPN-Users should also be associated with VPN connected Joe.
So a policy From: SSLVPN-Users should match the appropriate packets from this VPN session.
I believe that this also work this way for IKEv2-Users group name.
As this does not seem to be working for you, try adding the VPN virtual subnets to these new restricted policies in the From: field.
There was no problem before the user was given remote VPN access. They would simply be in the office; connect to the authentication server on :4100 and then through this they are given a less restrictive application content policy.
this policy is now given to them freely as soon as they connect via the VPN
Yes, I understand that.
Have you added new HTTP & HTTPS policies above the less restricted policies, From: SSLVPN-Users, IKEv2-Users and the virtual VPN subnets?
If not PLEASE try this.
Thanks Ill give that a go. Brain is a bit frazzled now, so will leave it until tomorrow
Hi Bruce
moving the Http & Https polices above the less restricted policies, resulted in the internal authenticated user no longer receiving the necessary permissions.
Hi James
Adding the custom rule to allow the access only from the internal addresses did the trick
thank you both
Tess