To configure the system for ICAP URL filtering, the operator needs to:
Create an AA interface and assign an IP address to each AA ISA within an IES or VPRN service. This routed interface is then used by the system to establish TCP communication with the ICAP server.
Create an HTTP redirect policy (used by the URL filter to redirect HTTP or HTTPS traffic).
Create a URL filter, configure the ICAP server IP address, redirect policy, and default action.
Verify that the AA interface and URL filter are operationally up.
Use the following CLI syntax to configure the AA interface for each AA ISA:
config>service>vprn# aa-interface <aa-if-name> [create]
config>service>vprn>aa-if# aa-interface interface <ip-int-name> [create]
description <description-string>
no description
address <ipv4_subnet/31>
no address
sap <card/mda/aa-svc:vlan> [create]
description <description-string>
no description
egress
[no] filter
[no] qos
exit
ingress
[no] qos
exit
[no] shutdown
exit
The following example displays an AA interface created for the ISA card 1/2 using IP address 172.16.2.1/31:
A:7750>config>service>ies# info
----------------------------------------------
aa-interface "aa-if1" create
address 172.16.2.1/31
sap 1/2/aa-svc:10 create
egress
filter ip 10
exit
no shutdown
exit
no shutdown
exit
In the example above, 172.16.2.1 is used by the IOM side of the interface while the ISA itself is automatically assigned 172.16.2.0 based on the /31 subnet.
Consider the following recommendations:
More than one AA interface can be configured for each AA ISA card, however, the operator must use the same service VLAN across all these interfaces for a URL filter object.
Configure an egress IP filter under the SAP toward the ISA AA interface to only allow selected IP addresses or subnets (for example, ICAP servers or network management).
Use the following CLI syntax to configure the URL filter:
config>app-assure>group#
url-filter <url-filter-name> [create]
default-action {allow | block-all | block-http-redirect <redirect-name>}
no default-action
http-redirect <http-redirect-name>
no http-redirect
http-request-filtering {all | first}
no apply-function-specific-behavior
icap
custom-x-header <x-header-name>
[no] custom-x-header
vlan-id <service-port-vlan-id>
no vlan-id
default-action {allow | block-all | block-http-redirect <redirect-name>}
no default-action
http-redirect <http-redirect-name>no http-redirect
server <ip-address[:port]> [create]
description <description-string>
no description
[no] shutdown
no server <ip-address[:port]>
no url-filter <url-filter-name>
If the apply-function-specific-behavior command is enabled, the operator may configure an ICAP-specific default-action and redirect. This is done by configuring default-action and http-redirect in config>app-assure>group>url-filter>icap context.
The following example displays a URL filter configuration:
*A:7750>config>app-assure>group# url-filter "filter1" create
apply-function-specific-behavior
icap
vlan-id 10
default-action block-http-redirect "http-redirect-portal"
server 172.16.1.101 create
no shutdown
exit
exit
no shutdown
Enabling the apply-function-specific-behavior command allows the operator to configure a default-action and HTTP redirect which are specific to ICAP URL filtering only. Alternatively, the operator configures the same default-action and http-redirect for all url-filter functions by disabling the apply-function-specific-behavior and configuring a default-action and http-redirect in the config>app-assure>group>url-filter context.
The following example displays an AQP entry to enable ICAP URL filtering for opted-in subscribers based on ASO characteristics:
A:7750>config>app-assure>group>policy>aqp# entry 100 create
match
characteristic "url-filter" eq "yes"
exit
action
url-filter "filter1"
exit
no shutdown
Optionally, the operator can add a custom x-header to the ICAP request in order for the ICAP server to filter traffic based on this new x-header value instead of filtering based on subscriber names. This is done by defining a new ASO characteristic for the different ICAP filtering service packages used in the network and referring the characteristic name in the URL filter AQP action.
The following example displays a URL filter configuration with the custom-x-header field added to the ICAP request:
A:7750>config>app-assure>group# url-filter "filter1" create
apply-function-specific-behavior
icap
default-action block-http-redirect "http-redirect-portal"
http-redirect "http-redirect-portal"
custom-x-header "Filtering-Policy"
vlan-id 10
server 172.16.1.101 create
no shutdown
exit
exit
no shutdown
The following example displays the ASO characteristic used to define the type of filtering policy available:
A:7750>config>app-assure>group>policy>aso# info
----------------------------------------------
characteristic "url-filter-policy" create
value "filtering-policy-1" #less than 10 years old
value "filtering-policy-2" # less than 16 years old
value "example1"
value "none"
value "example2"
default-value "none"
exit
----------------------------------------------
The following example displays the AQP action required to add the appropriate ASO value to the ICAP custom-x-header field:
A:7750>config>app-assure>group>policy>aqp# entry 100 create
match
characteristic "url-filter" eq "yes"
exit
action
url-filter "filter1" characteristic "url-filter-policy"
exit
no shutdown