Non-SSL Remote Access VPN

Setting up a Non-SSL Remote Access (RA) VPN on Cisco IOS involves a series of steps to define the ISAKMP policy, user authentication method, IP address pools, transform sets, dynamic maps, crypto maps, and AAA configuration. Below is a breakdown of the essential steps to get a basic RA VPN up and running using pre-shared keys and local authentication.

1. Define the ISAKMP Policy

Begin by configuring the ISAKMP policy, which sets the parameters for Phase 1 negotiation. In this example, we use pre-shared key authentication, 3DES encryption, SHA hashing, and DH Group 2:

crypto isakmp policy 1
authentication pre-share
encryption 3des
hash sha
group 2
exit

 

2. Create the ISAKMP Client Group

Next, configure the ISAKMP client group, which includes the pre-shared key and IP address pool assignment:

crypto isakmp client configuration group name
key key
pool pool-name
exit

 

3. Define the IP Address Pool

Set up a local IP address pool that will be assigned to remote clients upon successful connection:

ip local pool pool-name start-ip end-ip

 

4. Configure the IPsec Transform Set

The transform set determines how IPsec will encrypt and authenticate traffic during Phase 2. In this example, we use 3DES for encryption and HMAC-SHA for integrity:

crypto ipsec transform-set name esp-3des esp-sha-hmac
mode tunnel

 

5. Set Up the Dynamic Crypto Map

Define a dynamic crypto map to handle connections from remote clients dynamically:

crypto dynamic-map dmap-name num
set transform-set name
reverse-route
exit

 

6. Configure the Static Crypto Map

Tie the dynamic map into a static crypto map and associate it with the ISAKMP policies:

crypto map name num ipsec-isakmp dynamic dmap-name
crypto map name client configuration address respond
crypto map name client authentication list default
crypto map name isakmp authorization list default

 

7. Apply the Crypto Map to an Interface

Assign the crypto map to the relevant interface (e.g., GigabitEthernet2):

interface g2
crypto map name

 

8. Configure AAA for User Authentication

Enable AAA and configure it to use the local database for login and network authorization:

aaa new-model
aaa authentication login default local
aaa authorization network default local

 

9. Create Local User Credentials

Finally, define a local user account for VPN login:

username username privilege 15 password password

This configuration provides a basic, functional non-SSL RA VPN setup on IOS routers using pre-shared keys and local AAA. It’s a solid starting point for labs or simple production deployments. For additional security, consider upgrading the encryption to AES and using certificate-based authentication.

 

SSL VPN with Cisco AnyConnect

When deploying a thick-client SSL VPN using Cisco AnyConnect 4.2 on IOS routers, you’ll need to configure the WebVPN gateway, context, and policy group, along with defining the client address pool and user authentication. Below is a step-by-step walkthrough of the configuration process.

1. Upload the AnyConnect Package

Before beginning any WebVPN configuration, copy the AnyConnect .pkg file to the router’s flash storage using your preferred method—FTP, TFTP, USB, or another file transfer protocol.

 

2. Configure the WebVPN Gateway

Enable CEF and define the WebVPN gateway settings:

webvpn cef
webvpn gateway gateway-name
ip address x.x.x.x port port
http-redirect port port
inservice

This sets up the router to listen on the specified IP and port for incoming SSL VPN connections and enables HTTP redirection for user convenience.

 

3. Define the WebVPN Context

Create a WebVPN context for configuration isolation:

webvpn context context-name

 

4. Set Up the Policy Group

Configure the group policy that defines client behavior and IP allocation:

policy-group policy-name
functions svc-enabled
svc default-domain domain.com
svc keep-client-installed
svc address-pool pool-name netmask mask

This enables SSL VPN services, applies a default domain, ensures the AnyConnect client stays installed after connection, and assigns IPs from the specified pool.

 

5. Finalize Gateway Settings

Return to the gateway configuration and associate it with the policy group:

gateway gateway-name
inservice
default-group-policy policy-name

This ties the gateway to the policy group created earlier and brings it into service.

 

6. Define the IP Address Pool

Configure the local IP pool from which clients will be assigned addresses:

ip local pool pool-name start-ip end-ip

Ensure this subnet doesn’t overlap with any local network unless it’s intentionally routed.

 

7. Install the AnyConnect Package

Point the router to the location of the AnyConnect .pkg file on flash:

webvpn install svc flash:/location/anyconnect.pkg

This enables the router to distribute the AnyConnect client to end users if needed.

 

8. Configure Loopback Interface for Routing

Set up a loopback interface that belongs to the same subnet as the client IP pool:

interface loopback0
ip address x.x.x.x mask

This is important for routing return traffic to VPN clients correctly.

 

9. Create a Local User Account

Finally, define at least one local user credential for client authentication:

username username password password

This configuration creates a functional SSL VPN solution on a Cisco IOS router using the AnyConnect client. For enhanced security, consider integrating with RADIUS or TACACS+ for user authentication, using certificates, and applying access control via ACLs or firewall zones.

 

SSL VPN with Single Gateway with Multiple Contexts

For organizations needing secure, browser-based remote access for different user groups or domains, Cisco IOS WebVPN supports multiple contexts under a single gateway. This allows you to offer differentiated SSL VPN services to various user types, each with its own web portal configuration and resource links. Here’s how to configure a single-gateway, multi-context SSL VPN deployment on Cisco ISR platforms.

Step 1: Enable WebVPN and Configure the Gateway

Start by enabling WebVPN services and configuring a gateway on the ISR. This includes assigning an IP address and listening ports, along with enabling HTTP redirection for client convenience.

webvpn cef
webvpn gateway gateway-name
ip address x.x.x.x port port-number
http-redirect port port-number
inservice

 

Step 2: Create the First WebVPN Context

Now, define the first WebVPN context. This context includes a list of bookmarks (URLs), a heading for the web portal, and a reference to a named URL list. These bookmarks serve as clickable links that users will see on their SSL VPN landing page.

webvpn context context-name
url-list url-list-name
heading heading
url-text text1 url-value http://x.x.x.x
url-text text2 url-value http://x.x.x.x
url-text text3 url-value http://x.x.x.x

 

Step 3: Define the First Policy Group

With the context in place, create a policy group that governs what the users can do in this context. Enable file-related functionality and hide the URL bar to streamline the user interface.

policy group pname
url-list url-list-name
function file-access
function file-browse
function file-entry
hide url-bar

 

Step 4: Bind the Context to the Gateway

Next, associate the context and its policy group to the WebVPN gateway and activate the configuration. The domain name here acts as a trigger for selecting the appropriate context when users connect.

default-group-policy pname
gateway gateway-name domain domain
inservice

 

Step 5: Create a Second WebVPN Context

To serve a second group of users or another domain, repeat the context creation steps with different values. This second context will use the same structure but may include unique bookmarks or branding.

webvpn context context-name2
url-list url-list-name
heading heading
url-text text1 url-value http://x.x.x.x
url-text text2 url-value http://x.x.x.x
url-text text3 url-value http://x.x.x.x

 

Step 6: Define a Second Policy Group

Just as with the first context, create a second policy group for the new context:

policy group pname2
url-list url-list-name
function file-access
function file-browse
function file-entry
hide url-bar

 

Step 7: Activate the Second Context

Finally, go back to the gateway and bind the second domain and policy group to complete the multi-context configuration:

gateway gateway-name domain domain2
inservice
default-group-policy pname2

This setup enables multiple isolated user experiences over a single SSL VPN gateway, useful for segmented access, multi-tenant environments, or differentiated branding and policy enforcement. Each context can have its own domain, bookmark list, and set of allowed features, all while sharing the same WebVPN infrastructure.

 

SSL VPN with Multiple Gateways and Multiple Contexts

When managing distinct user groups, departments, or tenants, deploying multiple SSL VPN gateways with separate web contexts provides a powerful way to isolate and control user experiences. On Cisco IOS routers, this multi-gateway, multi-context approach ensures high flexibility, granular access control, and brandable portals per domain or user base. Here’s how to configure it step-by-step.

Step 1: Configure Multiple WebVPN Gateways

Begin by enabling CEF and creating separate WebVPN gateways. Each gateway can have its own IP address and ports to listen for SSL VPN requests:

webvpn cef
webvpn gateway gateway-name1
ip address x.x.x.x port port
http-redirect port port
inservice
exit

webvpn cef
webvpn gateway gateway-name2
ip address x.x.x.x port port
http-redirect port port
inservice

These gateways act as entry points for different user segments or customer domains.

 

Step 2: Configure the WebVPN Contexts

Define distinct contexts for each user group or organization. Each context presents a custom web interface with its own list of bookmarks and branding:

webvpn context context-name1
url-list url-list-name
heading heading
url-text text1 url-value http://x.x.x.x
url-text text2 url-value http://x.x.x.x
url-text text3 url-value http://x.x.x.x
exit

webvpn context context-name2
url-list url-list-name
heading heading
url-text text1 url-value http://x.x.x.x
url-text text2 url-value http://x.x.x.x
url-text text3 url-value http://x.x.x.x

Each context is visually and functionally isolated, allowing customization of user experience.

 

Step 3: Define the Policy Groups

Policy groups dictate what features are available to users within a given context. Below is the configuration for two distinct groups:

policy group pname
url-list url-list-name
function file-access
function file-browse
function file-entry
hide url-bar
exit

policy group pname2
url-list url-list-name2
function file-access
function file-browse

You can enable or disable functions like file access or directory browsing to fit user needs.

 

Step 4: Assign Group Policies to the Gateways

Finally, bind the policy groups to each gateway and associate them with a domain. This step activates each VPN entry point and its associated context:

default-group-policy pname
gateway gateway-name domain domain
inservice

default-group-policy pname2
gateway gateway-name domain <omain2
inservice

This configuration ensures that when users connect via a specific domain, they are routed to the appropriate context and granted access per the defined policy group.

This multi-gateway, multi-context SSL VPN setup is ideal for MSPs, large enterprises with department-specific access needs, or multi-tenant service environments. It provides strong separation of concerns and user interface control—all while sharing the same hardware infrastructure.

 

Advanced SSL VPN with Split Tunneling

Split tunneling in an SSL VPN environment allows remote clients to access specific subnets through the VPN while sending general internet traffic directly through their local gateway. This provides bandwidth optimization and access control. Here’s how to configure advanced split tunneling with WebVPN on Cisco IOS, using multiple contexts and domain-specific settings.

Step 1: Configure the WebVPN Gateway

Start by enabling WebVPN and defining the gateway. Assign the appropriate IP and ports:

webvpn cef
webvpn gateway gateway-name
ip address x.x.x.x port <port
http-redirect port port
inservice

 

Step 2: Set Up the Initial WebVPN Context

Create a context that will be associated with a domain or user group:

webvpn context context
url-list list-name
heading heading
url-text text url-value http://x.x.x.x

 

Step 3: Define the Policy Group

Configure the policy group for this context. This defines user permissions and SSL VPN client behavior:

policy group pname
url-list list-name
functions file-access
functions file-browse
functions file-entry
hide-url-bar
functions svc-enabled
svc keep-client-installed
svc default-domain domain-name
svc address-pool pool-name netmask mask

 

Step 4: Bind the Context to the Gateway

Return to the gateway configuration and bind the policy to the domain:

gateway gateway-name domain domain
inservice
default-group-policy name

 

Step 5: Create an Additional WebVPN Context

You can repeat the process for a second context and domain:

webvpn context context
url-list list-name2
heading heading
url-text text url-value http://x.x.x.x

 

Step 6: Define a Second Policy Group

Create another policy group for the second context. Be sure to associate the right URL list and client pool:

policy group pname
url-list list-name2
functions file-access
functions file-browse
functions file-entry
hide-url-bar
functions svc-enabled
svc keep-client-installed
svc default-domain domain-name2
svc address-pool pool-name2 netmask mask

 

Step 7: Bind the Second Context to the Gateway

Map the second context and policy group to its associated domain:

gateway gateway-name domain domain2
inservice
default-group-policy name

 

Step 8: Configure Local IP Pools

Define the address pools from which clients will receive IPs:

ip local pool pool-name x.x.x.x x.x.x.x
ip local pool pool-name2 x.x.x.x x.x.x.x

 

Step 9: Associate Loopback Interfaces

Each address pool must have a loopback interface for routing:

interface loopback0
ip address x.x.x.x mask

interface loopback1
ip address x.x.x.x mask

 

Step 10: Define the SVC Package

Point the WebVPN to the AnyConnect client package:

webvpn install svc flash:/x.pkg

 

Step 11: Define Split Tunneling Rules

Finally, configure the policy group and context with split tunnel directives to selectively route traffic:

policy group pname
svc split include x.x.x.x mask

webvpn context name2
svc split include x.x.x.x mask

This setup provides a highly customizable SSL VPN deployment using WebVPN with support for AnyConnect-style client behavior, domain-based isolation, and selective traffic redirection via split tunneling. It’s ideal for hybrid access scenarios where you want to protect only enterprise traffic while leaving internet-bound traffic local.

 

URL Filtering in Cisco SSL VPN (WebVPN)

Once your base SSL VPN (WebVPN) configuration is complete, you can enhance access control by applying URL filtering directly within your VPN contexts. This allows you to restrict what remote users can access through the WebVPN portal, enforcing compliance and reducing risk.

In this example, we’ll walk through how to configure advanced URL filtering using an Access Control List (ACL) within a WebVPN context.

Step 1: Define the URL ACL in the WebVPN Context

Start by entering the relevant WebVPN context and creating an ACL that defines which URLs are permitted. Here’s how you do it:

webvpn context context-name
acl acl-name
permit url http://x.x.x.x

This ACL ensures that only the specified URL (http://x.x.x.x) is accessible to users in this context. You can add multiple permit url entries if necessary, or use deny url for exclusions.

 

Step 2: Bind the ACL to a Policy Group

Once the ACL is created, bind it to the correct policy group to enforce it on users assigned to that group:

policy group pname
acl acl-name

Now, any user associated with this policy group will be restricted to only the URLs permitted by the ACL.

URL filtering through WebVPN ACLs gives administrators precise control over remote user access within SSL VPN sessions. It’s a lightweight but effective method of limiting exposure and ensuring users are only accessing approved resources.

 

Using Group-Lock in Cisco SSL VPN to Restrict User Context Access

In Cisco WebVPN environments, a single user account can normally access multiple VPN contexts unless specifically restricted. This can pose challenges in multi-tenant or department-isolated environments where strict access control is required. The Group-Lock feature allows administrators to tightly bind users to specific SSL VPN contexts, preventing them from accessing other portals, even if they know the credentials.

Here’s how to implement Group-Lock on IOS-based SSL VPN deployments.

Step 1: Pre-requisites

This configuration assumes your base SSL VPN setup (gateway, context, policy group, etc.) is already in place. We’re simply adding group-locking functionality on top of it to restrict user movement between contexts.

 

Step 2: Configure AAA Domains per Context

Enter each WebVPN context and define a unique authentication domain to associate with it. This will act as the delimiter for group-locking.

webvpn context context-name1
aaa authentication domain @domain

webvpn context context-name2
aaa authentication domain @domain2

Each context now expects login usernames that are scoped to its domain.

 

Step 3: Define User Accounts with Domain Binding

Now, create user accounts in the local authentication database, each associated with its appropriate domain. These usernames are domain-qualified (e.g., user@domain) and will only be valid for the corresponding WebVPN context:

username username1@domain password password
username username1@domain2 password password

As a result, username1@domain can only log in through context-name1, while username1@domain2 is restricted to context-name2. This enforces strict separation without needing an external AAA server.

 

Why Use Group-Lock?

Group-lock is essential in multi-context SSL VPN environments where each context may represent a different business unit, customer, or environment. Without group-lock, a user could accidentally (or maliciously) connect to contexts they weren’t intended for. This feature enforces isolation and minimizes lateral access risk.

 

Enabling Time-Based URL Access in Cisco SSL VPN (WebVPN)

In some environments, it may be necessary to restrict WebVPN access to specific URLs during defined time windows—for example, allowing access to a partner portal only during business hours. Cisco IOS WebVPN supports this through Time-Range ACLs, which let you define when specific URLs can be accessed via the SSL VPN portal.

Here’s how to configure time-based URL filtering in WebVPN.

Step 1: Prerequisites

This lab assumes your SSL VPN setup is already in place. Before configuring time-based filtering, ensure the router has a valid time set, either manually or via NTP. Accurate system time is critical for time-range enforcement.

 

Step 2: Define a Time Range in the WebVPN Context

Enter the WebVPN context and define the allowed time window using the time-range command. For example:

webvpn context context-name
time-range time-name
periodic daily hh:mm to hh:mm

This configuration specifies a daily recurring time period when access is allowed.

 

Step 3: Create an ACL That Uses the Time Range

Define an ACL that uses the previously configured time range to permit access to a specific URL:

acl acl-name
permit url http://x.x.x.x time-range time-name

This means that the specified URL is only accessible during the defined hours.

 

Step 4: Apply the ACL to a Policy Group

Finally, associate the ACL with a policy group to enforce it on users tied to that group:

policy group pname
acl acl-name

Once configured, users under this policy will only be able to access the specified URL during the defined time range.

This time-based access control feature is ideal for scenarios such as:

  • Allowing access to time-sensitive resources (e.g., shift-based portals).
  • Restricting after-hours usage.
  • Temporarily enabling access for limited-time campaigns or vendor support windows.

 

SSL VPN Through a Firewall: IOS Router + ASA ACL Configuration

Deploying an SSL VPN solution behind a firewall involves careful coordination between the router acting as the WebVPN gateway and the firewall (such as a Cisco ASA) that controls perimeter access. This lab walks through configuring WebVPN on the router and the necessary access control rules on the ASA firewall to ensure seamless operation.

Step 1: Configure the WebVPN Router

Begin by setting up the router as a WebVPN gateway. This includes enabling CEF, assigning an IP address, and activating HTTP redirection for client convenience.

webvpn cef
webvpn gateway gateway-name
ip address x.x.x.x port port
http-redirect port 80
inservice
exit

 

Step 2: Create the WebVPN Context

Next, configure the WebVPN context. This defines the content and bookmarks users will see on their portal page.

webvpn context context-name
url-list listname
heading name0
url-text name1 url-value http://x.x.x.x
url-text name2 url-value http://x.x.x.x

 

Step 3: Define the Policy Group

Now, set up a policy group to control user behavior and apply features such as file access, client persistence, domain binding, and split tunneling:

policy group policy-name
url-list url-list-name
functions file-access
functions file-browse
functions file-entry
hide-url-bar
banner banner
functions svc-enabled
svc keep-client-installed
svc default-domain domain
svc address-pool pool-name netmask x.x.x.x
svc split include x.x.x.x mask
exit

 

Step 4: Activate the Gateway

Link the gateway to its context and policy group:

gateway gateway-name domain domain
inservice
default-group-policy policy-name

 

Step 5: Configure Local Authentication and IP Pool

Set up local user credentials and assign an IP address pool for the clients:

username username password password
ip local pool pool-name x.x.x.x x.x.x.x

 

Step 6: Install the AnyConnect Package

Point the router to the location of the AnyConnect or SVC package to support client installs:

webvpn install svc flash:/package.pkg

 

Step 7: Configure the ASA Firewall

On the ASA, create ACL entries that permit inbound SSL and HTTP traffic to the WebVPN gateway. These entries ensure that traffic on TCP ports 443 and 80 is allowed through the firewall to reach the router.

access-list name permit tcp any host x.x.x.x eq 443
access-list name permit tcp any host x.x.x.x eq 80
access-group name in interface outside

This configuration allows both SSL VPN negotiation (port 443) and HTTP redirection (port 80) through the firewall, ensuring users can reach the portal and authenticate successfully.

Combining Cisco IOS WebVPN with ASA firewall policies enables secure, firewall-aware remote access without sacrificing control or visibility. Be sure to test inbound connections and verify split-tunnel routes if used. Also, consider enabling logging on both the ASA and router to monitor and troubleshoot connection attempts.

 

Troubleshooting SSL VPN on Cisco IOS

Deploying SSL VPN using WebVPN on Cisco IOS is powerful, but troubleshooting issues can become complex without clear diagnostics. This lab highlights common problems and solutions for SSL VPNs that fail to load portals, establish tunnels, or resolve DNS queries.

1. Verify WebVPN Gateway Status

If the SSL VPN portal doesn’t appear in the browser, begin by verifying whether the WebVPN gateway is operational:

show webvpn gateway

If the output shows Admin down and Operation down, then the gateway isn’t active. To bring it up:

webvpn gateway g1
inservice

Make sure the gateway is both administratively and operationally up for the SSL page to load.

 

2. Ensure SSL Package is Installed

If the SSL portal loads but clicking “Connect” on the tunnel doesn’t initiate anything, check whether the SSL VPN package is installed:

webvpn install svc flash:/webvpn/svc.pkg

Without this package, tunnel connections using the AnyConnect client won’t function.

 

3. Fix DNS Errors in AnyConnect

If the AnyConnect client displays an error like “Network error. Unable to lookup host names”, it’s likely a DNS resolution or split tunneling issue. First, inspect whether the address pool and split include statements are properly configured in the policy group:

policy group ppp
url-list "u_list"
functions file-access
functions file-browse
functions file-entry
functions svc-enabled
banner "MGMT_SERVERS"
hide-url-bar
svc address-pool "mgmt-pool" netmask 255.255.255.0
svc default-domain "mgmt.com"
svc keep-client-installed
svc split include 192.168.20.0 255.255.255.0

Check that the referenced pool exists:

show ip local pool

If the pool (e.g., mgmt-pool) is missing, create it:

ip local pool mgmt-pool 192.168.100.100 192.168.100.254

 

4. Troubleshoot Split Tunneling Configuration

If split tunneling is still not working, verify that it is applied properly within the context and policy group:

webvpn context admin
policy group PPP
svc split include 192.168.0.0 255.255.0.0

webvpn context mgmt
policy group PPP
svc split include 192.168.0.0 255.255.0.0

Be sure the svc split command appears under the appropriate policy and context entries.

 

5. Confirm Login and AAA Integration

If login to the SSL portal fails, check that the username and password are correctly defined. If AAA is being used, make sure your configuration accounts for it:

show running-config | section webvpn

Look for:

gateway g1
ip address 101.1.1.100 port 443
http-redirect port 80
gateway g1 domain admin
inservice

 

6. Check for Group Lock Enforcement

Lastly, determine whether a group lock restriction is blocking access based on domain affiliation. Look for an aaa authentication domain line:

aaa authentication domain @admin

And ensure the gateway matches:

gateway g1 domain admin

This configuration ties users to a specific domain. If their credentials don’t match the expected domain (e.g., user@admin), access will fail.

When troubleshooting SSL VPN issues on IOS:

  • Always verify gateway state, SSL package presence, and split tunnel config
  • Ensure IP pools are created and AAA settings aren’t overly restrictive
  • Use show commands liberally to validate current router state