Connecting the world…

client

Configure IOS SSL VPN on IOS router

Yesterday I blogged about configuring a VPN client on an IOS router and today I blogged about importing PKCS12 certificates for WebVPN purposes. This follow up blog is about configuring the WebVPN functionality together with the AnyConnect client and port forwarding on an IOS router. I use the same setup as with the VPN client and also configured split-tunneling for the AnyConnect connection.

webvpn The Cisco IOS SSL VPN feature supports multiple options, like:

  • Clientless: usage of a web portal;
  • Thin client: usage of a web portal with port forwarding feature;
  • Full client: usage of the Cisco AnyConnect client;

This example shows you how to configure all options listed above. The fist step involves configuring the authentication method with an AAA method.

aaa new-model
aaa authentication login sslvpn local
username rene privilege 15 secret 5 $1$FkgJ$u3uU0rstyeaBXswW0EIX55

The authentication method is called sslvpn and uses the local database on the router for authenticating users. Next you have to configure the basic IP and port information for connecting to the SSL VPN feature of the router. I use the public IP address of the router and configured the WebVPN on port TCP/4400. I use the SSL trustpoint from my previous blog post.

webvpn gateway gateway_1
ip address 83.137.194.62 port 4400
ssl trustpoint trustpoint_www
inservice

To use the full client feature, you have to upload an AnyConnect client to the routers flash. You can upload multiple AnyConnect clients for different operating systems. I just upload a client for Windows.

webvpn install svc flash:/webvpn/svc.pkg sequence 1

Next you have to configure a “webvpn context”. Within the webvpn context you define multiple VPN parameters. The webvpn context contains configuration parameters to access an URL through the web portal, define the port forwarding features or apply a policy group to the webvpn context. Below you see an example configuration of a webvpn context.

webvpn context home
title “Booches Portal”
ssl authenticate verify all
!
url-list “WebServers”
heading “WebServers”
url-text “Inside webserver” url-value “http://192.168.1.10”
!
login-message “Booches”
!
port-forward “Port Forwarding”
local-port 444 remote-server “192.168.1.150” remote-port 5001 description “NAS TCP/5001 (Management)”
local-port 443 remote-server “192.168.1.150” remote-port 443 description “NAS TCP/443 (Photo,File System)”
local-port 222 remote-server “192.168.1.200” remote-port 22 description “Ubuntu TCP/22 (Management)”
!
policy group policy1
url-list “WebServers”
port-forward “Port Forwarding”
functions file-access
functions file-browse
functions file-entry
functions svc-enabled
hide-url-bar
svc address-pool “sslvpn”
svc keep-client-installed
svc split include 192.168.1.0 255.255.255.0

You can configure multiple webvpn contexts with different authentication methods, url-list or port forwarding parameters. Next you see some screenshots from the WebVPN. To access the WebVPN feature the user has to browse to https://83.137.194.62:4400/home, because I configured gateway gateway_1 domain home (full config at the end). The web portal login page is displayed below.

webportal_login

After logging in you will get to the web portal menu, where you can choose between the multiple client options.

default_portal

The Bookmarks section list the URL list to access internal websites. The Tunnel Connection (SVC) option starts the Cisco AnyConnect client. If the AnyConnect client isn’t yet installed on the remote client, it will be pushed by the router. The Thin Client Application starts the port forwarding feature.

port_forwarding

All the relevant configuration from the example above can be found below.

aaa new-model
aaa authentication login sslvpn local
username rene privilege 15 secret 5 $1$FkgJ$u3uU0rstyeaBXswW0EIX55
!
ip local pool sslvpn 10.10.1.1 10.10.1.254
!
webvpn gateway gateway_1
ip address 83.137.194.62 port 4400
ssl trustpoint trustpoint_www
inservice
!
webvpn install svc flash:/webvpn/svc.pkg sequence 1
!
webvpn context home
title “Booches Portal”
ssl authenticate verify all
!
url-list “WebServers”
heading “WebServers”
url-text “Inside webserver” url-value “http://192.168.1.10”
!
login-message “Booches”
!
port-forward “Port Forwarding”
local-port 444 remote-server “192.168.1.150” remote-port 5001 description “NAS TCP/5001 (Management)”
local-port 443 remote-server “192.168.1.150” remote-port 443 description “NAS TCP/443 (Photo,File System)”
local-port 222 remote-server “192.168.1.200” remote-port 22 description “Ubuntu TCP/22 (Management)”
!
policy group policy1
url-list “WebServers”
port-forward “Port Forwarding”
functions file-access
functions file-browse
functions file-entry
functions svc-enabled
hide-url-bar
svc address-pool “sslvpn”
svc keep-client-installed
svc split include 192.168.1.0 255.255.255.0
default-group-policy policy1
aaa authentication list sslvpn
gateway gateway_1 domain home
max-users 2
inservice

I like for SMB solutions the IOS SSL VPN feature, because it is powerful and works over SSL, but it is also flexible and can almost publish every service.

Configure VPN client on IOS router

One way to remotely access a network is using the Cisco VPN client. Nowadays more and more implementations of SSL VPN are being done and Cisco stopped their development on their VPN client and pushes their Cisco AnyConnect client.

Still the Cisco VPN client is often used to remotely gain access to a network. The Cisco VPN client supports:

  • Windows XP, Vista (x86/32-bit only) and Windows 7 (x86/32-bit only);
  • Linux (Intel);
  • Mac OS X 10.4 & 10.5;
  • Solaris UltraSparc (32 and 64-bit);

The Cisco VPN client is available for download if you have a SMARTnet support contract and encryption entitlements. The client can be used in conjunction with VPN concentrators, PIX and ASA firewall and IOS routers. Below you can find a template configuration for enabling the Cisco VPN client on an IOS router (all used IP addresses and credentials are chosen randomly and don’t represent a real configuration). I used the setup from the picture below:

CiscoVPNClient

The configuration uses the local database to authenticate users and split-tunneling is configured to only encrypt traffic destined for the LAN network. With split-tunneling enabled you still can access all local resources and the internet.

aaa new-model
aaa authentication login userauthen local
aaa authorization network groupauthor local
!
username rene privilege 15 secret 5 $1$FkgJ$u3uU0rstyeaBXswW0EIX55
!
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
!
crypto isakmp client configuration group booches-vpn-client
key pr3sh@r3dk3y
dns 192.168.1.10 192.168.1.11
domain booches.local
pool vpnpool
acl 110
netmask 255.255.255.0
!
crypto ipsec transform-set vpn-ts-set esp-3des esp-sha-hmac
!
crypto dynamic-map dynamicmap 10
set transform-set vpn-ts-set
reverse-route
!
crypto map client-vpn-map client authentication list userauthen
crypto map client-vpn-map isakmp authorization list groupauthor
crypto map client-vpn-map client configuration address initiate
crypto map client-vpn-map client configuration address respond
crypto map client-vpn-map 10 ipsec-isakmp dynamic dynamicmap
!
interface FastEthernet0/0
ip address 83.137.194.62 255.255.255.240
ip nat outside
crypto map client-vpn-map
!
interface FastEthernet0/1
ip address 192.168.1.254 255.255.255.0
ip nat inside
!
ip local pool vpnpool 10.10.1.1 10.10.1.254
!
ip nat inside source list 100 interface FastEthernet0/0 overload
!
access-list 100 deny   ip 192.168.1.0 0.0.0.255 10.10.1.0 0.0.0.255
access-list 100 permit ip 192.168.1.0 0.0.0.255 any
access-list 110 permit ip 192.168.1.0 0.0.0.255 10.10.1.0 0.0.0.255

Microsoft CA certificate validity period

Using a Microsoft CA is very common in network to issue self-signed certificates. Last week I had to configure a Windows IIS server with client certificate authorization. Remote people (non Active Directory users) need a client certificate to browse to a specific website. The communication between the remote user and the website is secure by a default SSL web certificate.

The website is configured to require SSL and client certificate authentication. Within IIS I configured Client Certificate Mappings to authenticate the remote users. To create Client Certificate Mappings I had to generate client certificates. Client certificates can be generated by installing a Microsoft Certificate Authority. You can also use OpenSSL to generate client certificate, but this customers has a complete Microsoft Windows environment, so I decided to install a Microsoft CA.

You can install two kinds of CA’s:

  • Stand-alone CA
  • Enterprise CA

A standalone CA does not issue certificates independent of administrator intervention. The reasoning for this is based upon the fact that a standalone CA doesn’t tap into a local or domain user account. Instead, it relies upon human intervention as a ‘last check’ method prior to issuing a certificate. Standalone CA certificates are also not distributed automatically, but further require a delivery method, such as group policy (for local domain users), or via further human intervention. For Web and Internet access, this is the type of CA to use.

The enterprise CA adds a new level of flexibility and ability to the certificate picture, but also added complexity. The Enterprise CA is integrated with Active Directory, and only provides certificates to members within that Active Directory. This pretty much kills the idea of having both an extranet or secure Internet communications along with secure local domain communications. Enterprise Certificates can, however, be used in a manner that falls within the ‘not often, but still really nifty’ category. Enterprise Certificates can be used to bypass repeated and redundant domain authentication, and when properly configured, can be used to further enhance the standard Kerberos authentication methods. Enterprise Certificates are automatically issued for every user account when it is created. The certificate itself, since it is a file, can be stored on any storage location and can still be valid. In keeping along this train of thought, it is possible to place a certificate on a card or plug-in device that can be used to authenticate a user during the normal Kerberos authentication process. These specialized devices are called Smart Cards, and while Smart Card implementation is somewhat expensive, several large corporations have implemented this technology as an added safety factor. […] Source

I decided to install a Standalone CA server, so client certificates can be generated with credentials from the remote users. When using an Enterprise CA, the client certificate contains the credentials from the Windows users who generates the request. The Enterprise CA requires Windows Integrated Authentication to perform a request.

Everything is working perfectly, the only caveat was the validity period of the client certificates. By default, the lifetime of a certificate that is issued by a Stand-alone Certificate Authority CA is one year. The validity period that is defined in the registry affects all certificates that are issued by Stand-alone and Enterprise CAs. For Enterprise CAs, the default registry setting is two years. I used the following procedure to change the default validity period from one year to two years.

  1. Click Start, and then click Run
  2. In the Open box, type regedit, and then click OK
  3. Locate, and then click the following registry key:
    • HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\CertSvc\Configuration\<CAName>
  4. In the right pane, double-click ValidityPeriod
  5. In the Value data box, type one of the following, and click OK
    • Days
    • Weeks
    • Months
    • Years
  6. In the right pane, double-click ValidityPeriodUnits
  7. In the Value data box, type the numeric value that you want, and then click OK. In my situation I used the value 2
  8. Stop and then restart the Certificate Services service. To do so
    • Click Start, and then click Run
    • In the Open box, type cmd, and then click OK
    • At the command prompt, type the following lines.
    • net stop certsvc
    • net start certsvc
  9. Type exit to quit Command prompt.

I found this procedure in the Microsoft Knowledge Base and used it on Microsoft Windows 2003 and Microsoft Windows 2008.

Juniper SA & Terminal Server with Novell Client SSO

Normally configuring SSO on a Terminal Server in conjunction with a Juniper SA isn’t that hard. On the Juniper you pass the user credentials to the Terminal Server. On a normal Terminal Server you have to check the following:

Disable Always prompt for password under:

Terminal Services Configuration –> Connections –> Properties of RDP-tcp –> Tabblad Logon Settings

On a Terminal Server, which is member of a Windows Domain, you have to check the following Group policy:

Disable Always prompt client for password upon connection under:

Computer Configuration –> Administrative Templates –> Windows Components –> Terminal Services –> Encryption and Security –> Policy “Always prompt client for password upon connection”

Now I had to configure Single Sign On to a Terminal Server where the Novell Client is installed. As soon as I pushed the user credentials to the Terminal Server, I noticed that the RDP session tries to logon as Workstation only. I found a nice thread on the Novell website to Enable TSClientAutoAdminLogon.

I added the following two registry keys to the registry:

HKEY_LOCAL_MACHINE\SOFTWARE\Novell\Login 
Value Type=REG_SZ, Name=TSClientAutoAdminLogon, Data=1 
Value Type=REG_SZ, Name=DefaultLoginProfile, Data=Default 

I am able to logon to the Terminal Server using SSO after adding both registry keys to the registry. All registry entries under HKEY_LOCAL_MACHINE\SOFTWARE\Novell\Login are displayed in the picture below.

SSO_TS_novell_client