Note: At this time, the Cisco Integrated Client Firewall (CIC) is
compatible only with a Cisco VPN Client (versions 3.5.x or later) connecting
back to a VPN 3000 Concentrator (versions 3.5.x or later). Cisco Secure PIX
Firewall does not currently support this feature.

When a VPN Client connects back to a headend gateway and there is no
split tunneling allowed, all traffic must flow to the headend. In such an
instance, this client could theoretically be used as a relay agent for some
type of security breach, since the security posture set at the headend controls
what the client can see when requesting resources other than those available on
the private network.

To allow remote clients access to resources on the protected network
while not truly enforcing what Internet resources are available, you can
implement a split tunnel. A split tunnel allows the VPN Client to access the
networks protected by the VPN headend via the VPN tunnel and other resources in
clear data (outside the VPN tunnel) simultaneously. A potential drawback is
that this VPN Client could be a relay agent if someone on the clear data side
compromised the client's workstation and used that workstation to get
information from the VPN-protected networks.

To enforce protection of your internal networks when the remote clients
are using a split tunnel, you can implement a personal CIC firewall on the VPN
Client workstation. A variety of vendors can supply this feature; the examples
in this document use the integrated client included in the VPN Client. Note
that the VPN Client software must be at least version 3.5. The VPN Client with
embedded CIC will accept policies that were defined on the VPN 3000
Concentrator (running at least 3.5.x software) to be pushed down to the client
to enforce the non-VPN traffic activity while the tunnel is up. CIC is
automatically installed along with the VPN Client; no separate steps are
required.

It is important to keep the following points in mind when you use this
document.

Use the Cisco VPN Client 3.5.x or later; the CIC feature is not
available on earlier versions.

There is no end-user configuration on the VPN Client side. Everything
is done on the VPN 3000 Concentrator headend.

This document assumes that you have users and groups configured. The
configuration steps apply only to adding the CIC feature and split
tunneling.

Policies to be pushed to the VPN Client via Cisco Pushed Policy (CPP)
are active only when the tunnel is up. The pushed policies are applied to
unencrypted traffic, so CPP should only be configured when split tunneling is
enabled.

The firewall rules displayed on the VPN Client's statistics screen
are listed in order of precedence.

Because split tunneling is assumed in use, the first firewall rules
displayed are to allow traffic to each of the private networks listed. After
these, the rules pushed by the defined policy are listed.

The VPN 3000 Concentrator automatically appends the drop all
inbound and drop all outbound parameters to the end
of the list of rules.

The information in this document is based on the software and hardware
versions below.

Cisco VPN Client 4.0.2(B) with CIC Firewall integrated

Cisco VPN 3000 Concentrator running 4.0.1.C

The information presented in this document was created from devices in
a specific lab environment. All of the devices used in this document started
with a cleared (default) configuration. If you are working in a live network,
ensure that you understand the potential impact of any command before using
it.

The following steps describe the defining policies and rules for
configuring the VPN 3000 Concentrator.

Define the policy for the non-tunneled traffic. Remember that the
CIC Firewall does not apply to the encrypted traffic. The VPN Client in this
example is connected through VPN and has a policy that includes the following
parameters.

Non-CIC

Access the VPN-protected network resources –
This is allowed by default with the split-tunnel list, as long as there are no
filters defined on the VPN group, user ID, or interface that would prohibit the
flow of traffic. By default, no filters are defined, so all traffic should pass
to the protected network.

CIC

DNS queries – You must add this rule if the
DNS server passed down to the VPN Client is not part of the VPN-protected
network. If you don't add the rule, the clients will not be able to reach sites
via a DNS name; IP addresses will still work.

Web access – The VPN Client can access sites
that are not VPN-protected on HTTP (TCP/80).

Deny everything else.

Once the policy is defined, you need to create rules that reflect
the policy specifications (as defined above). Remember that the filter rules
are bidirectional, so you must create one for both the inbound and outbound
connections. Unless specified below, values should be left on their default
settings.

Repeat the steps above to create a filter rule for the outbound
connection (DNS requests). Use the values shown below to configure this
rule.

Rule Name: DNS-outbound

Direction: outbound

Action: Forward

Protocol: udp

Source Port / Port: Range

Range: 1024 to 65535

Destination Port / Port: DNS
(53)

Click Apply when you have finished entering the
values.

Note: The configurations in steps 1 – 3 above apply only to the DNS
properties. Web HTTP requests are already defined as "outgoing HTTP in" and
"outgoing HTTP out". The rule "outgoing HTTP out" matches all IP packets with
TCP destination port 80 (www) and any source port, while "outgoing HTTP in"
matches all IP packets with TCP source port 80 and any destination port. The
rules "incoming HTTP in" / "incoming HTTP out" match any IP packet with TCP
source port any / 80 and destination port 80 / any, respectively. The name tags
"in" and "out" refer to the directions (inbound and outbound) from the
perspective of the of the VPN Client. If you are unsure, you can take a closer
look at the rules by using the Modify function to check the
source and destination ports.

Give the filter a descriptive name. The following example uses a
filter named "client_fw_rule".

Leave the filter's default action as Drop. If the design calls for
source-routing, check the Source Routing box; to disable fragmentations,
uncheck the Fragments. Click Add when you are
finished.

To add rules to the filter, select the applicable rules from the
"Available" column (on the right) and click Add to move them
to the Current Rules in Filter column (on the left). Click
Done when you are finished.

The example below for the filter named "client_fw_rule" shows four
current rules.

DNS-inbound

Outgoing HTTP In

DNS-outbound

Outgoing HTTP
Out

To apply the filter to the group, go to Configuration >
User Management > Groups. Select the group that you want to modify
and click Modify Group.

On the Client FW tab, select the "Firewall Setting" value of
Firewall Required, and use the pull-down menu to set the
"Firewall" value to Cisco Integrated Client
Firewall.

For the "Firewall Policy" attribute, select Policy Pushed (CPP) and
select <filter_name> from the pull-down menu. The example below shows the
filter "client_fw_rule".

When you are finished, click Apply, then click
Save Needed (in the top right of the
window).

To define the networks that you want to be tunneled, go to
Configuration > Policy Management > Traffic Management >
Network Lists. Click Add, then define a name for the
list and specify what networks are to be included.

Note that the mask is a wild-card mask. To protect the
10.0.0.0/255.0.0.0 network, the inverse mask (required in this network list) is
0.255.255.255.

To apply the network list as a split tunnel, you need to modify the
group that will have the tunnel applied. Go to Configuration > User
Management > Group ><group name>.
Click Modify Group and select the Client Config tab. Under
Split Tunneling Policy, select the option for Only
tunnel networks in list. Under Split Tunneling Network
List, select the network list you defined earlier; in this example,
the list is called VPN_Protected_Network.

This section provides information you can use to confirm your
configuration is working properly.

To verify that the configuration was successful, you can check the
Firewall settings in the VPN Client Connection Status window.

Open the VPN Client Connection Status window and click on the Firewall
tab to display the pushed policy. Remember that the policy is read from top to
bottom and should have bidirectional definitions—one for the outbound
connection and one for the inbound connection. The example below shows the
outbound flow of DNS (port 53 protocol 17) sourcing from a random high port of
the VPN Client.

Note: If there is no Firewall tab, then the Firewall policy was not
implemented successfully. You will need to run some debugs to determine what
went wrong.

The last two statements in the list of Firewall Rules are "Drop" and
"Inbound/Outbound Packet".

This section provides information you can use to troubleshoot your
configuration.

If you are running Cisco VPN Client 3.5.x or later and the policy is
not being pushed properly, verify the configuration (as shown in steps 6 and 7)
by making sure that the Client FW tab has the following settings.

Firewall Setting: Firewall Required (recommended)
or anything other than No Firewall

Firewall: Cisco Integrated Client Firewall

Firewall Policy: Policy Pushed (CPP) and pointed
to <filter_name> (the name of the filter to enforce)

If you are experiencing problems accessing or pinging when the tunnel
is active between the VPN Client and the local LAN, go to the VPN Client,
select the connection entry, and choose Modify. Click the
Transport tab and check Allow local LAN Access. This must
match the configured group on the VPN Concentrator end to allow local LAN
access.