Steps for configuring the branch office model: Part 1 (host-to-gateway with IPSec)

The branch office model part 1 consists of two networks whose IP connectivity relies on the Internet. The server is protecting traffic that originates from hosts outside the internal network, which at some point is routed over the Internet.

Before you begin

The following topics are covered in the discussion of this model:

• Host-to-gateway
• Gateway-to-gateway
• Autoactivation
• Command-line activation
• Using wildcards for location and identity
• Pre-shared key peer authentication

Figure 1 shows the branch office portion of the security model network.

Figure 1. Branch office model

Transport-mode IPSec is used exclusively for transporting encrypted data directly between two hosts. Tunnel-mode IPSec encapsulation must be used if one of the security endpoints is a security gateway routing traffic for any number of hosts. In the branch office model, there can be multiple hosts behind a security gateway that is providing the security mechanism for all hosts that are behind the security gateway. The base assumption is that the local secure server represents a single data endpoint and a single security endpoint, whereas the remote subnetwork represents multiple data endpoints which share a common security endpoint, namely the security gateway host. Traffic from the local server to the branch office gateway is IPSec protected, while traffic from the branch office gateway to the hosts behind the security gateway need not be encrypted or even filtered.

As in the previous models, a complete IP security policy defines the traffic that is allowed between the local server and the zone representing the branch office. However, the difference lies primarily in where the remote security endpoint is situated. In the previous examples, all of the IPSec protection was provided on a host-to-host basis. Each set of communicating endpoints had a single dynamic VPN that represented a secure channel of communication between two hosts, local and remote. In contrast, any scenario that involves an IPSec security gateway can require that one VPN carry traffic for multiple hosts. This difference is highlighted in this branch office example.

For this example, assume the following requirements to allow network communications from zone C, a branch office network (9.6.0.0/16), to a public IP address (9.3.3.3) on this host. The hosts on the branch office network connect to the Internet through the public branch office gateway server (9.5.5.5).

• Allow IKE traffic from branch office zone C to this host.
• Allow EE traffic from branch office zone C to an EE service running on this host, using a dynamic VPN with strong authentication and encryption. The VPN should be up when the stack initializes.
• Allow normal FTP traffic from branch office zone C to an FTP server running on this host, using a dynamic VPN with strong authentication and encryption. The VPN is command-line activated. Only one VPN should be established to carry all FTP traffic. There will not be one VPN per connection, but rather one Security Association will be negotiated for all of the remote FTP clients.
  Restriction: Negotiating a single Security Association for multiple remote clients is possible only when the remote security endpoint is acting as a secure gateway.
• Peers authenticate themselves using the pre-shared key method.

Perform the following steps to meet these requirements and configure part 1 of the branch office model.

1. Determine the number of zones to be protected. The branch office represents one zone, zone C.
2. For each zone, determine what services are allowed and define an IpService block for each wanted service. Services are defined by their protocols and the well-known ports they use.

   The definitions that describe FTP traffic can be combined in an IP service group as follows:

   IpServiceGroup               FTPServer
   {
     IpService                  FTPServer-Control
     {
       SourcePortRange            21
       Protocol                   tcp
       Direction                  bidirectional InboundConnect
       Routing                    local
       SecurityClass              0        		
     }
     IpService                  FTPServer-Data
     {
       SourcePortRange            20
       Protocol                   tcp
       Direction                  bidirectional OutboundConnect
       Routing                    local
       SecurityClass              0
     }
     IpService                  FTPServer-Data-Passive
     {
       SourcePortRange            50000 50200
       Protocol                   tcp
       Direction                  bidirectional InboundConnect
       Routing                    local
       SecurityClass              0
     }
   }

   The traffic pattern for Enterprise Extender can be defined in one IpService block as follows:

   IpService                    Enterprise-Extender
   {
     SourcePortRange            12000 12004
     DestinationPortRange       12000 12004
     Protocol                   udp
     Direction                  bidirectional
     Routing                    local
     SecurityClass              0
   }

3. Determine the data endpoints to be protected. Typically, this is both a local and remote IP address or subnetwork.

   In this example, for the local host public IP address, 9.3.3.3, define the following statement:

   IpAddr                       PublicServerAddressA1
   {
     Addr                       9.3.3.3
   }

   For the remote subnet, 9.6.0.0/16, the following statement is defined:

   IpAddrSet                    SubnetC
   {
     Prefix                     9.6.0.0/16
   }

   Because it is necessary to permit IKE traffic between the local public server and the remote branch office gateway, the IP address of the remote gateway must also be defined as follows:

   IpAddr                       BranchOfficeGateway
   {
     Addr                       9.5.5.5
   }

4. Determine what level of security is needed between each set of data endpoints. In this example, strong authentication and encryption is needed for both EE and FTP traffic, so ESP authentication and ESP encryption are used.
5. Configure an IpGenericFilterAction statement for the level of security that is required (permit, deny, ipsec), including whether the connection should be logged, as follows:

   IpGenericFilterAction        ipsec
   {
     IpFilterAction             ipsec
   }

6. If IPSec is required between any two endpoints, take the following actions:
   1. Configure a key exchange policy that defines the parameters of the phase 1 negotiation as follows:
      1. Determine the required type and strength of protection for the phase 1 Security Association.

         In this example, SHA1 authentication is used because it is more secure than MD5, and AES encryption is used because it is stronger than DES and equivalent to 3DES. Diffie-Hellman Group5 and Group14 are considered strong enough to generate keying material for AES using a 128 bit key. Group14 is used in this example..

      2. Decide what type of peer authentication to use.

         In this example, pre-shared key authentication is specified in the requirements. Typically, the RSA signature method is preferable, given its numerous advantages, but for the purposes of example the pre-shared key method is used here. Because there is only one remote IKE peer in the branch office scenario (the remote security gateway), and because it is relatively simple to configure, pre-shared key authentication is a reasonable choice.

      3. Configure a KeyExchangeOffer statement that defines the parameters for the phase 1 negotiation as follows:

         KeyExchangeOffer             SHA1-AES-PSK
         {
           HowToEncrypt               AES_CBC KeyLength 128
           HowToAuthMsgs              SHA1
           HowToAuthPeers             PresharedKey
           DHGroup                    Group14
         }

      4. Decide whether NAT traversal will be allowed.

         In this example, the following parameter is used:

         AllowNat No

      5. Determine the negotiation mode, Main or Aggressive.

         Because security is a priority in the branch office model, the more secure Main mode is used for the phase 1 negotiation.

      6. Configure a KeyExchangeAction statement as follows:

         KeyExchangeAction            Gold-PSK
         {
           HowToInitiate              main
           HowToRespondIKEv1          main
           KeyExchangeOfferRef        SHA1-AES-PSK
         }

      7. Configure a LocalSecurityEndpoint statement and RemoteSecurityEndpoint statement as follows:

         LocalSecurityEndpoint        Public_IKED
         {
           Identity                   IpAddr 9.3.3.3
           LocationRef                PublicServerAddressA1
         }
         
         RemoteSecurityEndpoint       ZoneC_IKED
         {
           Identity                   Fqdn gateway.BO.example.com
           LocationRef                BranchOfficeGateway
         }

      8. Configure a KeyExchangeRule statement that includes the two endpoints, the key exchange action, and the pre-shared key as follows:

         KeyExchangeRule              ZoneC_KeyExRule1
         {
           LocalSecurityEndpointRef   Public_IKED
           RemoteSecurityEndpointRef  ZoneC_IKED
           KeyExchangeActionRef       Gold-PSK
           PresharedKey               abracadabra
         }

      9. Include the KeyExchangeRule statement in the KeyExchangePolicy statement block, as follows:

         KeyExchangePolicy
         {
             KeyExchangeRuleRef         ZoneC_KeyExRule1
         }

   2. Configure an IpDynVpnAction statement defining the control of the phase 2 negotiation, as follows:
      1. Determine the required type and strength of IPSec protection for the phase 2 Security Association.

         In this example, authentication is ESP HMAC_SHA1 and encryption is AES.

      2. Determine whether tunnel or transport mode is required.

         Tunnel mode is required when one of the security endpoints is a security gateway.

      3. Configure an IpDataOffer statement that defines the parameters of the phase 2 negotiation, as follows:

         IpDataOffer                  SHA-AES-Tunnel
         {
           HowToEncap                 tunnel
           HowToEncrypt               AES_CBC KeyLength 128
           HowToAuth                  ESP HMAC_SHA1
         }

      4. Determine which peer is allowed to initiate the negotiation.

         Because the EE VPN is up when the stack starts, you need to be able to start the negotiation locally (that is, autoactivate it). The FTP VPN is command-line activated, so you need to be able to start the negotiation locally.

      5. Configure an IpDynVpnAction statement that defines the control information for the phase 2 negotiation, as follows:

         IpDynVpnAction               Gold-TunnelMode
         {
           Initiation                 either
           InitiateWithPfs            group2
           AcceptablePfs              group2
           IpDataOfferRef             SHA-AES-Tunnel
         }

   3. Decide how the Security Association is activated.
      1. Optionally, configure a local dynamic VPN policy, if command-line activated or autoactivated.

         A LocalDynVpnRule statement is required for each Security Association because none are on-demand activated, five for the EE traffic and two for the FTP traffic, as follows:

         LocalDynVpnRule              ZoneC_VPN-EE1
         {
            LocalIpRef                 PublicServerAddressA1
            RemoteIpSetRef             SubnetC
            LocalDataPort              12000
            RemoteDataPort             12000
            Protocol                   UDP
            AutoActivate               Yes
         }
         
         LocalDynVpnRule              ZoneC_VPN-EE2
         {
            LocalIpRef                 PublicServerAddressA1
            RemoteIpSetRef             SubnetC
            LocalDataPort              12001
            RemoteDataPort             12001
            Protocol                   UDP
            AutoActivate               Yes
         }
         
         LocalDynVpnRule              ZoneC_VPN-EE3
         {
            LocalIpRef                 PublicServerAddressA1
            RemoteIpSetRef             SubnetC
            LocalDataPort              12002
            RemoteDataPort             12002
            Protocol                   UDP
            AutoActivate               Yes
         }
         
         LocalDynVpnRule              ZoneC_VPN-EE4
         {
            LocalIpRef                 PublicServerAddressA1
            RemoteIpSetRef             SubnetC
            LocalDataPort              12003
            RemoteDataPort             12003
            Protocol                   UDP
            AutoActivate               Yes
         }
         
         LocalDynVpnRule              ZoneC_VPN-EE5
         {
            LocalIpRef                 PublicServerAddressA1
            RemoteIpSetRef             SubnetC
            LocalDataPort              12004
            RemoteDataPort             12004
            Protocol                   UDP
            AutoActivate               Yes
         }
         
         LocalDynVpnRule              ZoneC_VPN-FTP-Data
         {
            LocalIpRef                 PublicServerAddressA1
            RemoteIpSetRef             SubnetC
            LocalDataPort              20
            RemoteDataPort             0
            Protocol                   TCP
            AutoActivate               Yes
         }
         
         LocalDynVpnRule              ZoneC_VPN-FTP-Control
         {
            LocalIpRef                 PublicServerAddressA1
            RemoteIpSetRef             SubnetC
            LocalDataPort              21
            RemoteDataPort             0
            Protocol                   TCP
            AutoActivate               Yes
         }

      2. Configure an optional IpLocalStartAction statement, if the Security Association is to be activated locally (that is, on-demand, command-line, or autoactivation) and one of the security endpoints is acting as a security gateway (that is, not a host-to-host Security Association). Include a reference to the IpLocalStartAction statement in the IP filter rule.

         If the local secure server initiates an IKE negotiation, it must be able to identify a remote IKE peer. However, in this case, the remote data endpoint is not a single host, but multiple endpoints in a subnetwork, ZoneC. The IpLocalStartAction statement is used to identify the remote IKE peer, and is required if the local IKE daemon initiates an ipsec connection with a remote security gateway.

         IpLocalStartAction             StartZoneC
         {
            RemoteSecurityEndpointRef   ZoneC_IKED
         }

      3. Create an IpFilterRule statement that allows IPSec traffic (AH and ESP), or set the global IpFilterPolicy statement parameter PreDecap to off.

         In this example, PreDecap off is used in the IpFilterPolicy statement.

7. Define an IpFilterRule statement for each set of data endpoints. The rule should include the services that are allowed (one IpService statement for each allowed service), and the level of security that is required (a reference to the IpGenericFilterAction statement). If IPSec is required, create an IpFilterRule statement that allows IKE traffic (UDP, port 500). If NAT traversal is allowed, create an IpFilterRule statement that allows IKE UDP traffic on port 4500. See the IpAddr and IpAddrSet statements configured in step 3.

   IpFilterRule                 Rule1C
   {
      IpSourceAddrRef            PublicServerAddressA1
      IpDestAddrRef              BranchOfficeGateway
      IpServiceRef               IKE
      IpGenericFilterActionRef   permit
   }
   
   IpFilterRule                 Rule2C
   {
      IpSourceAddrRef            PublicServerAddressA1
      IpDestAddrSetRef           SubnetC
      IpServiceRef               Enterprise-Extender
      IpServiceGroupRef          FTPServer
      IpGenericFilterActionRef   ipsec
      IpDynVpnActionRef          Gold-TunnelMode
      IpLocalStartActionRef      StartZoneC
   }

8. Define an IpFilterGroup statement for each zone and include the IpFilterRule statements that belong to that zone.
9. Include all IpFilterGroup references and, optionally, any additional IpFilterRule statements as needed, in the IpFilterPolicy block.
10. Include all configured statements in the stack-specific IP security configuration file.

#-------------------------------------------------------
# Filter Policy for Secure Server
#-------------------------------------------------------
IpFilterPolicy
{
  PreDecap                   off
  FilterLogging              on
  AllowOnDemand              no
  IpFilterGroupRef           ZoneC
}

#-------------------------------------------------------
# KeyExchange Policy for Secure Server
#-------------------------------------------------------
KeyExchangePolicy
{
  KeyExchangeRuleRef         ZoneC_KeyExRule1
}

#-------------------------------------------------------
# LocalDynVpn Policy for Secure Server
#-------------------------------------------------------
LocalDynVpnPolicy
{
  LocalDynVpnGroupRef        ZoneC_BranchOfficeVPNs
}

########################################################
#               Connectivity Profile
#              Secure Server To Zone C
#
#   Server to Trusted Branch Office Network
#
########################################################
IpFilterGroup                ZoneC
{
   #-------------------------------------------------------
   # Permitted Zone C traffic:
   #    Allow IKE traffic from the gateway IKE Server
   #    for branch office to this host.
   #
   #    IKE  (UDP port 500) - IKE negotiations
   #-------------------------------------------------------

   IpFilterRule                 Rule1C
   {
     IpSourceAddrRef            PublicServerAddressA1
     IpDestAddrRef              BranchOfficeGateway
     IpServiceRef               IKE
     IpGenericFilterActionRef   permit
   }

   #-------------------------------------------------------
   # IPSec-protected Zone C traffic:
   #
   # Enterprise Extender (ports 12000-12004)
   #    FTP Server - SubnetC to PublicServerAddressA
   #-------------------------------------------------------

   IpFilterRule                 Rule2C
   {
     IpSourceAddrRef            PublicServerAddressA1
     IpDestAddrSetRef           SubnetC
     IpServiceRef               Enterprise-Extender
     IpServiceGroupRef          FTPServer
     IpGenericFilterActionRef   ipsec
     IpDynVpnActionRef          Gold-TunnelMode
     IpLocalStartActionRef      StartZoneC
   }
}

IpLocalStartAction             StartZoneC
{
   AllowOnDemand               yes
   RemoteSecurityEndpointRef   ZoneC_IKED
}

KeyExchangeRule              ZoneC_KeyExRule1
{
  LocalSecurityEndpointRef   Public_IKED
  RemoteSecurityEndpointRef  ZoneC_IKED
  KeyExchangeActionRef       Gold-PSK
}

#--------------------------------------------------------
# Zone C LocalDynVpnRules
#
# Setup SAs for EE traffic from branch office zone C to
# EE (UDP ports 12000-12004).
#--------------------------------------------------------

LocalDynVpnGroup             ZoneC_BranchOfficeVPNs
{
   LocalDynVpnRule              ZoneC_VPN-EE1
   {
     LocalIpRef                 PublicServerAddressA1
     RemoteIpSetRef             SubnetC
     LocalDataPort              12000
     RemoteDataPort             12000
     Protocol                   UDP
     AutoActivate               Yes
   }

   LocalDynVpnRule              ZoneC_VPN-EE2
   {
     LocalIpRef                 PublicServerAddressA1
     RemoteIpSetRef             SubnetC
     LocalDataPort              12001
     RemoteDataPort             12001
     Protocol                   UDP
     AutoActivate               Yes
   }

   LocalDynVpnRule              ZoneC_VPN-EE3
   {
     LocalIpRef                 PublicServerAddressA1
     RemoteIpSetRef             SubnetC
     LocalDataPort              12002
     RemoteDataPort             12002
     Protocol                   UDP
     AutoActivate               Yes
   }

   LocalDynVpnRule              ZoneC_VPN-EE4
   {
     LocalIpRef                 PublicServerAddressA1
     RemoteIpSetRef             SubnetC
     LocalDataPort              12003
     RemoteDataPort             12003
     Protocol                   UDP
     AutoActivate               Yes
   }

   LocalDynVpnRule              ZoneC_VPN-EE5
   {
     LocalIpRef                 PublicServerAddressA1
     RemoteIpSetRef             SubnetC
     LocalDataPort              12004
     RemoteDataPort             12004
     Protocol                   UDP
     AutoActivate               Yes
   }

#-------------------------------------------------------
# Setup SAs for FTP traffic from branch office zone C
# to an FTP server running on this host using a dynamic
# vpn (TCP port 20, 21).
#-------------------------------------------------------

   LocalDynVpnRule              ZoneC_VPN-FTP-Data
   {
     LocalIpRef                 PublicServerAddressA1
     RemoteIpSetRef             SubnetC
     LocalDataPort              20
     RemoteDataPort             0
     Protocol                   TCP
     AutoActivate               Yes
   }

   LocalDynVpnRule              ZoneC_VPN-FTP-Control
   {
     LocalIpRef                 PublicServerAddressA1
     RemoteIpSetRef             SubnetC
     LocalDataPort              21
     RemoteDataPort             0
     Protocol                   TCP
     AutoActivate               Yes
   }
}