Has anyone manage to find a easy way to configure access so that user that are in hotel can actually connect to the sign in page ( that is on the public internet ) and once it's done, only have access to establish vpn connection to the office ?
I will go like this :
allow all ( to establish connection in whateve hotel they are ) ---> CAG that know it's on the internet ( somehow, like a ping to google.com ) ---> in that CAG, rules that permit only http/https connection to public ip of compagny ( to VPN SSL ).
The problem i see is in defining the CAG to see if it`s on the internet or not. I dont know what ip/DNS/DHCP im gonna get at the hotel. Is it possible to define a criteria for CAG that is "active" like if you ping this addresse then youre in ?
Hope im clear, and sorry for the bad english
In the upcoming release, HIPS 8.0, which is due to be released later this quarter, we will have a new feature called "Timed Groups". This feature will let you open the firewall and allow all traffic for a limited amount of time. The user must establish VPN connectivity within this time limit for the regular firewall policy to come into effect. This feature is configurable so that you can decide what type of traffic to allow (all traffic or outbound only) and for how long (5 mins, 10 mins, etc.).
But will it be better to have a CAG setting that could be aware that you actually have a active and working internet connection and thus only permit to talk to VPN/or other server ? That way there will not be a gap between connection time and rule enforcement.
Like a ping on a public server, to know that you have a working internet connection, and permit to connect only to corporate vpn portal.
Also, do we have a feature list that is gonna be put in version 8 ?
You can implement any rule set within a timed group. The idea was to give some flexibility for a limited amount of time. Please contact your McAfee representative for more info on HIPS 8.0.
In HIPS 7 we solved the WAN access point problem with the following general firewall rules:
Allow HTTP, HTTPS to local subnet
Allow HTTP, HTTPS to 192.168.16.0.0/16
Allow HTTP, HTTPS to 172.16.0.0/12
Allow HTTP, HTTPS to 10.0.0.0/8
This worked in almost any environments. A small drawback is that the user could use a local proxy in those subnets to surf the internet directly.