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?

Best Answer

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

  • edited September 10

    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 [email protected] When logging in as [email protected], 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 [email protected] 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

Sign In to comment.