Application Delivery (ADX)

Microsoft Outlook Web Access (OWA) with ServerIron - Deployment guidelines

by Yasir_Liaqatullah on ‎06-09-2009 04:50 AM - edited on ‎10-30-2013 05:41 PM by bcm1 (3,040 Views)

Deploying Microsoft Exchange Outlook Web Access with ServerIron

 

 

Introduction

 

This document guides you through all the steps required to successfully deploy Microsoft Outlook Web Access with ServerIron. The first part of the document describes how to create a simple working environment with SSL offloading enabled. The second part discusses some optional configurations which are not required but are generally recommended. These include using Source-NAT, enforcing use of HTTPS by sending redirect message to incoming requests on HTTP, and maintaining persistence using cookies.

Contents

Pre-requisites
Network Topology
Required ServerIron configuration
     Assign an IP address to the ServerIron
     Importing keys and certificates
     Creating a SSL profile
     Creating Real-Servers
     Creating Virtual Server
     Configuring header insertion for "Front-End-Https: on"
     Minimum required Configuration
     Verifying Operation
Optional ServerIron configuration
     Overriding default behavior of HTTP downgrade
     Using source-nat and enabling client-ip-insertion
     Configuring http redirect to enforce the use of HTTPS
     Configuring persistence to a single front-end server using cookie-switching
Final Configuration with all optional features


Appendix 1 : Supported OWA Methods

Pre-requisites

The following are the pre-requisites for this deployment guide

  • You have an appropriate ServerIron SSL hardware e.g. SI-4G-SSL, SI-450/850 with SSL
  • The ServerIron must be running Traffic Works version 9.5.02c or later
  • The guide assumes that you have a working frond-end/back-end Microsoft Exchange system


Network Topology

 

The network topology is shown in figure 1. As the topology shows, it is a front-end / back-end architecture. The clients connect to the front-end servers using HTTP or HTTPs, and the front-end then communicates with back-end Exchange servers. This internal communication between front-end and back-end is invisible to the users. There is a Brocade ServerIron load-balancer in between the router and the front-end servers, and it load-balances incoming requests. Cookie-switching is used to persist requests to a single server.

 

 

 

 

Figure 1 : Network Topology

Required ServerIron configuration

 

 

The minimum required steps on the ServerIron to enable OWA with SSL-offload enabled are the following.

1.     Assign an IP address to the ServerIron

2.     Import keys and certificates

3.     Create an SSL profile

4.     Create Real-Servers

5.     Create Virtual Server

6.     Configure header insertion for "#Front-End-Https: on"

7.     Verify operation

 

1. Assign an IP address to the ServerIron

An IP address can be assigned to the ServerIron using the following command:

ServerIron#configure terminal
ServerIron(config)#ip address 10.1.1.9/24


2. Importing keys and certificates

It is assumed that there is an existing Key and Certificate in either PFX or in PEM format, and it needs to be imported to the ServerIron.

¨Tip

PFX and PKCS12 are very similar and most of the times they can be used interchangeably. In some cases you may have to convert a PFX file to a PEM file and the upload the key and Cert independently, but in all other cases you can ignore the extension and treat a PFX file just as a PKCS12

¨Note

Please refer to ServerIron manual for further information on obtaining certificate and key.

 

a) Importing a key in PFX format to the ServerIron

The following steps are required to import a key/certificate:

  • enable ssh server

(conf)# crypto key generate dsa

  • enable empty passwords, or use local authentication

(conf)# ip ssh permit-empty-passwd or

(conf)# user admin password <secret>

(conf)# aaa authentication login default local

(conf)# enable telnet authentication

  • Using SCP from a Linux machine, or PSCP from a Windows machine, upload the .PFX file to the serverIron using the command:
    scp <pkcs-formatted-file> <user>@<ip-address-of-ServerIron>:sslkeypair:<file-name-on-SI>:<password>Smiley Tonguekcs12

for example, if the local file name is msexchcert.pfx, the configured username on ServerIron is admin, the IP address is 10.1.1.9, and the password is foundry, the command to upload the PFX file will be:

scp msexchcert.pfx admin@10.1.1.9:sslkeypair:msexchcert:<secret>Smiley Tonguekcs12

b) Importing a key in PEM format to the ServerIron

  • enable ssh server

(conf)# crypto key generate dsa

  • enable empty passwords, or use local authentication

(conf)# ip ssh permit-empty-passwd or

(conf)# user admin password <secret>

(conf)# aaa authentication login default local

(conf)# enable telnet authentication

  • · Using SCP from a linux machine, or PSCP from a windows machine, upload the .PEM formatted certificate and the key.

for example, if the local file names are msexchcert.pem and msexchkey.pem, the configured username on ServerIron is admin, the IP address is 10.1.1.9, and the password is foundry, the command to upload the files will be:

scp msexchcert.pem admin@10.1.1.9:sslcert:msexchcertSmiley Tongueem

scp msexchkey.pem admin@10.1.1.9:sslkeypair:msexchkey:<secret>Smiley Tongueem

¨Note

It is imperative that the certificate is in proper chained format. Otherwise, you will get a security warning message when you connect to the virtual-server. Please refer to the ServerIron documentation guide on how to obtain and chain the intermediate certificate.

 

3. Creating a SSL profile

Once the key and certificate is uploaded to the ServerIron, the next step is configure the SSL profile. The SSL profile groups the Certificate, the key and additional parameters like list of cipher-suites. If the certificate and key will be in two individual files if they were uploaded as PEM files, however, they will be in a single file if they were uploaded as PKCS12/PFX.

The commands to create the profile are

ServerIron#configure terminal
ServerIron(config)#ssl profile exchsslprofile
ServerIron(config-ssl-profile-exchsslprofile)#ssl key-pair-file verisign128key
ServerIron(config-ssl-profile-exchsslprofile)#keypair-file verisign128key
ServerIron(config-ssl-profile-exchsslprofile)#certificate-file verisign128cert
ServerIron(config-ssl-profile-exchsslprofile)#cipher-suite all
ServerIron(config-ssl-profile-exchsslprofile)#enable-certificate-chaining
ServerIron(config-ssl-profile-exchsslprofile)#


¨Tip

ServerIron will not add a certificate to the profile if the key does match the certificate. To confirm that they match, issue a show-running and make sure that you see both the key and the certificate in the profile.

4. Creating Real-Servers

The next step is to configure the real-servers. The real-servers are the actual references to the front-end servers. In this scenario we are assuming that the real-servers are already configured and they are running web-servers, listening on port 80 (http). The IP addresses are already mentioned in the network topology.

The actual front-end-servers are listening only on http (80) port , however, we will define two ports on the real-servers in our configuration. The first port is http (80), and the second port is 8080. The second port is a dummy port and it will be used in the virtual server so that it can receive both HTTP and HTTPS traffic. We will discuss it further in the next section.

The commands to configure the real servers are:

ServerIron(config)#server real fes1 10.1.1.101
ServerIron(config-rs-fes1)#port http
ServerIron(config-rs-fes1)#port 8080
ServerIron(config-rs-fes1)#exit
ServerIron(config)#
ServerIron(config)#server real fes2 10.1.1.102
ServerIron(config-rs-fes2)#port http
ServerIron(config-rs-fes2)#port 8080
ServerIron(config-rs-fes2)#exit
ServerIron(config)#
ServerIron(config)#server real fes3 10.1.1.103
ServerIron(config-rs-fes3)#port http
ServerIron(config-rs-fes3)#port 8080
ServerIron(config-rs-fes3)#exit
ServerIron(config)#

 

 

5. Creating Virtual Server

Now we have to define a virtual-server. The virtual server will receive the incoming client-traffic and will load-balance it to one of the real-servers defined above. The virtual server will be listening on port HTTP as well as on HTTPS as the ServerIron is providing SSL-Acceleration services.

We will define an http port on the virtual server and bind it to the http ports on the real-servers. This will enable the Virtual Server to listen on port http.

(conf)#port http
(conf)#bind http fes1 http fes2 http fes3 http


We also have to define an SSL port on the virtual server to enable it to listen on port HTTPS (443). In addition to defining the port, we also have to enable SSL-Termination on it. This will ensure that the incoming SSL requests are properly converted to plain HTTP, thus, the incoming requests will be in SSL, while the outgoing requests will be in plain HTTP. The SSL-Profile is required as well, so that the correct certificate and key is bound to the port.

(conf)#port ssl
(conf)#port ssl ssl-terminate exchsslprofile


The only problem which we will see will be that since we already have a binding from http to http, therefore, we cannot define a new binding between ssl and http. We will circumvent this problem by using a small configuration trick. We will bind ssl to the dummy port 8080, but also define the real-port as http. Thus, SSL will be essentially bound to http.

(conf)# bind ssl fes1 8080 real-port http fes2 8080 real-port http fes3 8080 real-port http


The required configuration steps are:

ServerIron(config)#server virt VS_OWA 10.1.1.10
ServerIron(config-vs-VS_OWA)#port http
ServerIron(config-vs-VS_OWA)#bind http fes1 http fes2 http fes3 http
ServerIron(config-vs-VS_OWA)#port ssl

ServerIron(config-vs-VS_OWA)#no port ssl sticky
ServerIron(config-vs-VS_OWA)#port ssl ssl-terminate exchsslprofile
ServerIron(config-vs-VS_OWA)#bind ssl fes1 8080 real-port http fes2 8080 real-port http fes3 8080 real-port http

 

 

At this time the system should be ready to accept incoming connections and to load balance them to the front-end servers. One way to verify this is to issue the command "show server bind" and verify the output. All ports should be Active.

 

 

ServerIron#show server bind

Bind info
Virtual server: VS_OWA                   Status: enabled  IP: 10.1.1.10
         http -------> fes1: 10.1.1.101,  http (Active)
                       fes2: 10.1.1.102,  http (Active)
                       fes3: 10.1.1.103,  http (Active)
          ssl -------> fes1: 10.1.1.101,  8080 (Active-Active)
                       fes2: 10.1.1.102,  8080 (Active-Active)
                       fes3: 10.1.1.103,  8080 (Active-Active)
ServerIron#

 

 

6. Configuring header insertion for "#Front-End-Https: on"

#At this time the front-end servers are listening only on HTTP, while the virtual-server is listening on HTTP as well as HTTPS. This introduces a problem for requests coming on HTTPS. Since the front-end-servers do not know that the original requests was sent using https://, it will generate http:// links for the client. The can potentially break the system as the client was expecting an https:// link.

 

One of the solutions to fix this problem is insert a special header "front-end-https: on" on all requests going to the front-end-servers. Another solution is to add a registry entry.


¨Tip

- Form Based Authentication (FBA) and RPC-over-HTTP require registry keys
- Non FBA Outlook Web Access require header "Front-End-HTTPS: on"
- Outlook Mobile Access (OMA) does not support SSL offloading
- Exchange Auto Sync (EAS) does not require any additional configuration
(http://download.microsoft.com/documents/australia/teched2005/MSG304_Andaker.pdf)#

 

¨Note

To learn more about "front-end-https: on" Please refer to http://technet.microsoft.com/en-us/library/aa997519.aspx for further details

To learn more about registry keys please refer to http://support.microsoft.com/?kbid=327800 for further details.
##
#For General Microsoft Exchange deployment, please refer to http://www.microsoft.com/technet/solutionaccelerators/mobile/deploy/msfpdepguide.mspx

 

 

If in case header insertion is required than CSW feature of the ServerIron has to be used. This feature identifies traffic based on configured rules and takes an action. Multiple rules can be defined in a policy, and the policy has to applied on a port. In this case we need to add the header to all incoming requests, thus, we do not need a dedicated rule and can use a default rule.

Another requirement is that the real-servers has to be part of a group, thus, group-ids have to be defined on all servers.

 

#

ServerIron(config)##
ServerIron(config)#csw-policy exchpolicy
ServerIron(config-csw-exchpolicy)#default forward 10
ServerIron(config-csw-exchpolicy)#default rewrite request-insert header
ServerIron(config-csw-exchpolicy)#exit

ServerIron(config)#
ServerIron(config)#server virtual VS_OWA
ServerIron(config-vs-VS_OWA)#port ssl csw-policy exchpolicy
ServerIron(config-vs-VS_OWA)#port ssl csw  
ServerIron(config-vs-VS_OWA)#port ssl request-insert "Front-end-https: on"
#ServerIron(config-vs-VS_OWA)#exit#

#ServerIron(config)##
ServerIron(config)#server real fes1
ServerIron(config-rs-fes1)#port 8080 group-id 10 10
ServerIron(config-rs-fes1)#exit
ServerIron(config)#server real fes2
ServerIron(config-rs-fes2)#port 8080 group-id 10 10
ServerIron(config-rs-fes2)#exit
ServerIron(config)#server real fes3
ServerIron(config-rs-fes3)#port 8080 group-id 10 10
ServerIron(config-rs-fes3)#exit

##

 

7. Minimum required Configuration

 

Complete   configuration with VIP listening on HTTP and SSL

+ header   insertion for “front-end-http: on”

ServerIron#show running-config
!Building configuration...
!Current configuration : 1843 bytes
!
ver 09.5.02dTD2
!
module 1 bi-0-port-wsm6-ssl-management-module
module 4 bi-jc-8-port-gig-module
!
ssl profile exchsslprofile
  keypair-file verisign128key
  certificate-file verisign128cert
  cipher-suite all-cipher-suites
  enable-certificate-chaining
  session-cache off
!
csw-policy "exchpolicy"
  default forward 10
  default rewrite request-insert header
!
server real fes1 10.1.1.101
  port http
  port http url "HEAD /"
  port 8080
  port 8080 group-id  10 10
!
server real fes2 10.1.1.102
  port http
  port http url "HEAD /"
  port 8080
  port 8080 group-id  10 10
!                                                 
server real fes3 10.1.1.103
  port http
  port http url "HEAD /"
  port 8080
  port 8080 group-id  10 10
!
server virtual VS_OWA 10.1.1.10
  port http
  no port ssl sticky
  port ssl ssl-terminate exchsslprofile
  port ssl csw-policy "exchpolicy"
  port ssl csw
  port ssl request-insert "Front-end-https: on"
  bind http fes1 http fes2 http fes3 http
  bind ssl fes1 8080 real-port http fes2 8080 real-port http fes3 8080   real-port http
!
no enable aaa console
ip address 10.1.1.9 255.255.255.0
telnet server
snmp-server
web-management
!
end

 

 

 

 

 

8. Verifying Operation

verify server bindings and make sure that all server are up
      show server bind
verify the state of real servers
     show server real
verify the state of virtual server
     show server virtual

 

 

Optional ServerIron configuration

The following optional configuration are not required for OWA operation but are useful.

  • Overriding default behavior of HTTP downgrading from 1.1. to 1.0
  • Using source-nat and enabling client-ip-insertion
  • Configuring http redirect to enforce the use of HTTPS
  • Configuring persistence to a single front-end server using cookie-switching

 

Overriding default behavior of HTTP downgrade

When CSW is enabled ServerIron downgrades the incoming HTTP version. For example, if the client sends a request using HTTP/1.1, the ServerIron parses the request, and after Layer-7 header-insertion etc, sends it out to the real-servers. However, the outgoing request is in HTTP/1.0.

 

Thus essentially, the ServerIron downgrades the incoming version from 1.1. to 1.0

 

There are multiple configuration options to override this default behavior. The two common techniques are:

1.     port ssl keep-alive

2.     port ssl tcp-offload

Both of these commands are applied on virtual server level. For this particular example, we will use the first method i.e. port ssl no-keep-alive.

 

The required commands are:

 

SLB-ServerIron#configure terminal

SLB-ServerIron(config)#server virtual VS_OWA

SLB-ServerIron(config-vs-VS_OWA)#port ssl keep-alive

SLB-ServerIron(config-vs-VS_OWA)#end

SLB-ServerIron#

 

 

1.               Using source-nat and enabling client-ip-insertion

Source is required when an SSL service module is used in SI-450/SI-850. It is not a requirement in chassis based systems with integrated SSL module, or with SI-4G-SSL.

When Source-NAT is enabled, the ServerIron replaces the original source-ip from the incoming request and replace it with another IP, and then send the request to the Real-Server. On the return traffic, it replaces this IP with the original source-ip, and then forwards the response to the client.

Thus, source-ip enable the ServerIron to act as a full proxy for all incoming connections.

Source-NAT can be enabled by taking the following steps:
a) specify a source-nat-ip for normal traffic, and another source-nat-ip for SSL terminated traffic.
  server source-nat-ip <source-nat-ip>/<mask> <gateway-ip> port-range 2
   server source-nat-ip <source-nat-ip>/<mask> <gateway-ip> port-range 2 for-ssl
     b) enable source-nat on the real servers
  source-nat

In our sample configuration, the required commands are:

ServerIron(config)#server source-nat-ip 10.1.1.250/24 0.0.0.0 port-range 2
ServerIron(config)#server source-nat-ip 10.1.1.251/24 0.0.0.0 port-range 2 for-ssl
ServerIron(config)#
ServerIron(config)#server real fes1
ServerIron(config-rs-fes1)#source-nat
ServerIron(config-rs-fes1)#exit
ServerIron(config)#server real fes2
ServerIron(config-rs-fes2)#source-nat
ServerIron(config-rs-fes2)#exit
ServerIron(config)#server real fes3
ServerIron(config-rs-fes3)#source-nat
ServerIron(config-rs-fes3)#exit
ServerIron(config)#


A side effect of enabling source-nat is that the front-end servers will not be able to see the original source-ip, as it is replaced by the source-nat-ip. This a classic problem with all proxies, and the work around is to preserve the original-ip in an additional header. In some cases the name of this header is "X-Forwarded-for:". By default ServerIron calls this header "Client-IP:", but the name can be changed to any user defined string, including "X-Forwarded-for".

The CSW feature "client-ip-insertion" is used for this additional header insertion. The default rule can be used for this purpose as the header has to be inserted in all incoming requests. Most of the configuration required for adding a CSW-Policy was already done in step-6 of last section when CSW-Header insertion was enabled, but is done again for sake of completeness.

ServerIron(config)#
ServerIron(config)#csw-policy exchpolicy
ServerIron(config-csw-exchpolicy)#default forward 10
ServerIron(config-csw-exchpolicy)#default rewrite request-insert client-ip
ServerIron(config-csw-exchpolicy)#exit

ServerIron(config)#
ServerIron(config)#server virtual VS_OWA
ServerIron(config-vs-VS_OWA)#port ssl csw-policy exchpolicy
ServerIron(config-vs-VS_OWA)#port ssl csw  
ServerIron(config-vs-VS_OWA)#exit

ServerIron(config)#
ServerIron(config)#server real fes1
ServerIron(config-rs-fes1)#port 8080 group-id 10 10
ServerIron(config-rs-fes1)#exit
ServerIron(config)#server real fes2
ServerIron(config-rs-fes2)#port 8080 group-id 10 10
ServerIron(config-rs-fes2)#exit
ServerIron(config)#server real fes3
ServerIron(config-rs-fes3)#port 8080 group-id 10 10
ServerIron(config-rs-fes3)#exit

 


¨Tip

To modify the default header from "Client-IP:" to "X-Forwarded-for", use the virtual server level command "port ssl request-insert client-ip "X-Forwarded-for"

 

 

The configuration now becomes:

 

 

Complete   configuration with VIP listening on HTTP and SSL

+ and header   insertion for “front-end-http: on”

+ ourceNAT   operation

+   client-ip-insertion

ServerIron#show running
!Building configuration...
!Current configuration : 2187 bytes
!
ver 09.5.02dTD2
!
module 1 bi-0-port-wsm6-ssl-management-module
module 4 bi-jc-8-port-gig-module
!
ssl profile exchsslprofile
   keypair-file verisign128key
   certificate-file verisign128cert
   cipher-suite all-cipher-suites
   enable-certificate-chaining
   session-cache off
!                                                
server source-nat-ip 10.1.1.250 255.255.255.0 0.0.0.0 port-range 2
server source-nat-ip 10.1.1.251 255.255.255.0 0.0.0.0 port-range 2 for-ssl
!
csw-policy "exchpolicy"
   default forward 10
   default rewrite request-insert header
   default rewrite request-insert client-ip
!
!
server real fes1 10.1.1.101
   source-nat
   port http
   port http url "HEAD /"
   port 8080
   port 8080 server-id 1211
   port 8080 group-id  10 10
!
server real fes2   10.1.1.102                       
        source-nat
   port http
   port http url "HEAD /"
   port 8080
   port 8080 server-id 1212
   port 8080 group-id  10 10
!
server real fes3 10.1.1.103
   source-nat
   port http
   port http url "HEAD /"
   port 8080
   port 8080 server-id 1213
   port 8080 group-id  10 10
!
server virtual VS_OWA 10.1.1.10
   port http
   port ssl
   no port ssl sticky
   port ssl ssl-terminate exchsslprofile
   port ssl cookie-name "ServerID"
   port ssl csw-policy   "exchpolicy"                 
        port ssl csw
   port ssl request-insert "Front-end-https: on"
port ssl keep-alive

  bind http fes1 http fes2 http fes3 http
   bind ssl fes1 8080 real-port http fes2 8080 real-port http fes3 8080   real-port http
!
no enable aaa console
ip address 10.1.1.9 255.255.255.0
telnet server
snmp-server                                       
web-management
!

end
ServerIron#

 

 

2.               Configuring http redirect to enforce the use of HTTPS

Often times Exchange architects want to enforce the use of HTTPS and the incoming requests on plain HTTP are dropped. An alternate solution is to send an HTTP redirect message in response to such requests and thus redirect them to HTTPS.

Request (coming to http://10.1.1.10/index.html)

GET /index.html HTTP/1.1\r\n

Host: webmail.mycompany.com\r\n

\r\n

Response (redirected to https://10.1.1.10/index.html)

HTTP/1.1 302 Moved Temporarily\r\n

Server:HTTP Proxy/1.0\r\n

Connection: close\r\n

Content-Length: 0\r\n

Location: https://10.1.1.10/index.html\r\n

\r\n

CSW can be used to achieve this redirection. Since this policy has to be applied on all incoming HTTP requests, thus, a default rule can be used. Also, this rule will be applied only on port HTTP as the redirection should happen only for clear-text requests.

ServerIron(config)#csw-policy redirectpolicy
ServerIron(config-csw-redirectpolicy)#default redirect * * ssl
ServerIron(config-csw-redirectpolicy)#exit
ServerIron(config)#
ServerIron(config)#server virtual VS_OWA
ServerIron(config-vs-VS_OWA)#port http csw-policy redirectpolicy
ServerIron(config-vs-VS_OWA)#port http csw      
ServerIron(config-vs-VS_OWA)#exit
ServerIron(config)#

 

3.               Configuring persistence to a single front-end server using cookie-switching

Another common requirement is persistence. Persistence can be achieved through cookie-switching. Persistence is required so that a single client always go the same front-end server. The ServerIron achieves this by assigning a special ID to each of the real servers. When a client connects to the ServerIron for the first time, ServerIron send it a "cookie". The client accepts this cookie and stores it locally. The next time the client connects to the ServerIron, it sends the same cookie. ServerIron recognizes the cookie and based on the special value it switches the client to the original front-end real server.

Cookie switching is a part of CSW and can be added to the existing policy. We will add a new rule to the existing policy, which will match the cookie and extract the server-id. Once the server-id is retrieved, the request can be switched to the proper server. We also need to consider the case when the incoming request does not have a cookie. All such requests will hit the default rule, and we need to configure an action such that a new cookie is inserted.

We also need to configure the cookie-name under the virtual-server, in our case, it is ServerID. The Server-ID values have to be configured for each real-server. These values are the same which are sent to clients as Cookie, and are used for subsequent switching decision.

The following configuration achieves the above requirements.

ServerIron(config)#csw-rule r1 header "cookie" search "ServerID="
ServerIron(config)#csw-policy exchpolicy
ServerIron(config-csw-exchpolicy)#match r1 persist offset 0 length 4 group-or-server-id
ServerIron(config-csw-exchpolicy)#match r1 rewrite request-insert header
ServerIron(config-csw-exchpolicy)#match r1 rewrite request-insert client-ip
ServerIron(config-csw-exchpolicy)#default rewrite insert-cookie
ServerIron(config-csw-exchpolicy)#exit
ServerIron(config)#

ServerIron(config)#server virtual VS_OWA
ServerIron(config-vs-VS_OWA)#port ssl cookie-name "ServerID"
ServerIron(config-vs-VS_OWA)#exit
ServerIron(config)#

ServerIron(config)#
ServerIron(config)#server real fes1
ServerIron(config-rs-fes1)#port 8080 server-id 1211
ServerIron(config-rs-fes1)#exit
ServerIron(config)#server real fes2
ServerIron(config-rs-fes2)#port 8080 server-id 1212
ServerIron(config-rs-fes2)#exit
ServerIron(config)#server real fes3
ServerIron(config-rs-fes3)#port 8080 server-id 1213
ServerIron(config-rs-fes3)#exit
ServerIron(config)#

 

Final Configuration with all optional features

After adding all the required and optional configurations, the final form is as the following

Complete   configuration with VIP listening on HTTP and SSL, using Source-NAT

+ Client-IP   Insertion

+ header   insertion for “front-end-http: on”

+ HTTP Redirect   to HTTPS

+   Cookie-Switching

ServerIron#
ServerIron#show runn
!Current configuration : 2244 bytes
!
ver 09.5.02dTD2
!
module 1 bi-0-port-wsm6-ssl-management-module
module 4 bi-jc-8-port-gig-module
!
ssl profile exchsslprofile
   keypair-file verisign128key
   certificate-file verisign128cert
   cipher-suite all-cipher-suites
   enable-certificate-chaining
   session-cache off
!
csw-rule "r1" header "cookie" search "ServerID="
!
csw-policy "exchpolicy"
   match "r1" persist offset 0 length 4 group-or-server-id
   match "r1" rewrite request-insert header
   default forward 10
   default rewrite insert-cookie
   default rewrite request-insert header
!
csw-policy "redirectpolicy"
   default redirect "*" "*" ssl
!
server real fes1 10.1.1.101
   port http
   port http url "HEAD /"
   port 8080
   port 8080 server-id   1211                         
        port 8080 group-id  10 10
!
server real fes2 10.1.1.102
   port http
   port http url "HEAD /"
   port 8080
   port 8080 server-id 1212
   port 8080 group-id  10 10
!
server real fes3 10.1.1.103
   port http
   port http url "HEAD /"
   port 8080
   port 8080 server-id 1213
   port 8080 group-id  10 10
!
server virtual VS_OWA 10.1.1.10
   port http
   port http csw-policy "redirectpolicy"
   port http csw
   port ssl
   no port ssl   sticky                               
        port ssl ssl-terminate exchsslprofile
   port ssl cookie-name "ServerID"
   port ssl csw-policy "exchpolicy"
   port ssl csw
port ssl request-insert   "Front-end-https: on"

port ssl   keep-alive
bind http fes1 http fes2 http   fes3 http
bind ssl fes1 8080 real-port   http fes2 8080 real-port http fes3 8080 real-port http
!
no enable aaa   console                             
ip address 10.1.1.9 255.255.255.0
telnet server
snmp-server
web-management
!
end                                               
ServerIron#

 

Appendix 1 : Supported OWA Methods

 

ServerIron TrafficWorks support the following well-known HTTP methods:

 

GET, HEAD, POST, PUT,

DELETE, TRACE, CONNECT.

 

Starting with version 9.5.02, TrafficWorks also support the following additional Microsoft OWA methods:

 

BDELETE,     PROPPATCH, COPY,         LOCK,

UNLOCK,      MKCOL,                   BCOPY,                   BMOVE,

POLL,          SUBSCRIBE, SEARCH,     BPROPPATCH,

RPC_OUT_DATA, RPC_IN_DATA.

 

Any other command will not be properly understood by the CSW mechanism and the ServerIron will send a reset to the incoming client.

 

 

 

 

 

 

Contributors