Departmental VPN Administrator Guide

Departmental VPN service for departmental IT administrators

Service Description: The Departmental VPN service allows remote users to be authenticated using departmental authentication services such as LDAP, and Radius, and be landed onto departmental networks directly.  The service supports SSL only based VPN clients provided by Cisco.  These clients are named Anyconnect.  IPSEC is not supported in this service.

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:




vpn-page-1

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:

departmental VPN outside termination

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:

addressing

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.

PAT option1


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.

pat option2


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:


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.



LDAP-AD-1



LDAP-AD 3
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).

Allow Deny button
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.



VPN device placement

All Information Needed to Setup the Departmental VPN Service:

Please create a helpdesk case to have DoIT Network Services setup the Departmental VPN service.  ALL of the following information is needed for the service to be configured (really ALL, we can't set it up with any of the information missing!):

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).

VLAN number to terminate/land the users onto.  Be careful and give the VLAN number of either the outside vlan or inside vlan of the firewall (they are different).

Four IP addresses to be used by the VPN device for connectivity to the network and PAT.  They should be four contiguous for IP addresses.

Type of your departmental authentication service (Microsoft AD, LDAP, or RADIUS).

IP Address(es) of your authentication servers.

Username and password to be used by the VPN device to authenticate the remote users (Note: for Windows the username and the LDAP name MUST be the same):

For LDAP, the Username should include the full LDAP path of the username. Example:  ASAVPNUSER,OU=System Accounts,OU=Accounts,OU=Operations,DC=deptx,DC=wisc,DC=edu. 

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.

Split Tunneling options.  Tunnel all traffic, campus traffic, or a very limited list of networks into the VPN tunnel. 

DNS servers the remote VPN clients should use.  By default the remote users will use the standard campus DNS servers, but you may choose to point your users at DNS servers that your department uses.

DNS domain name that the clients machine will append to names that are not fully qualified.

Idle Timeout.  The time no traffic from the remote VPN device is received before the client is logged off the VPN server.  This setting is important to understand when used in conjunction with static client IP address assignment.  It is suggested that this number be between 5-15 mins.

For example, let's say that a remote VPN user starts a departmental VPN connection on campus and that user is configured to be given a static IP address by an LDAP server.  That user puts his device into sleep mode and walks over to a coffee shop off campus.  When he/she opens his device it associates with the public hot spot and is given a new IP address.  The VPN client attempts to use the existing VPN connection.  To the VPN server it looks like the users VPN session is being hijacked by a user at the coffee shop. If the user reconnects to the VPN service, the departments server will give the client the same IP address as the existing abandoned session.  This doesn't work because the abandoned session is using the IP address the LDAP server handed out.

In the example, if the idle timeout is set to say 5 mins, when the user opens his device at the coffee shop, the session will have already been logged out (because it took at least 5 mins to walk to the new location) and the user is required to re-login to use the VPN service.

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.

Maximum VPN Session Time Length.  The maximum time a remote access VPN user is allowed to keep a session open.  The default is 24 hours.

Firewall rules required to allow the VPN device to authenticate users.  The department firewall administrator must install firewall rules to allow LDAP/LDAPS or RADIUS over tcp from the following IP addressing to their authentication servers:  144.92.42.108, 144.92.42.100, 144.92.249.20.

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.

Using the Service 

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.

The user then may start the Anyconnect client directly from his/her desktop after this first time install process.

The Anyconnect client has the four VPN device alias names programmed into it (east, central, west campus, and legacy vpn) to make future VPN connections a little easier to remember than an obscure DNS name.

The has the option of launching the VPN Anyconnect client though the  Departmental VPN web page of http://vpn.wisc.edu if they find that is easier to do.  Once the Anyconnect client is downloaded via the portal page it does not need to be re-download unless there is an Anyconnect client version upgrade available.

FAQ:

Question: Can the remote users of the same department connect to other machines that are using the VPN service (i.e. sideway communication).  

Answer: No.

Question:  Can I have multiple VPN tunnel configurations terminate on the same VLAN?

Answer: No.  The VPN device does not allow this at this time.

Question:  Do I need to use the Anyconnect client for the service or can I use the native IPSEC features on my device?

Answer: The only way a remote user can use this service is though the Anyconnect client.  Issues with IPSEC, preshared keys and uni-directional IPSEC sessions make the use of Anyconnect client the preferred and only way to use the service.  The Anyconnect client uses SSL technology to encrypt and secure the remote sessions.



Keywords:Deptvpn, Departmental VPN, VPN, remote access VPN Administrator Guide   Doc ID:25040
Owner:Greg P.Group:Network Services
Created:2012-07-06 09:29 CDTUpdated:2013-02-14 12:38 CDT
Sites:DoIT Help Desk, Network Services
Feedback:  2   1