Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Wilson_Wiley
Participant

SecuRemote IA/APCL/URLF Gateway Compatibility

Hi All,

I have a potentially huge problem on my hands. We use two different VPN clients, the SecuRemote remote access VPN for external agencies that connect to us, and the Endpoint Security remote access VPN for our internal users. In working towards doing internet access through our firewalls, we enabled the Identity Awareness, Application Control, and URL Filtering blades on our core firewalls on Sunday. We started off with Identity Awareness, on the gateway object we checked the blade and configured the options for Remote Access and Identity Collectors. We knew from trying to do this once before that we needed to create Access Roles and we could put our User Groups in the Access Roles, so we created the Access Roles, removed the “Legacy User Access” from the ACL rules and added the Access Roles in their place and pushed policy to the firewall. After we did that, we found that when an Endpoint Security VPN connected, there was a new Identity Awareness Log In event recorded and traffic was passed normally, hitting the Access Role rules, however, when a SecuRemote VPN connected, there was not an Identity Awareness Log In event, and all traffic from the SR VPN was passing the Access Role rules and going to the bottom drop all rule in the rulebase. We found that we could add the Legacy User Access groups back into the ACL rules alongside the Access Roles and traffic from the SR VPN client would hit the correct rules again.

However, when enabling Application Control and URL filtering on the gateway object, enabling App Control & URL filtering in the policy layer, and then pushing policy to the gateway, we got this message: "Layer [policy name]: Rule [#] has "Legacy User Access" in the Source Column which can be configured on layer with Firewall only."

So it appears we can’t use Legacy User Access on gateways with Application Control and URL filtering enabled in the policy. But if we remove the Legacy User Access from the policy and use Access Roles the SecuRemote traffic doesn’t hit the Access Roles. I looked at the Access Role objects, specifically the Remote Access Clients tab > Specific Client > New > Allowed Client > +. It lists the below VPN clients:

- ActiveSync
- Capsule VPN/Connect
- Capsule Workspace
- Check Point GO
- Endpoint Security VPN/Check Point Mobile for Windows
- L2TP
- Mobile Access Portal
- Mobile Access SSL Network Extender (SNX)
- VPN-1 SSL Network Extender (SNX)

So, it looks like SecuRemote is not one of the listed VPN clients that could be allowed for an Access Role, which is probably why the traffic from SecuRemote is not hitting the Access Role rules. Looking at that list of VPN clients, most of them I don’t think are options for Windows computers for a replacement for SecuRemote. I had never tried Check Point Mobile for Windows, but I’ve seen it before because it’s one of the three client options in the Remote Access VPN client installer. I loaded the Check Point Mobile client on a Windows computer and tried connecting it. It looks like it’s a cross between SecuRemote and Endpoint Security RA VPN, it’s a pretty basic client like SecuRemote, but it does a couple things that Endpoint Security RA VPN does that are deal-breakers for us: office mode IP addresses, and route all traffic to gateway. When I connected Check Point Mobile it was failing to connect because it failed to get an office mode IP. We only offer office mode IP addresses to our internal user ES RA VPN clients (SecuRemote can’t even do office mode IP’s), because we make the office mode IP network part of our client network. I added the user to the group that we offer office mode IP’s to and connected Check Point Mobile again on the computer and it connected that time. However, then I noticed it was sending all traffic over the VPN to the gateway. We have enforced on our gateway to send all traffic to the gateway when the VPN client is connected, however, SecuRemote doesn’t support doing that (and we don’t want SR to because it’s loaded on external agency’s computers), so only Endpoint Security was actually sending all traffic to the gateway. Consequently, because of those reasons Check Point Mobile isn’t going to be an option for replacing SecuRemote on external agency’s computers.

So, it looks to me like I’m in a pretty bad place, it appears I can’t use SecuRemote with IA/APCL/URLF on our gateway and Check Point Mobile isn’t an option for replacing it (I don’t think any of the other listed VPN clients would be either). At this point, I am thinking we need to start looking at configuring the SSL VPN on our reverse proxies for our external users and get them off of SecuRemote so that we can continue with the IA/APCL/URLF deployment on our firewalls, but that's going to take a lot of time, and we've got thousands of external agency computers with the SecuRemote VPN installed. I’m hoping someone has some solution to this that will be an easy fix or change, such as R81/81.10/81.20 supports SecuRemote as a VPN client for Access Roles or something like that, but that’s probably wishful thinking.

I would appreciate anyone's help or insight on this.

Thanks!

Wilson

0 Kudos
3 Replies
PhoneBoy
Admin
Admin

In a Remote Access VPN situation, the IP that is used for Identity Awareness is the Office Mode IP.
With SecuRemote, there is no IP address we can associate with a user, so no identity or access role is possible.
The Legacy User Access objects are only compatible with Firewall rules, as you noted.

Which leaves you with a few options:

  • Use Mobile Access Blade and SNX as the VPN client
  • Use Ordered Layers and put the Legacy User Access rules in the first (Firewall only) layer
  • Create some non-identity specific rules using the RemoteAccess community in the VPN column
0 Kudos
Wilson_Wiley
Participant

I'm really intrigued by the second option of using ordered layers and putting the Legacy User Access rules in the first firewall only layer. We never had APCL/URLF in pre-R80 versions, so I never got to see what a R80 migrated policy would look like with two ordered layers, one for firewall and one for APCL/URLF. Post R80 I've only used inline layers, which I love, I've only seen ordered layers lightly covered in some of the R80 documentation and videos. I'm going to have to play around with a test policy to see if I can get it working. Thanks!

0 Kudos
the_rock
Legend
Legend

I think options @PhoneBoy gave are 100% logical and 2nd option seems the best in your case, for sure. 

0 Kudos