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).
Procedure
Perform the following steps to meet these requirements
and configure part 1 of the branch office model.
- Determine the number of zones to be protected. The
branch office represents one zone, zone C.
- 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
}
- 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
}
- 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.
- 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
}
- If IPSec is required between any two endpoints, take the
following actions:
- Configure a key exchange policy that defines the parameters
of the phase 1 negotiation as follows:
- 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..
- 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.
- 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
}
- Decide whether NAT traversal will be allowed.
In this example,
the following parameter is used:
AllowNat No
- 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.
- Configure a KeyExchangeAction statement as follows:
KeyExchangeAction Gold-PSK
{
HowToInitiate main
HowToRespondIKEv1 main
KeyExchangeOfferRef SHA1-AES-PSK
}
- 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
}
- 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
}
- Include the KeyExchangeRule statement in the KeyExchangePolicy
statement block, as follows:
KeyExchangePolicy
{
KeyExchangeRuleRef ZoneC_KeyExRule1
}
- Configure an IpDynVpnAction statement defining the control
of the phase 2 negotiation, as follows:
- 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.
- Determine whether tunnel or transport mode is required.
Tunnel
mode is required when one of the security endpoints is a security
gateway.
- 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
}
- 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.
- 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
}
- Decide how the Security Association is activated.
- 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
}
- 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
}
- 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.
- 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
}
- Define an IpFilterGroup statement for each zone and include
the IpFilterRule statements that belong to that zone.
- Include all IpFilterGroup references and, optionally, any
additional IpFilterRule statements as needed, in the IpFilterPolicy
block.
- Include all configured statements in the stack-specific
IP security configuration file.
Results
The following policy is a complete IP security policy
for traffic from the local secure server to zone C, assuming that
the reusable statements are included in the common 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
}
}