Using Clientless SSL Remote Access VPNs (WebVPN) on the Cisco VPN 3000 Concentrator

As discussed at the beginning of this chapter, one great advantage of SSL VPNs is that they do not require dedicated client softwarethe only software that is required is a standard web browser and e-mail software such as Microsoft Outlook Express, if e-mail functionality is required via POP3/IMAP4/SMTP.

This section examines how it is possible to provide file server access, website access, and TCP application access using clientless SSL remote access VPNs. Before enabling these types of access of SSL, however, it is necessary to complete basic SSL remote access VPN configuration tasks on the VPN 3000 concentrator.

Completing Basic SSL Remote Access VPN Access Configuration Tasks on the Cisco VPN 3000 Concentrator

Before you can enable SSL remote access VPN functionality such as file access or port forwarding, it is necessary to complete a number of basic configuration tasks:

Step 1.

Enroll and obtain a (SSL) certificate for the VPN 3000 concentrator from a certificate authority (CA) (optional).
 

Step 2.

Enable WebVPN for relevant user groups (or create a group specifically for WebVPN access).
 

Step 3.

Specify acceptable versions of SSL and configure cryptographic algorithms associated with SSL cipher suites.
 

Step 4.

Enable SSL on the VPN 3000 concentrator's public interface.
 

The sections that follow describe these steps in further detail. Before moving on to step 1, however, it is worth mentioning that on the Cisco VPN 3000 concentrator, WebVPN uses global DNS settings rather than those specified under a group. So, make sure that you specify global DNS settings under Configuration > System > Servers > DNS.

Step 1: Enroll and Obtain a (SSL) Certificate for the VPN 3000 Concentrator from a Certificate Authority (Optional)

As described earlier in this chapter, clients authenticate the VPN gateway during the RSA handshake using the VPN gateway's certificate (or certificate chain).

The certificate that the VPN gateway uses to identify itself is shown under the SSL Certificates heading (public interface) in Administration > Certificate Management (see Figure 10-15).

Figure 10-15. SSL Certificate

By default, the SSL certificate for the public interface is self-generated (it is not obtained from a CA). Although it is okay to use this certificate for testing, it is usually a good idea to enroll the VPN 3000 concentrator with a CA and obtain a certificate to use for the SSL handshake.

Obtain the CA's certificate, and then click Enroll under the Actions section under the SSL Certificates heading (public interface) to obtain a certificate for the SSL handshake. Obtaining the CA's certificate and enrolling with the CA can be achieved using the procedures described previously in Chapter 8, "Designing and Implementing L2TPv2 and L2TPv3 Remote Access VPNs," and Chapter 9, "Designing and Deploying IPsec Remote Access and Teleworker VPNs."

Note that during the SSL handshake, client web browsers will display a warning concerning the certificate(s) sent by the VPN gateway. Users can bypass this warning simply by clicking in the affirmative when asked whether the certificate should be accepted. If you do not want this warning to display, you can install the certificate of the CA with which the VPN gateway enrolled into the certificate store of the browser.

Step 2: Enable WebVPN for Relevant User Groups

The next step is for WebVPN to be enabled for relevant user groups. As shown in Figure 10-16, this is simply accomplished by going to Configuration > User Management > Groups, choosing the relevant group, clicking Modify Group, choosing the General tab, and checking the WebVPN box under Tunneling Protocols.

Figure 10-16. Enabling WebVPN for Relevant User Groups

 

Step 3: Specify Acceptable Versions of SSL and Configure Cryptographic Algorithms Associated with SSL Cipher Suites (Optional)

Next, it is a good idea (although optional) to go to Configuration > Tunneling and Security > SSL > Protocols, and specify acceptable versions of SSL as well as cryptographic algorithms associated with SSL cipher suites (see Figure 10-17).

Figure 10-17. Specifying Acceptable Versions of SSL, as Well as Cryptographic Algorithms Associated with SSL Cipher Suites

As you can see in Figure 10-17, the encryption (and hashing) algorithms associated with cipher suites that you can enable are 3DES-168/SHA, RC4-128/MD5, DES-56/SHA. By checking or unchecking these, an administrator can control the algorithms associated with the cipher suite that is accepted by the VPN gateway (and sent in the ServerHello message to the client). In Figure 10-17, only 3DES-168/SHA is enabled.

It is also possible to specify which versions of SSL that the VPN gateway will accept or negotiate with clients by choosing the appropriate option in the drop-down box. SSLv2 has a number of well-known vulnerabilities, and so, unsurprising, the VPN 3000 concentrator supports only SSLv3 and TLS.

Note

When deciding which versions of SSL to accept or negotiate, it is important to note that although most recent versions of popular web browsers support both SSLv3 and TLS (and often SSLv2), some browsers do not have TLS enabled by default.

For example, TLS is not enabled by default in Internet Explorer 6.0 (SSLv2 and SSLv3 are). TLS (v1.0) can be enabled in Internet Explorer 6.0 by going to Tools > Internet Options > Advanced and checking it under Security. In Internet Explorer 7.0, on the other hand, SSLv3 and TLS are enabled by default, while SSLv2 is disabled.

Firefox 1.0 supports SSLv2, SSLv3, and TLS (v1.0) by default.

In summary, if possible, it is a good idea to establish which types of browser users will be connecting from. If this is not possible (if users will be connecting from Internet cafés, and so on), it is a good idea to accept or allow the negotiation of SSLv3 (and optionally TLS).

In Figure 10-17, the VPN gateway has been configured to negotiate either SSLv3 or TLS with clients.

Finally, it is possible to configure the interval at which the VPN gateway will rekey (establish new cryptographic keys) with workstation running the Cisco SSL VPN Client. You can find more information on the Cisco SSL VPN Client later in this chapter.

Step 4: Enable SSL on the VPN 3000 Concentrator's Public Interface

The last of the basic steps is enabling SSL on the public interface of the Cisco VPN 3000 concentrator. This can be achieved by going to Configuration > Interfaces, clicking the public interface, and then choosing the WebVPN tab (see Figure 10-18).

Figure 10-18. Enabling SSL on the Public Interface

As shown in Figure 10-18, it is possible to enable SSL on the public interface by allowing HTTPS, POP3S, IMAP4S, and SMTPS.

To enable SSL for basic features such as access to file and HTTP servers, as well as TCP application access via port forwarding, you must check the Allow WebVPN HTTPS sessions box.

If proxy e-mail access is also required, you must also check the Allow POP3S sessions, Allow IMAP4S, and Allow SMTPS sessions boxes as appropriate. POP3 and IMAP4 can be used for inbound e-mail access, and SMTP is used for outbound e-mailyou should check the boxes according to which protocols are used by your e-mail clients and servers.

Another useful option is Redirect HTTP to HTTPS. If this box is checked, the VPN concentrator will cause the browsers of remote access user who type http://ip_address_or_name_of_VPN_concentrator to instead access the Cisco VPN 3000 concentrator using HTTPS (https://ip_address_or_name_of_VPN_concentrator).

It is also a good idea to navigate to Configuration > Tunneling and Security > SSL > HTTPS and verify that HTTPS is enabled (the default), the TCP port used for HTTPS, and to enable client authentication if desired.

The HTTPS configuration options shown in Figure 10-19 are as follows:

  • Enable HTTPS This option, if checked, enables HTTP over SSL (the default).
  • HTTPS Port This is used to specify the TCP port used for HTTPS (default 443).
  • Client Authentication This option, if checked, configures client authentication with the RSA handshake.

    Note that when client authentication is enabled, the client must obtain the certificate of CA and also obtain an identity certificate.

    See the section, "Understanding the SSL RSA Handshake with Client Authentication" earlier in this chapter for more information on this topic.

Figure 10-19. Configuring Additional Basic SSL Options

 

Configuring File and Web Server Access via SSL Remote Access VPNs

One of the most basic levels of access that you can enable via an SSL remote access VPNs is file and/or web server access.

To enable file server access, it is necessary to complete the following tasks:

Step 1.

Configure one or more NetBIOS name servers.
 

Step 2.

Configure WebVPN file servers and shares.
 

Step 3.

Enable file access for the WebVPN user group(s).
 

Step 1: Configure One or More NetBIOS Name Servers

You can accomplish configuration of a NetBIOS name server by going to Configuration > System > Servers > NBNS (see Figure 10-20).

Figure 10-20. Configuring NBNS Addresses

The first step is to enable NBNS by checking the Enabled box.

Next, you can choose WINS or Master Browser in the Server Type drop-down box.

The IP addresses of primary, secondary, and tertiary NBNS servers can then be configured in the appropriate boxes.

Finally, you can configure the timeout period in seconds, as well as the number of timeout retries. Unless you have a good reason, it is a good idea to leave these at their defaults (2 and 2).

Step 2: Configure WebVPN File Servers and Shares

To configure server names and shares for users to access, go to Configuration > Tunneling and Security > WebVPN > Servers and URLs > Add.

Figure 10-21 shows the configuration of file access for SSL remote access VPN users.

Figure 10-21. Configuring File or Web Server Access

You can type a description of the file or web server in the Name box. This description appears on the WebVPN home page when SSL remote access VPN users successfully authenticate on the VPN 3000 concentrator.

In the Server Type drop-down box, you can choose the server type (either Common Internet File System [CIFS], HTTP, or HTTPS). CIFS is based on the Server Message Block (SMB) protocol and can be used to request file and print services from Windows or other servers.

You must then specify the name of the server or share in the Remote Server box. When using CIFS, you must specify the server name or share in the //server/share format.

When all the boxes have been completed, click the Apply box.

Step 3: Enable File and URL Access for the WebVPN User Group(s)

After server names and shares have been configured, the next step is to enable file access under the appropriate group or groups.

Under Configuration > User Management > Groups, choose the appropriate group, click Modify Group, click the WebVPN tab, and you will see the page shown in Figure 10-22.

Figure 10-22. Enabling File and/or Web Server Access Under Group Settings

Check the Enable File Access box to enable (appropriately enough) file server access.

Checking the Enable File Server Browsing box allows users to browse files and folders on servers (server file and folder permissions permitting).

It may also be a good idea to check the Enable File Server Entry box to place server names or file paths on the home page of SSL remote access VPN users.

When a user connects to the VPN 3000 concentrator and authenticates, he/she will see the share listed in the home page (see Figure 10-23).

Figure 10-23. Accessible File and Web Servers

Figure 10-23 shows file shares, including in the one created in Figure 10-21. By clicking these links, the remote access VPN user will be able to access those resources (see Figure 10-24).

Figure 10-24. Accessing Files on a File Server

As shown in Figure 10-24, it is possible (file server and VPN 3000 concentrator configuration permitting) to browse files and folders, open, create, rename, and copy files to the server.

Note

The Java Runtime Environment (JRE) version 1.4 or later must be installed on client workstations for file access to function correctly.

It is also worth noting that it might be necessary to modify local policies on a Windows 2003 domain controller when configuring file access. Specifically, it might be necessary to open the Domain Controller Security Policy (found under Administrative Tools) and under Local Policies > Security Options disable the Microsoft network server: Digitally sign communication (always) policy (right-click and choose Properties).

Figure 10-25 shows modification of the Microsoft network server: Digitally sign communication (always) policy.

Figure 10-25. Modifying Security Options on a Windows 2003 Domain Controller

Configuration of URL access is similarly configured as follows:

Step 1.

Configure HTTP/HTTPS proxy server addresses as required.
 

Step 2.

Configure URLs under Configuration > Tunneling and Security > WebVPN, click Servers and URLs (see Figure 10-21), click Add, and then add a URL. The server type should be specified as HTTP or HTTPS as appropriate.
 

Step 3.

Enable URL entries under Configuration > User Management > Groups, choose the appropriate group, click Modify Group, choose the WebVPN tab (see Figure 10-22), and check Enable URL Entry.
 

It is possible to control remote users' web access by configuring HTTP/HTTP proxy server addresses on the VPN 3000 concentrator. In this case, HTTP/HTTPS connections from remote users are forwarded from the VPN 3000 concentrator to the proxy server(s).

As shown in Figure 10-26, configuration of HTTP/HTTPS proxy servers is achieved under Configuration > Tunneling and Security > WebVPN > HTTP/HTTPS Proxy.

Figure 10-26. Configuring HTTP/HTTPS Proxy

Configuration is fairly self-explanatory:

  • HTTP Proxy This is the IP address of the proxy server to which HTTP WebVPN requests are redirected by the VPN 3000 concentrator.
  • HTTP Proxy Port The TCP port used by the HTTP proxy server.
  • HTTPS Proxy The IP address of the proxy server to which HTTPS WebVPN requests are redirected.
  • HTTPS Proxy Port The TCP port used by the HTTPS proxy server.
  • Default Timeout The timeout, in minutes, for WebVPN sessions if one is not set in group settings.

Enabling TCP Applications over Clientless SSL Remote Access VPNs

Apart from file and web server access, another form of access via clientless SSL remote access VPNs is that for TCP-based applications. Remote access VPN users can access TCP-based applications via a VPN 3000 concentrator using a mechanism called port forwarding.

One of the most popular applications to enable using port forwarding is Windows Terminal Services, which allows remote access users to remotely access a desktop and applications that are installed on a Windows server, with screen bitmaps transported over the network between the remote users and the server. This method of server desktop and application hosting conforms to the thin-client model.

Note

To enable Citrix MetaFrame support with WebVPN, you must check the Enable Citrix MetaFrame box on the WebVPN tab under Groups.

Note that in this case, an SSL certificate with a fully qualified domain name (not an IP address as the common name) must be installed on the public interface on the VPN 3000 concentrator.

This section covers how to enable Windows Terminal Services for port forwarding over SSL. Other TCP-based applications can be similarly enabled.

Figure 10-27 illustrates the port-forwarding concept. In Figure 10-27, on the client, traffic sent to IP address 127.0.0.x, TCP port 3389 (Windows Terminal Services) is redirected over SSL to the VPN 3000 concentrator. The VPN 3000 concentrator then forwards this traffic to the application server. Return traffic from the server is then sent to the VPN 3000 concentrator, which then forwards it over SSL to the client.

Figure 10-27. The TCP Port-Forwarding Concept

Configuration of port forwarding is fairly straightforward. The first step is to enable port forwarding by checking the Enable Port Forwarding box under the user group, as illustrated in Figure 10-22 on page 933.

After port forwarding has been enabled for the user group, it is then simply a case of going to Configuration > Tunneling and Security > WebVPN > Port Forwarding, clicking Add, and specifying TCP port forwarding parameters (see Figure 10-28).

Figure 10-28. Configuring Port Forwarding

The various boxes shown in Figure 10-28 are fairly self-explanatory.

You can enter a description for the application in the Name boxthis is displayed on the remote access VPN client when the user enables application access.

Next, the port that the client uses to connect to the application should be specified in the Local TCP Port box. This setting controls which TCP traffic will be redirected over SSL to the VPN 3000 concentrator by the remote client. In the example shown, traffic using TCP port 3389 (the default Windows Terminal Services port) will be redirected over SSL to the VPN 3000 concentrator.

The IP address or name of the application server must then be entered in the Remote Server box.

If the IP address of applications servers are specified then they are accessed from the user workstation by specifying the IP address 127.0.0.1.

If the names of application servers are specified, the hosts file on Windows user workstations are modified during WebVPN access, with the first application used for port forwarding being mapped to IP address 127.0.0.2, the second application being mapped to IP address 127.0.0.3, and so on.

Finally, configure the TCP port that the application uses on the application server in the Remote TCP Port box. This TCP port will often be the same as that entered in the Local TCP Port box.

Click Add, and port forwarding will be ready for use for the particular application just configured.

For port forwarding to function, the Sun JRE must be installed on the clients, and this requires the person installing the software have administrative rights on that workstation. Because administrative rights are required for the installation of the JRE, it is unlikely that remote access users will be able to access applications using port forwarding from locations such as Internet cafés or airport Internet kiosks.

Note

JRE can be downloaded from the Sun website. At the time of this writing, the download location is as follows:

http://java.sun.com

Note that Microsoft Java cannot be used for port forwarding.

Also, make sure that either Negotiate SSLv3 or Negotiate SSLv3/TLS is chosen under Configuration > Tunneling and Security > SSL > Protocols. If one of these two options is not chosen, port forwarding will not function.

Remote access VPN users must connect to the VPN 3000 concentrator and access their home page using their web browser. Users can then click the Start Application Access link on either the home page itself or on the pop-up dialog box (make sure that pop-ups are allowed!) to enable application port forwarding for the SSL connection. Take a look back at Figure 10-23 on page 934 to see the Start Application Access link on the home page.

When a user clicks the Start Application Access link, a Java applet opens the Application Access window on the client, and application port forwarding is enabled.

Figure 10-29 shows access to Windows Terminal Services using port forwarding over SSL.

Figure 10-29. Access to Windows Terminal Services Using Port Forwarding over SSL

In the upper-left corner of the screen in Figure 10-29, you can see the Application Access window. As you can see, it lists the application names, associated local and remote TCP ports, remote application server IP addresses, the number of application data bytes sent (Bytes Out) and received (Bytes In), and the number of sockets open for particular applications. The application names, TCP ports, and remote application server IP addresses are, as previously described, configured under Configuration > Tunneling and Security > WebVPN > Port Forwarding (see Figure 10-22).

The main window in Figure 10-29 shows the remote desktop on the remote Windows Terminal Server accessed via the VPN 3000 concentrator.

One important detail in Figure 10-29 is the local IP address used to access the remote TCP application. Notice that the local IP address shown in the Application Access window (and in the upper-left corner of the main window) is 127.0.0.1. This is the IP address that is typed into the Computer box of the Remote Desktop Connection application used on Windows XP to access the Windows Terminal Server. Of course, 127.0.0.x is used to specify the local system, and this (TCP) traffic is then redirected over SSL to the VPN 3000 concentrator.

As previously mentioned, when using DNS names, the redirection of application traffic that port forwarding relies upon is achieved by the modification of the local system's Hosts file. The Hosts file is modified when application access is enabled (a copy of the original file is saved during application access, and restored later).

Figure 10-30 shows a modified Hosts file that enables application traffic redirection during application access.

Figure 10-30. Modified Hosts File

In Figure 10-30, the Hosts file has been modified to include four entries, two corresponding to port forwarding to wints.mjlnet.com/wints (127.0.0.2) and two corresponding to termsrv.mjlnet.com/termsrv (127.0.0.3).

When enabling an application for port forwarding over SSL, it is important to establish that the application is, in fact, TCP based, and if so, which TCP ports it uses. After this information has been confirmed and obtained, the application should be enabled for port forwarding in a similar manner to that for Windows Terminal Services described in this section.

If you want to enable a remote access VPN user to Telnet to a terminal server (router) via the VPN 3000 concentrator, for example, you first need to establish that the application is TCP based (it is, of course), and the TCP port(s) that it uses (port 23).

After these facts have been established, port forwarding for Telnet to the terminal server can be configured as shown in Figure 10-31.

Figure 10-31. Configuring Port Forwarding for Telnet

In Figure 10-31, the name Telnet To Term Server has been configured for the Telnet port forwarding connection. This name is, of course, displayed on the WebVPN home page and in the Application Access window.

The local and remote TCP ports are configured as 23, and the remote server (terminal server) IP address is configured as 10.10.10.1 (an internal IP address).

Figure 10-32 shows how Telnet to the terminal server functions on a remote access VPN client. As shown, the user Telnets to the local IP address (127.0.0.x) to connect to the remote terminal server. Telnet packets are then redirected over SSL to the VPN 3000 concentrator that then proxies the Telnet connection to the terminal server.

Figure 10-32. Port Forwarding for Telnet on a Remote Access VPN Client

 

Configuring E-mail Proxy for SSL Remote Access VPN Users

E-mail proxy describes the process by which the VPN 3000 concentrator terminates POP3S (POP3 over SSL), IMAP4S (IMAP4 over SSL), and STMPS (SMTP over SSL) connections from remote access VPN clients and proxies those connections to internal e-mail servers.

Figure 10-33 depicts e-mail proxy for POP3S, IMAP4S, and SMTPS connections from remote access VPN clients.

Figure 10-33. E-Mail Proxy for POP3S, IMAP4S, and SMTPS Connections

In Figure 10-33, remote access VPN user Mark is using an e-mail client such as Outlook Express. His e-mail client is configured to connect to the VPN 3000 concentrator using POP3S (for incoming e-mail) and SMTPS for outgoing e-mail. The VPN 3000 concentrator proxies these connections to an internal e-mail server.

The configuration of e-mail proxy consists of enabling the appropriate e-mail protocols on the public interface and then configuring protocol port numbers, e-mail server IP addresses or names, and methods of authentication.

Enabling e-mail protocols (POP3S, IMAP4S, and SMTPS) on the public interface of the VPN 3000 concentrator by going to Configuration > Interfaces, choosing the public interface, and clicking the WebVPN tab. See Figure 10-18 on page 929 for information on the method of enabling e-mail protocols.

You can configure e-mail protocol port numbers, e-mail server IP addresses or names, and methods of authentication under Configuration > Tunneling and Security > WebVPN > Email Proxy (see Figure 10-34).

Figure 10-34. Configuring E-Mail Protocol Ports, Server Addresses or Names, and Methods of Authentication

The first two parameters (VPN Name Delimiter and Service Delimiter) are, as their names suggest, used to delimit VPN and e-mail server usernames and passwords.

The VPN Name Delimiter is used to separate the VPN usernames/passwords and e-mail server usernames/passwords. This delimiter is used when configuring the e-mail clientin the box on the e-mail client where the username is entered, the username that the VPN 3000 concentrator uses to authenticate the user, as well as the username that the e-mail server uses to authenticate the user must be configured. These usernames are separated in the box using the delimiting character specified by the VPN Name Delimiter.

So, for example, if the username used to authenticate the user on the VPN 3000 concentrator is mark, the username used to authenticate the user on the e-mail server is markj, and the delimiting character specified on the VPN 3000 concentrator is:, then mark:markj should be entered into the username box on the e-mail client (more on this later).

Similarly, the Service Delimiter is used to separate the e-mail server username from the e-mail server name itself. The default is @, which is often the delimiting character used on e-mail servers. If the delimiting character is different for your e-mail servers, the Service Delimiter should be modified using the drop-down box as appropriate.

Underneath the VPN Name Delimiter and Service Delimiter parameters are the settings for POP3S, IMAP4, and SMTPS ports, default e-mail server IP addresses or names, and methods of authentication.

The ports used for POP3S, IMAP4S, and SMTPS must match those specified on e-mail clients.

The default e-mail server IP addresses or DNS names should be entered into the appropriate boxes. Note that these are the mail servers to which e-mail traffic is sent when e-mail client do not explicitly specify e-mail servers.

As far as methods of authentication are concerned, it is possible to use one or more of the four different methods of authentication for POP3S, IMAP4S, and SMTPS:

  • Email Server If this box is checked then it indicates that the e-mail server(s) will authenticate POP3S, IMAP4S, and SMTPS. This box must be checked for POP3S and IMAP4S.
  • Concentrator This box must be checked if authentication of users on the VPN 3000 concentrator is also required.

    In this case, the e-mail server and concentrator usernames passwords must be separated in the e-mail clients' configuration using the VPN Name Delimiter character, as previously described.

  • Piggyback HTTPS When this box is checked, a regular HTTPS (WebVPN) session must have already been established via a web browser with the VPN 3000 concentrator.
  • Certificate If this box is checked, clients are required to authenticate themselves during the RSA handshake using a certificate.

Client configuration is fairly simpleclients should be configured such that they point to the VPN 3000 concentrator instead of directly to an e-mail server.

If you are using Outlook Express, for example, you must configure an e-mail account as normal; if you are using VPN 3000 concentrator authentication in addition to e-mail server authentication for POP3S or IMAP4S, however, you must configure the username and password appropriately (see Figure 10-35).

Figure 10-35. Configuring the Username and Password on Outlook Express When Using E-Mail Proxy

If you take a look under the "Incoming Mail Server" header in the Servers tab of the account properties, you will notice that the account name is mark:markj.

Because e-mail proxy via the VPN 3000 concentrator is being used, and Concentrator authentication is configured (see the Concentrator box in Figure 10-34), the VPN 3000 concentrator username (mark) is specified first, and the e-mail account name (markj) is specified next. The two usernames are separated using the VPN Name Delimiter (:) specified on the VPN 3000 concentrator (again, see Figure 10-34). If the usernames on both the VPN 3000 concentrator and the e-mail server are the same, it is only necessary to specify the username once (for example, mark).

Now, if the e-mail client in question wants to access e-mail on a mail server that is not the default (see configuration of Default E-Mail Server in Figure 10-34), the e-mail server name must be specified in this same box in this format:

(e-mail_server_username)[Server Delimiter](e-mail_server_name)

So, if the e-mail server is mserver2.mjlnet.com (not the default specified in Figure 10-34), the account name should be mark:markj@mserver2.mjlnet.com.

Next, the password on the Outlook Express account properties Server tab must be configured using a similar formatthe VPN 3000 concentrator user password must be specified first, with the e-mail server account password configured second. The two must again be separated using the VPN Name Delimiter.

If the VPN 3000 concentrator is configured to authenticate users and the password user mark is hello, and the e-mail server password for user markj is hithere, the password specified in the Password box on the client must be hello:hithere.

One other important setting to notice on the Server tab is the My server requires authentication check box under Outgoing Mail Server heading. It may be necessary to check this box if you receive an error when attempting to connect to the e-mail server via the VPN 3000 concentrator.

Having configured authentication, the next step is to specify POP3S and SMTPS ports under the Advanced tab, as shown in Figure 10-36.

Figure 10-36. Configuring SMTPS and POP3S Ports on Outlook Express When Using E-Mail Proxy

Under the Server Port Numbers heading you must check both of the This server requires a secure connection (SSL) boxes (for both SMTP and POP3).

Having checked the boxes, you must now specify the ports to use for each protocol. These ports must match those specified on the VPN 3000 concentrator. In Figure 10-36, for example, the SMTPS and POP3S ports are configured as 988 and 995, respectivelythese match those specified on the VPN 3000 concentrator in Figure 10-34.


Implementing Full Network Access Using the Cisco SSL VPN Client

Part I: Understanding VPN Technology

What Is a Virtual Private Network?

Part II: Site-to-Site VPNs

Designing and Deploying L2TPv3-Based Layer 2 VPNs

Designing and Implementing AToM-Based Layer 2 VPNs

Designing MPLS Layer 3 Site-to-Site VPNs

Advanced MPLS Layer 3 VPN Deployment Considerations

Deploying Site-to-Site IPsec VPNs

Scaling and Optimizing IPsec VPNs

Part III: Remote Access VPNs

Designing and Implementing L2TPv2 and L2TPv3 Remote Access VPNs

Designing and Deploying IPsec Remote Access and Teleworker VPNs

Designing and Building SSL Remote Access VPNs (WebVPN)

Part IV: Appendixes

Designing and Building SSL Remote Access VPNs (WebVPN)

Appendix B. Answers to Review Questions

show all menu





Comparing, Designing, and Deploying VPHs
Comparing, Designing, and Deploying VPNs
ISBN: 1587051796
EAN: 2147483647
Year: 2007
Pages: 124
Authors: Mark Lewis
Similar book on Amazon

Flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net