Departmental VPN Administrator Guide
Departmental VPN service for departmental IT administrators
Terminating Users On a LAN:
There are two options to terminate or "land" the remote users onto the network. The users can be connected to the network in front of OR behind the departmental firewall.
Landing the remote users behind the firewall will allow full unrestricted access from the remote user to all workstations and servers on the network as seen in the graphic Option1:
Landing the remote users in front of the firewall allows the firewall administrator to create firewall rules to control access to resources behind the firewall as seen in the graphic Option2:
IP Addresses Needed for Service:
In order to implement the Departmental VPN service, four IP addresses from the LAN need to be given to the VPN devices. Below is a diagram of the typical IP address assignment to the network Devices:
The use of four IP addresses from the department LAN allows for using the same VPN configuration to multiple remote user groups. The standard Departmental VPN configuration creates three user pools.
The first remote user pool is assigned from the first 127 addresses of the 10.12.x.x/24 space and is assigned directly by the VPN device. These users are converted to the 1st IP address that this document will refer to as PAT1. Firewall rules can be assigned to allow/deny access from the PAT1 address. It is expected that this address pool will be used to provide remote access to the bulk of departmental remote users.
IP addresses from the second IP address pool are assigned by the departmental LDAP/AD server statically to each individual user. These 10.12.x.x addresses in the second pool are converted by the VPN device to the second PAT address (referred to as PAT2). It is expected that the department will use this pool to give remote users full network access via generous firewall rules for users such as IT support staff.
IP addresses from the third IP address pool are assigned by the departmental LDAP/AD server statically to each individual user. These 10.12.x.x addresses in the third pool are converted by the VPN device to the third PAT address (referred to as PAT3). It is expected that the department will use this pool to give very restricted firewall access for outside users such as vendor support.
If a department has enough contiguous IP addresses for their maximum number of expected concurrent remote users, the address space can be given to the VPN device for assignment to end users and no Port Address Translations (PAT) takes place for those users. The 10.12.x.x/24 will still be configured and can be used for static remote client assignment via LDAP/AD servers. The VPN service still requires four IP address be given to the service for VPN device connectivity and support of the PAT2 and PAT3 translations.
Port Address Translation:
Port Address Translation (PAT) is used to conserve the use of publicly routable IP address space. Many computers are assigned private RFC 1918 address space and are translated by a network device to a single publicly routable IP address. The important functional limitation to understand in context to the Departmental VPN service is that when using PAT, a network connection cannot be initiated to the computer being PATed. This means that if the remote access VPN client is being assigned IP address space of 10.12.x.x and is being translated via PAT, then outside users cannot initiate a connection to any services running on that client machine (such as www server, Remote Desktop Protocol, FTP server). There are many applications that the client can run to get around this limitation such as WebEx, Gotomypc.com, eDonkey, but those client applications are the ones that initiate the communication.
If departmental IT staff have a need to initiate a connection to the remote user's PC, then using the option of assigning valid IP address space to all remote users may be the best choice, or working with the DoIT network staff to setup one-to-one NAT for small numbers of machines (less than 10) may be a better choice.
Split Tunneling is the process of allowing a remote VPN user to access a public network, most commonly the Internet, at the same time that the user is allowed to access resources on the VPN. This method of network access enables the user to access University computer services, at the same time as accessing the public network without going though the VPN tunnel.
An advantage of using split tunneling is that it alleviates bottlenecks and conserves bandwidth as Internet traffic does not have to pass through the VPN device. A disadvantage of this method is that it essentially renders the client endpoint vulnerable to attack as it is accessible through the public, non-secure network (if not running a local host based firewall).The Departmental VPN service allows three options for split tunneling of each departmental VPN configuration. The first option is to tunnel all traffic of remote users to use the VPN tunnel. This will force all traffic such as google.com, facebook.com, etc to use the tunnel. All traffic to the external websites such as google.com will see the PAT address as the source address of the traffic. This could cause issues if the remote user needs to access his/her local company networks because ALL traffic is sent to the University's VPN device.
The second option for split tunneling is to only have traffic going to campus IP address space use the tunnel. This will allow non-campus traffic to use the remote user's normal Internet connection/path for destinations other than the campus network. This option is the most used as it avoids issues with accessing local resources.
The third option for split tunneling is to have only a very specific and limited list of campus network destinations use the VPN tunnel.
Local LAN Access. The VPN Anyconnect client does not tunnel any traffic to destinations that the remote access VPN client is directly attached. For example, a user is at home and starts the Anyconnect client. The user is still able to access his local network printer and local file-server IF they are on the same exact subnet as the client is directly attached.
Static IP Address Assignment via Active Directory:LDAP servers such as Microsoft Active Directory (AD) can be used to assign static IP addresses to specific end users, thus having the VPN device PAT them to a known IP address. Also, additional LDAP fields can be returned by the LDAP server such as Network Access Permissions. This section shows how to configure Microsoft AD to assign static IP addresses to end users (thus overriding the VPN device dynamic pool IP address assignment).
In Microsoft Active Directory Users and Computers tool, open the Dial-in tab. (NOTE: Microsoft remote access assumes that any network mask is automatically derived from the class of the static IP assignment. This is NOT a correct assumption and therefore a network mask of 255.255.255.0 MUST be put into the Verify Caller-ID field as shown or the client will get the wrong subnet mask). Place a check in the Verify Caller-ID and type in 255.255.255.0 in this field. Click on the Assign Static IP address box, click on the Static IP addresses box, click the Assign a static IPv4 address box, and type in an IP address which you want to assign the user. This address MUST NOT be from the first 128 addresses of the 10.12.x.x which is given to you by DoIT. The address MUST be either in the .128-191 or the .192-254 range and chosen so that it is PATed to the PAT2 or PAT3 address of your choice.
Network Access Permission
The VPN device can be configured to honor the Network Access Permission section radio buttons of Allow access/Deny access. The default configuration for the VPN device will ignore these settings.
When the VPN device is configured to honor Network Access Permission radio buttons, every user will need to have this set to either Allow or Deny (The Control access through NPS Network Policy button has the same effect as the Allow remote access button selected).
Location/Naming of Departmental VPN Devices:
There are three pairs of VPN devices that provide the Departmental VPN service. One pair of VPN devices is located in each of the three supernode router locations on campus: Computer Sciences Building (CSSC), Animal Sciences Building, and 432 North Murray.
The DNS names for the VPN devices follow the naming convention of Dept-ra-<supernode name>.vpn.wisc.edu. Therefore the names of the VPN devices are: dept-ra-cssc.vpn.wisc.edu, dept-ra-animal.vpn.wisc.edu and Dept-ra-432nm.vpn.wisc.edu.
Dept is an abbreviation of departmental, RA is an abbreviation of Remote Access, and the last is the abbreviated supernode name.
All Information Needed to Setup the Departmental VPN Service:
Name of the Departmental VPN. This is what is shown to the user on the Anyconnect client and the VPN web page listing. The name should be less than 27 characters (the limit of the display in the Anyconnect client).
LDAP Search Path to search your users for authentication (this may be different that the path of the VPN username path).
For RADIUS, a username and password.
DNS domain name that the clients machine will append to names that are not fully qualified.
Temporary User Username/password so that we can test the functionality of the service during initial configration. This account can be removed as soon as the service has been tested and agreed upon as fully operational.
Note: If the authentication server(s) are on the same subnet as the IPs given for the 4 PAT IP addresses, the ASA will usually use the the first 2 IPs as source IPs when talking to the authentication servers. Depending on where you chose to terminate the users, you may have to allow these IPs through your firewall for authentication. Please confirm with the Network Services Engineer at the time of configuration to determine which IPs were used as interface IPs.
Remote end users may enter the above dept-ra-<supernode router name> DNS names into the Anyconnect client directly or use a web page that list all the possible departments that have use the Departmental VPN service.
The Departmental VPN web page http://vpn.wisc.edu contains a complete list of all the Departmental VPNs configured. The user may click on the appropriate link and use the SSL web based login portal. The portal then presents the user with the option to start/download the Anyconnect client via Java.