In the just concluded Lab #9, we set up a clientless SSL VPN on RTR2. We tested this VPN by connecting a host behind RTR3 and opening a web browser to https://22.22.22.22/. We discovered that the SSL VPN portal was blank even though users could use the URL field to access internal resources. In this mini-lab, we will customize the SSL VPN portal with our own defined logo and login text. We will also provide URL links for users on the SSL VPN portal.

Our network diagram that reflects the remote-access user behind RTR3 is shown below:

The configuration tasks for Lab #9.5 are as follows:

  • * Edit the Clientless SSL VPN configuration such that connected users have links to access two web servers: http://1.1.1.1 and http://2.2.2.2.
  • * Customise the SSL VPN portal so that the Intense School logo is displayed rather than the default Cisco logo. The title displayed on the SSL VPN service should be “Intense School Example SSL VPN” and the login message should be “Welcome to Intense School Example SSL VPN Service”.
  • * Test your SSL VPN service. Ensure that SSL VPN users can access both web servers from the SSL VPN portal.

Configuration solutions

To begin our configuration, I will navigate to Configure > Security > VPN > SSL VPN > SSL VPN Manager. Under the Edit SSL VPN tab, I will click on the Edit button.

This brings up the Edit SSL VPN Context screen.

The setting that we are interested in is the URL Lists because it allows us to create clickable links on the VPN portal page.

I will use the Add button to add a URL list called ‘Internal_servers’ with a heading of “Internal Servers.” This list will include two links: http://1.1.1.1 and http://2.2.2.2 as shown below:

Note: The URL List Name cannot contain spaces but the Heading can.

We are now done with the firsttask and we can move on to the second one which deals with customization. I will select HTML Display Settings to add the Intense School logo and add the custom texts.

Note: To download the Intense School logo, go to the Intense School site and right-click on the logo on the left-hand side at the top of the page and select Save image as. Then use an image editing tool such as Paint to crop the logo so that only the round part remains.

After selecting the Customize option and adding the required texts and logo location, the screenshot below shows what I have:

When you click on OK to apply your settings, the dialog box below is displayed showing that the Intense School logo is being uploaded from the location on my PC to the router’s flash.

When the file has been uploaded to the router, you can check your flash to see it as shown below:

The configuration to be delivered to the router regarding the changes we made is as follows:

webvpn context WEBVPN
 login-message "Welcome to Intense School Example SSL VPN Service"
 title "Intense School Example SSL VPN"
 logo file IntenseSchoolLogo.gif
 url-list "Internal_servers"
 url-text "Web server 1" url-value "http://1.1.1.1"
 url-text "Web server 2" url-value "http://2.2.2.2"
 heading "Internal Servers"
 exit
 exit

Let’s now access our SSL VPN service again to see the changes made. I will open a web browser and navigate to https://22.22.22.22.

On this screen, we can see the immediate changes: Logo, Title and login message. Let’s now login to see if our URL links are available.

There are still no URL links available. Let me explain what happened: Even though we created a URL list, we did not enable it under the Web VPN policy we are using. This becomes evident when we look at the Web VPN context details under the Edit SSL VPN tab.

We will now fix this. I will click on the Edit button again and select Group Policies.

As you can see from above, there are no URL Lists configured for this policy. I will enable the URL lists by editing this policy.

I will select the Clientless tab, tick the box beside Select and click OK. The configuration to be sent to the router is as follows:

webvpn context WEBVPN
 policy group policy_1
 url-list Internal_servers
 exit
 exit

Now I will logout of the SSL VPN portal on my virtual machine and login again.

Note: Refresh won’t work.

I can now see my links. Cool! Not so fast: check that you can access those links. You will discover that Web server 1 is unavailable as shown in the screen below:

However, Web server 2 is available:

To troubleshoot, I will debug IP packets on RTR1 (because it is the one with the 1.1.1.1 IP address). Because of the volume of output that debugging produces, you have to be careful not to cause a DoS against yourself. I will use an access list to specify only the traffic I am interested in. The configuration to achieve this is as follows:

access-list 100 permit tcp any host 1.1.1.1 eq www
exit
debug ip packet detail 100

The relevant messages I receive on RTR1 is as shown below:

RTR1 received HTTP traffic from 192.168.12.2 (RTR2’s Fa0/0 interface) for 1.1.1.1. That connection was denied according to the “dropped by local inspect” message. There are two things to note here: RTR2 seems to be applying some sort of NAT (probably PAT) for the clientless SSL VPN user. Secondly, that connection is denied by the zone-based firewall configuration on RTR1.

To allow this connection, we will edit the outside-to-self zone policy on RTR1 by adding the following configuration:

ip access-list extended HTTP_LOOPBACK0
 permit tcp any host 1.1.1.1 eq www
class-map type inspect match-all CMAP_HTTP_LOOPBACK0
 match protocol tcp
 match access-group name HTTP_LOOPBACK0
policy-map type inspect ccp-permit
 class type inspect CMAP_HTTP_LOOPBACK0
 inspect

Even after this, your web server connection will still not be allowed because there is also an HTTP ACL that allows HTTP connections only from 10.0.0.0/24.

I will remove the HTTP access restriction using command: no ip http access-class 1. Let’s try accessing that web server again from our SSL VPN portal.

Now we see that it works.

Summary

This brings us to the end of this mini lab where we have customized our SSL VPN service. We were able to add a different logo, change the title and login texts and also add URL links to the portal. We also discovered that we need to edit our firewall and HTTP access policies on RTR1.

Being a good network administrator is not only about knowing how to configure stuff but also knowing how to solve challenges when the need arises. I hope you have found this article insightful and I look forward to the next article in the series.

Further reading