Network Connect Question

[muttbarker_]

Howdy - I have a question in regards to using Network Connect to control access to Internet resources while connected to a corporate network. For some reason I almost never work with NC so I am just not that proficent at it.

End user connects to their internal network via Network Connect. Through
NC they have access to all their appropriate internal resources. However, while
connected via NC I would like to be able to limit access to other public
resources. This limit would be in the form of some public domains or public
subnets. So for example only let the user get to "*.microsoft.com" or
68.183.10.0/24 while the NC connect session is in place. I don't want to have them get to these resources through the SA box, but limit their "local" access to them through the PC Internet connection that they have in place.

Do you know if this is possible to do?

Thanks for any comments or suggestions on how to do this.

[stine_]

Multiple role mapping rules.

GalaxyRole contains the Galaxy portal

EmailRole contains the Email gateway.

In your role mapping rules, map each user to the corresponding role.

You need to create your role mapping rules in conjuntion to your AD administrators because they control who gets mapped to which AD group.

You could simply ask for a new group named G_GalaxyPortal and request that users who need access get added to this group.  You would then create a role mapping rule that maps group G_GalaxyPortal to role GalaxyRole, and so on.

If they refuse to create an AD group, you'll then have to manage it by username based role mapping rules.

[donoche_]

Thanks Theodore,

Will do as you suggested.Will update accordingly.

Regards,

Anthony

[donoche_]

Hello Guys

i need your input on this.

I am also managing the SSL for a client and they brought in similar thing as the previous situation i had but theirs here is the senario they demand below:

• That we can restrict a user access to some applications and services while others are given access.

ü  Mr Maxmathin should be able to access our Email Gateway (10.10.9.x ) and should not be able to access the Galaxy portal (192.168.2.x / http://gbb-dc-02), Whilst Mr Innocent should access the portal and not have access to the Email Gateway on the specified IP address above.

now the external interface is  10.10.9.x and internal is 192.168.2.x.

Kindly advise on what to do to resolve this request.

Thanks



[mkelly_uwyo_]

You can set a network connect access policy that limits the public resources the user can get to. This has to be done by IP range and not DNS entry.

However, if all you are trying to do is keep users from using your internet connection to get to the outside I would look into configuring split tunneling in the network connection profile.

[ruc_]

Yes this is possible; however not very clean i.e. because NC wonÕt accept dns names/suffix based ACL's and you will have to input each host/subnet individually and this can become hard to manage.

Example:
Requirements:
1. Allow all internal resources on 172.27.0.0/16 and 10.10.0.0/16 network through NC tunnel.
2. Allow access to public IP's a.b.c.d/32 through client direct ISP (outside the tunnel)
3. Deny access to all other resources.

Config:
1. At Role level disable split tunnel.
2. Under Resource Policies -> Network Connect -> Access: Enter all internal networks that you would want to tunnel through NC (make sure there is a deny *:* rule at the bottom)
3. Under Resource Policies -> Network Connect -> Split tunnel Networks -> Create an exclude rule for all internet hosts that you want to allow direct access to.

Hope it helps.

[kenlars_]

These responses raise a question that I thought I knew the answer to, but may not. My assumption was that the NC ACLs only operate on traffic which comes across the tunnel to the SA, and can not be used to control traffic outside the tunnel. Can someone confirm or deny that? I may just be extrrapolating from how Nortel Contivity worked...

If you want to allow users to access only a few subnets on the Internet when connected through NC, then you could use split tunneling to direct all other traffic into the secure network, where it should die. As of 6.4, you can use the "inverse split tunneling" feature to allow you to configure what is not to be tunneled to make this not too difficult to configure. Unfortunately, since this is all operating at layer 3, you only get to do this via IP address.

One caveat with "inverse split tunneling" - it would seem to me that configuring this should automatically allow access to the DNS servers on the native interface - that is, traffic to them should be allowed out the native interface. But this is not true unless you specifically configure them in the split tunneling configuration. Of course, since most of your users probably get them dynamically from their ISPs, this is not possible.

Ken

[muttbarker_]

Hey Ken, Ruc - appreciate very much your thoughtful replies and suggestions. I will do some testing and post my results.

I have somehow managed to avoid spending all that much time on NC except for basic "get it running" but that will change now

[ruc_]

>>My assumption was that the NC ACLs only operate on traffic which comes across the tunnel to the SA, and can not be used to control traffic outside the tunnel. Can someone confirm or deny that?

Ken, Your understanding is correct. The config I recommended above will ensure that all traffic (except what is added in the exclude rule) goes into the tunnel (as split tunnel is disabled) and then using ACL's we kill access to the internet traffic using a *:*/deny rule.

[stine_]

Kevin, there is no clean way to do what you're trying to do. Just because you can allow access to a block of MS ip addresses won't make windows update (for example) work. The reason for this is CDNs (akamai, etc.) I guess the most straight-forward solution would be the use of a proxy.pac file and NC acls where you could allow access to *.microsoft.com, *.mcafee.com, *.kaspersky.com, and *.company.private. With such a proxy.pac file installed, the users would have direct access to the three external networks irregardless of where they were hosted, and access to any internal resource (assuming all of your internal sites were configured to use FQDNs) via the NC tunnel.

It has been 10 years since I had to set up a proxy.pac file, so I can't help you with the config, but you should be able to allow access to limited internet resources plus your internal networks and block everything else.