Easy VPN- IOS to IOS client mode

In this minilab we will setup Easy VPN in client mode using IOS routers as both server and client. This will serve as base for other Easy VPN labs. In this scenario we will be using client mode with split tunneling, and enabling the client router to authenticate in the xauth phase ("save password") to make things easy to test.
Here's our topology:

R0's f0/0 connects to R1's f0/0, both connect to their internal networks via their f1/0 interface

And here´s the breakdown of the necessary tasks:

1. Server side configuration:
1. AAA and users
2. ISAKMP policy and IPsec transform-set
3. IP address pool
4. ACL for split tunneling
5. Client group configuration
6. Dynamic crypto map
7. Ezvpn crypto map
8. Apply crypto map to interface
2. Client side configuration:
1. IPsec client configuration
2. Assign interfaces as inside and outside

 Server config
1-AAA and users
R0#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R0(config)#aaa new-model
R0(config)#aaa authentication login aaa_auth local
R0(config)#aaa authorization network aaa_author local
R0(config)#username cisco password cisco

2-ISAKMP policy and IPsec transform-set 
 R0(config)#crypto isakmp policy 10
R0(config-isakmp)#authentication pre-share
R0(config-isakmp)#encryption aes
R0(config-isakmp)#group 2
R0(config-isakmp)#hash md5
R0(config)#exit
R0(config)#crypto ipsec transform-set tset esp-aes esp-sha-hmac
R0(cfg-crypto-trans)#exit

Note: The ISAKMP policy must use Diffie-Hellman group 2!

3- IP address pool
 R0(config)#ip local pool ezpool 4.4.4.1 4.4.4.10

4-ACL for split tunneling
R0(config)#access-list 199 permit ip 2.2.2.0 0.0.0.255 any

5-Client group configuration
R0(config)#crypto isakmp client configuration group MYGROUP 
R0(config-isakmp-group)#pool ezpool
R0(config-isakmp-group)#acl 199
R0(config-isakmp-group)#key cisco
R0(config-isakmp-group)#save-password

6-Dynamic crypto map
R0(config)#crypto dynamic-map DYNMAP 1
R0(config-crypto-map)#set transform-set tset

7-Ezvpn crypto map
R0(config)#crypto map ez_map client configuration address respond
R0(config)#crypto map ez_map isakmp authorization list aaa_author
R0(config)#crypto map ez_map client authentication list aaa_auth
R0(config)#crypto map ez_map 1 ipsec-isakmp dynamic DYNMAP

8-Apply crypto map to interface
R0(config)#int f0/0
R0(config-if)#crypto map ez_map
R0(config-if)#
*Mar  1 00:44:58.403: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON

As soon as you apply the crypto map you should see ISAKMP turning on (assuming you didn't have it on before). Now that the hard part is done let's move on to the client configuration.

Client config
1-IPsec client configuration
R1(config)#crypto ipsec client ezvpn remote_ez
R1(config-crypto-ezvpn)#group MYGROUP key cisco
R1(config-crypto-ezvpn)#peer 192.168.1.200
R1(config-crypto-ezvpn)#mode client
R1(config-crypto-ezvpn)#exit

2-Assign interfaces as inside and outside
R1(config)#int f0/0

R1(config-if)#crypto ipsec client ezvpn remote_ez outsideR1(config)#exit
R1(config)#int f1/0
R1(config-if)#crypto ipsec client ezvpn remote_ez inside
*Mar  1 00:46:55.919: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON

And soon enough you should get a message like this: 


*Mar  1 00:49:59.723: %CRYPTO-5-SESSION_STATUS: Crypto tunnel is UP  .  Peer 192.168.1.200:500       Id: 192.168.1.200

To check if everything is ok:
R1#sh crypto ipsec client ezvpn
Easy VPN Remote Phase: 2

Tunnel name : remote_ez
Inside interface list: FastEthernet1/0,
Outside interface: FastEthernet0/0
Current State: IPSEC_ACTIVE
Last Event: SOCKET_UP
Address: 4.4.4.1
Mask: 255.255.255.255
Split Tunnel List: 1
       Address    : 2.2.2.0
       Mask       : 255.255.255.0
       Protocol   : 0x0
       Source Port: 0
       Dest Port  : 0


Looking good so far, now to check if the split tunneling is working ping for R3 to R2, and then to R0's outside interface, if all is well the first ping should be encrypted and the second pass in cleartext:

R3#ping 2.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/44/120 ms
R3#ping 192.168.1.200

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.200, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/40/68 ms

Looking at a capture taken between R0 and R1:

Everything is working as expected :-)

DMVPN Hub and Spoke with EIGRP routing

In this minilab (microlab) I'll pick up where we left on the DMVPN Hub and Spoke minilab. We'll be adding EIGRP routing to the configuration so the private networks become reachable.
Here's a breakdown of the tasks necessary to configure DMVPN in each router:

1. Configure the EIGRP routing process on the spokes
2. Configure the EIGRP routing process on the HUB

1-Configuring EIGRP on the spokes

2-Configuring EIGRP on the hub

Now lets look at the routing tables on the hub:

Looking good.. now let's look at the spokes:

We're not receiving the routes for the other spokes, to receive these routes we need to disable split-horizon on the tunnel interface of the hub:

Another look at the spoke's routing tables:

Better.. we're now getting the route for the other spokes, but with this routing table will force the traffic between the private networks of the two spokes to go through the hub, to fix this we must issue the no ip next-hop-self command for the eigrp process on the tunnel interface of the hub:

Another look at the spoke's routing tables:

Finally we have the routes for the other spoke's private networks with the next hop at the other spoke's tunnel interface.


And we're done!!

DMVPN Hub and Spoke

Here´s a simple lab to set up a DMVPN scenario, we have two spokes (R2 and R3) and one hub (R1). R4 is simply there to simulate a "network" cloud". We will be using DMVPN phase 2 to permit the dynamic creation of spoke to spoke tunnels. Here's our topology:

In this the goal is to set up DMVPN. To simulate private networks we'll set up loopback interface's on each of the routers (R1 through R3) with addresses in the format 11.11.11.11, 22.22.22.22, etc.
Begin by setting up basic connectivity, R4 interface's should be the default gateway for other routers.


Here's a breakdown of the tasks necessary to configure DMVPN in each router:

1. Configure ISAKMP policy and keys
2. Configure IPsec transform-set and profile
3. Configure the tunnel interface:



1. IP address
2. Tunnel source, mode and key
3. NHRP authentication, mappings, network-id
4. Tunnel protection



4. Test!

We'll begin with the DMVPN configuration without EIGRP, and then add EIGRP routing over the tunnel. I'll be posting the configs for the hub and one of the spokes (R2), the other spoke's configuration is identical.

1-ISAKMP

Hub and Spoke:

2-IPsec

Hub and Spoke:

So far the only thing that you don't have in a simple ipsec tunnel is the ipsec profile.

3-Tunnel interface

3.1 and 3.2- IP, tunnel mode and source  

Hub and Spoke:

On the spoke the ip address should be 10.0.0.2 instead of 10.0.0.1. By not using a tunnel destination and defining the tunnel mode as gre multipoint on the spoke router we are implicitly using DMVPN Phase 2, whereas if we used a tunnel destination on the spoke we would be using DMVPN Phase 1, thus making all spoke-to-spoke traffic traverse the hub router.

3.3-NHRP

Hub:

Spoke:

And finally the configurations differ, on the spoke router we manually map the ip of tunnel interface of R1 to the physical interface of R1, and map multicast traffic to be directed to R1's physical interface, and define our next hop server as R1's tunnel interface.

On the hub side we simply say that multicast mapping is dynamic.

3.4-Tunnel protection

Hub and Spoke:

When you apply the tunnel protection command ISAKMP should become ON (if you weren't allready using it for something else).

4-Test!

You should see the nhrp mappings on the spoke and hub (show ip nhrp) and the DMVPN peers (show dmvpn), to make sure everything is working ping R1's tunnel interface from R2:

Bringing up R3 and configuring it identically, you should be able to ping it from the other spoke, and you should see that the two spokes form an adjacency ( sh adjacency detail ).

And we're done, on my next post we'll add routing and more to this scenario.

IPsec VTI

IPsec virtual tunnel interfaces provide a routable interface to terminate IPsec tunnels, also allowing the encryption of multicast traffic. One of the main advantages of using IPsec VTI interfaces is that you don't need to statically map the IPsec session to a particular interface (no crypto map is required), thus allowing the encrypted traffic to be sent and received through any physical interface. Another adavange is that there is no need to configure symmetrical ACLs on the end points of the IPsec tunnel to define "interesting" traffic, in IPsec VTI the routing engine is used as a trigger mechanism.


In this minilab we'll configure a static VTI tunnel between two routers, R1 and R3. I'll show the configuration steps on R1, the config on R3 is symmetrical.

Here's a breakdown of the tasks we have to do in order to acomplish this (basic connectivity is assumed to be configured):

1-Define ISAKMP policy and pre-shared key.

2-Define the IPsec transform-set

3-Create an IPsec profile

4-Create the tunnel interface and configure it accordingly

5-Test!

1-ISAKMP
R1(config)#crypto isakmp key 0 key address 23.23.23.3
R1(config)#crypto  isakmp policy 10
R1(config-isakmp)#group 2
R1(config-isakmp)#lifetime 3600
R1(config-isakmp)#encryption des
R1(config-isakmp)#hash md5
R1(config-isakmp)#authentication pre-share


2-IPsec transform set
R1(config)#crypto ipsec transform-set SET esp-des esp-sha-hmac
R1(cfg-crypto-trans)#mode transport


3-IPsec profile
R1(config)#crypto ipsec profile VTI
R1(ipsec-profile)#set transform-set SET


4-Tunnel interface
R1(config)#int tunnel 0
R1(config-if)#ip address 13.13.13.1 255.255.255.0
R1(config-if)#tunnel source fastEthernet 1/0
R1(config-if)#tunnel destination 23.23.23.3
R1(config-if)#tunnel mode ipsec ipv4
R1(config-if)#tunnel protection ipsec profile VTI


5-Route
R1(config)#ip route 3.3.3.0 255.255.255.0 tunnel 0


6-Test

R1#ping 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms

Notice there's no need to define the source of the ping, as would be in a classic IPsec tunnel where only the traffic between the private networks.

GRE over IPsec between two routers

Here´s a simple lab to set up a LAN-to-LAN IPsec tunnel. The "LANs" we'll be connecting are two loopback interfaces on R1 and R3, 1.1.1.1/24 and 3.3.3.3/24. Here's our topology:

For this lab we'll be running EIGRP on routers 1 and 3 with AS 13. The GRE tunnel will be established between two loopbacks in R1 and R3, with addresses 1.1.1.1 and 3.3.3.3.
We'll create one more loopback in each of the routers R1 and R3 to simulate local networks routed via GRE, the addresses for these will be 11.11.11.0/24 in R1 and 33.33.33.0/24 in R3.


If we wanted to be able to use the GRE tunnel without IPsec we would need R2 to have routes to these loopbacks, in this case we won't do that so the GRE tunnel will only work once the IPsec tunnel is established.



Here's a breakdown of the tasks we have to do in order to acomplish this:
1-Create the loopbacks and get basic connectivity
2-Create the GRE tunnel
3-Setup EIGRP
4-Define ISAKMP policy and pre-shared key.
5-Define the IPsec transform-set
6-Create an ACL for our "interesting" traffic.
7-Create a crypto map
8-Apply the crypto map to an interface.
9-Test!

1-Basic connectivity
R1 and R3 should have a default route with next hop in R2, don't create any routes in R2 it will only know directly connected networks. From R1 you should be able to ping 23.23.23.3 but not 3.3.3.3


2-GRE tunnel
R1(config)#interface tunnel 1
R1(config-if)#ip address 13.13.13.1 255.255.255.0
R1(config-if)#tunnel source loopback 0
R1(config-if)#tunnel destination 3.3.3.3


3-EIGRP
R1(config)#router eigrp 13
R1(config-router)#network 1.1.1.0 0.0.0.255
R1(config-router)#network 13.13.13.0 0.0.0.255
R1(config-router)#network 11.11.11.0 0.0.0.255


4-ISAKMP
R1(config)#crypto isakmp policy 10
R1(config-isakmp)#authentication pre-share
R1(config-isakmp)#encryption des
R1(config-isakmp)#lifetime 3600
R1(config-isakmp)#group 2
R1(config-isakmp)#hash md5
!
R1(config)#crypto isakmp key 0 key address 23.23.23.3


5-IPsec
R1(config)#crypto ipsec transform-set SET esp-3des ah-sha-hmac
R1(cfg-crypto-trans)#mode tunnel


6-ACL
R1(config)#ip access-list extended 103
R1(config-ext-nacl)#10 permit gre host 1.1.1.1 host 3.3.3.3


7-Crypto map
R1(config)#crypto map MAP 10 ipsec-isakmp
R1(config-crypto-map)#set transform-set SET
R1(config-crypto-map)#set peer 23.23.23.3
R1(config-crypto-map)#match address 103


8-Apply the crypto map to the interface
R1(config)#int fa1/0
R1(config-if)#crypto map MAP


9-Test the configuration!
When you apply the crypto map to both routers you should see an EIGRP adjacency being formed, all good so far, but after a while you should see flapping on the Tunnel interface:
*Feb  2 15:32:29.163: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 13: Neighbor 13.13.13.3 (Tunnel1) is up: new adjacency
*Feb  2 15:32:38.023: %TUN-5-RECURDOWN: Tunnel1 temporarily disabled due to recursive routing
*Feb  2 15:32:39.023: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down
*Feb  2 15:32:39.063: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 13: Neighbor 13.13.13.3 (Tunnel1) is down: interface down
*Feb  2 15:33:39.023: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
*Feb  2 15:33:41.699: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 13: Neighbor 13.13.13.3 (Tunnel1) is up: new adjacency
*Feb  2 15:33:48.023: %TUN-5-RECURDOWN: Tunnel1 temporarily disabled due to recursive routing
*Feb  2 15:33:49.023: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down
*Feb  2 15:33:49.063: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 13: Neighbor 13.13.13.3 (Tunnel1) is down: interface down

This behaviour is caused by EIGRP route pointing the tunnel's network to be reachable with the Tunnel interface as the next hop for that network, so whenever the router tries to send a packet to tunnel termination on the other router this happens:
The packet is queued in the output queue of the tunnel interface
The tunnel interface adds a GRE header to the packet and queues the packet to the transport protocol destined to the destination address of the tunnel interface.
IP looks up the route to the destination address and learns that it is through the tunnel interface, which returns the packet to Step 1 above; hence, there is a recursive routing loop.
(taken from  http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094690.shtml )
In this configuration there are two ways to solve this problem, one is to remove the loopbacks that are forming the tunnel from the eigrp routing process.The other solution is to manually add a more specific static route for the tunnel destination, with the next hop on our outbound interface (where we have the crypto map applied). So add it in:
R1(config)#ip route 3.3.3.3 255.255.255.255 FastEthernet 1/0
Now the router should have stopped the recursive routing, and you should get a stable tunnel, hte routing table should look something like this:
Gateway of last resort is 12.12.12.2 to network 0.0.0.0

     1.0.0.0/24 is subnetted, 1 subnets
C       1.1.1.0 is directly connected, Loopback0
     33.0.0.0/24 is subnetted, 1 subnets
D       33.33.33.0 [90/297372416] via 13.13.13.3, 00:02:43, Tunnel1
     3.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
S       3.3.3.3/32 is directly connected, FastEthernet1/0
D       3.3.3.0/24 [90/297372416] via 13.13.13.3, 00:02:43, Tunnel1
     11.0.0.0/24 is subnetted, 1 subnets
C       11.11.11.0 is directly connected, Loopback1
     12.0.0.0/24 is subnetted, 1 subnets
C       12.12.12.0 is directly connected, FastEthernet1/0
     13.0.0.0/24 is subnetted, 1 subnets
C       13.13.13.0 is directly connected, Tunnel1
S*   0.0.0.0/0 [1/0] via 12.12.12.2

And we're done, you should have connectivity between the local networks.

Basic LAN to LAN IPsec tunnel between two routers

Here´s a simple lab to set up a LAN-to-LAN IPsec tunnel. The "LANs" we'll be connecting are two loopback interfaces on R1 and R3, 1.1.1.1/24 and 3.3.3.3/24. Here's our topology:

Here's a breakdown of the tasks we have to do in order to acomplish this:
1-Define ISAKMP policy and pre-shared key.
2-Define the IPsec transform-set
3-Create an ACL for our "interesting" traffic.
4-Create a crypto map
5-Apply the crypto map to an interface.
6-Test!

When configuring IPsec it´s a good idea to create the configuration in notepad, so you can then copy and paste into the devices as required. The configuration steps below are for R1, for R3 they are exactly the same except for the peer address and the ACL will be an exact mirror of the one on R1. The commands are entered in config mode.

1-ISAKMP policy
crypto isakmp key 0 key address 23.23.23.3

crypto isakmp policy 10
authentication pre-share
encryption des
hash sha
group 2
lifetime 3600

2-IPsec transform set
crypto ipsec transform-set TS esp-seal esp-sha-hmac
mode tunnel

3-ACL
access-list 103 permit ip 1.1.1.0 0.0.0.255 3.3.3.0  0.0.0.255

4-Crypto map
crypto map CMAP 10 ipsec-isakmp
set transform-set TS
set peer 23.23.23.3
match address 103

5-Apply crypto map
R1(config)#int FastEthernet 1/0R1(config-if)#crypto map CMAP

6-Test the configuration!
To establish IPsec tunnel there must be interesting traffic, in this case we'll ping from 1.1.1.1 to 3.3.3.3, i'll have R3 with isakmp and IPsec debugging. The result should look like this in R1:

R1#ping 3.3.3.3 source loopback 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 92/100/108 ms


In R3 you should see the negotiation and the SAs being created.

Auth-proxy on Cisco IOS

Here´s a simple lab to test a simple auth-proxy configuration on IOS.
The goal of this lab is to get auth-proxy configured on R1, so that when the client tries to establish a http session to the web-server (10.0.0.111 which also happens to be the AAA/ACS server in my scenario) he will have to authenticate to access the server (as per CCIE security LAB i won't be covering basic connectivity configs).

Here's a breakdown of the tasks we have to do in order to acomplish this:
1- Configure AAA on the router, and make the required configurations on the ACS
2- Configure http server on the router
3- Configure auth-proxy
4- Apply auth proxy to the interface

Now let's go about it point by point:

1- AAA

For auth-proxy to work the router must get a auth-proxy ACL from to the ACS server, for this to work using ACS and TACACS+ you will have to configure the TACACS+ interface and add a new service to it as shown in the picture below:

After you configured the interface, you must configure the group that you will using for auth-proxy with custom-attributes for auth-proxy, the attributes are actually the ACL that the router will receive upon sucessfull authentication of a user for the auth-proxy service:
Now that we've configured the ACS side (i'm skipping the basics like configuring clients and key, and users), let´s move on to the router.
R1(config)# aaa new-model R1(config)# tacacs-server host 10.0.0.111 key 1234 R1(config)# aaa authentication login default group tacacs+

Take care not to lock yourself out :-)

2- Configure http server on the router

R1(config)# ip http server R1(config)# ip http authentication aaa R1(config)# ip http access-class 10

In my case i just configured ACL 10 to allow any host.

3- Configure auth-proxy

R1(config)# ip auth-proxy auth-cache-time 2 R1(config)# ip auth-proxy name teste_auth http

I set the innactivity timer to 2 minutes.
4- Apply auth proxy to the interface

R1(config)# int fastEthernet 1/0
R1(config-if)# ip auth-proxy teste_auth

And now let's test it:



And we're done!

For more resources on auth proxy look at:
http://www.cisco.com/en/US/docs/ios/12_0t/12_0t5/feature/guide/iosfw2_1.html
http://www.wr-mem.com/?p=111

Cisco IOS firewall CBAC

From Cisco's IOS Security Configuration Guide:
"CBAC creates temporary openings in access lists at firewall interfaces. These openings are created when specified traffic exits your internal network through the firewall. The openings allow returning traffic (that would normally be blocked) and additional data channels to enter your internal network back through the firewall. The traffic is allowed back through the firewall only if it is part of the same session as the original traffic that triggered CBAC when exiting through the firewall. "
This is a simple example that you can build on:


For this example i'll apply the ACL and the inspection on the outside interface to allow telnet from R1 to R3 and deny all other TCP or UDP traffic, ICMP will be allowed in the ACL for connectivity testing purposes.

After the basic connectivity and routing is set up we need to set up the ACL to apply inbound on the outside interface of R2, which will look something like this:

R2(config)#ip access-list extended OUTSIDE_in
R2(config-ext-nacl)#10000 deny ip any any
R2(config-ext-nacl)#10 permit icmp any any echo-reply
R2(config-ext-nacl)#20 permit icmp any any time-exceeded
R2(config-ext-nacl)#30 permit icmp any any packet-too-big
R2(config-ext-nacl)#40 permit icmp any any unreachable

And apply it inbound on the outside interface:

R2(config)#int fa1/1
R2(config-if)#ip access-group OUTSIDE_in in

Now testing the connectivity pings from R1 to 10.0.0.3 (R3) should go through, but not from R3 to R1, and telnet from R1 to R3 should not be working. To get telnet working we need to configure our inspect rule and apply it:

R2(config)#ip inspect name OUTSIDE_inspect telnet

And apply it outbound on the outside interface:

R2(config)#int fa1/1
R2(config-if)#ip inspect OUTSIDE_inspect out

Now telnet should be working and by using the debug commands "debug ip inspect object-creation" and "debug ip inspect object-deletion" the temporary objects to permit telnet traffic should show something like this on the routers output (R2):

Jan 23 19:00:56.531: CBAC* OBJ_CREATE: Pak 65728BAC sis 65CCA99C initiator_addr (192.168.1.1:42057) responder_addr (10.0.0.3:23) initiator_alt_addr (192.168.1.1:42057) responder_alt_addr (10.0.0.3:23)
Jan 23 19:00:56.531: CBAC OBJ-CREATE: sid 660F56F4 acl OUTSIDE_in Prot: tcp
Jan 23 19:00:56.535: Src 10.0.0.3 Port [23:23]
Jan 23 19:00:56.535: Dst 192.168.1.1 Port [42057:42057]
Jan 23 19:00:56.535: CBAC OBJ_CREATE: create host entry 660E5690 addr 10.0.0.3 bucket 9 (vrf 0:0) insp_cb 0x66435074
Jan 23 19:00:56.767: CBAC OBJ_DELETE: delete host entry 660E5690 addr 10.0.0.3
R2#
Jan 23 19:01:04.959: CBAC OBJ_DELETE: delete sis 65CCA99C
Jan 23 19:01:04.959: CBAC OBJ-DELETE: sid 660F56F4 on acl OUTSIDE_in Prot: tcp
Jan 23 19:01:04.959: Src 10.0.0.3 Port [23:23]
Jan 23 19:01:04.959: Dst 192.168.1.1 Port [42057:42057]

more info @ http://www.cisco.com/en/US/docs/ios/sec_data_plane/configuration/guide/sec_cfg_content_ac_ps6441_TSD_Products_Configuration_Guide_Chapter.html