VPN client and external personal firewall

For a VPN solution with a separately installed firewall, the ports for http/https data traffic to the personal firewall must be activated during hotspot registration. This can take place in three different ways:

1. The firewall rules for http/https are firmly preconfigured in order to guarantee the functionality with the desired hotspots.
2. The configuration allows that the ports are opened for http/https as needed for a certain time window (e.g. two minutes).
3. The user has administration rights and independently changes the firewall rules.


In all three cases there exists the risk that the user may surf outside of the secure VPN tunnel on the Internet and encounter destructive software such as viruses, worms or Trojans. Temporarily opening the firewall creates the danger of deliberate misuse by the user on the basis of multiple actuations of the time window. If the personal firewall fundamentally permits no communication outside of the configuration, then the user has to activate the corresponding firewall rules for the duration of registration on the hotspot. This requirements-based opening of the personal firewall involves the greatest risk of mis-configurations. The user must have a firm grasp of the exact changes being made and the exact environment in which they are made. Employee security awareness and technical know-how determine the security level quality.

A large security risk also exists when user data (user ID/password) is spied out externally on the hotspot during the registration process. With the aid of his notebook a hacker can simulate both the hotspot and the WLAN SSIDs. If a user then registers on a hotspot, he does not land at the access point of the provider, but rather on the notebook of the hacker. By means of the previously mirrored access point web pages, the user still assumes that he is authenticated on the hotspot, when in reality he is on the notebook of the hacker and his personal registration data is now exposed.

Providers always attempt to protect the hotspot registration pages through SSL processing (https), but that does not always succeed. For example, a user who arrives at a manipulated hotspot obtains the following report from the browser: A problem exists with the security certificate on the web site. In the background of this report, the attacker has only recreated the hotspot registration page and does not use the original certificate. For the lay person, this may not be recognizable at first glance, and it is incumbent to him to decide whether or not he should trust the certificate. In order not to place a user in the position of making this decision, the hotspot registration should flow transparently before construction of the VPN. A solution that has proven itself in practice is the so-called registration script that takes over the transmission of registration and the inspection of the certificate at the hotspot.