Configuring MS-MPC-Based or MX-SPC3-Based Converged HTTP Redirect Services
You can configure converged HTTP redirect services on MS-MPCs/MS-MICs. Starting in Junos OS Release 19.3R1, you can also configure converged HTTP redirect service provisioning on the MX-SPC3 services card if you have enabled Next Gen Services on the MX Series router.
Converged service provisioning separates service definition from service instantiation. After a service is defined, a service can be dynamically instantiated at subscriber login or by using a change of authorization (CoA) mid-session. Service instantiation uses only the name of the defined service, hiding all service details from system operators. Converged service provisioning supports service parameterization, which corresponds to dynamic variables within dynamic profiles.
For converged HTTP redirect services, this means that you define the service and service rules within a dynamic profile. The CPCD service rules are created dynamically based on the variables configured in the dynamic profile.
Optionally, you can choose to parameterize the redirect URL
by including defining a redirect-url
variable in the dynamic
profile. The value of the variable is provided by a RADIUS VSA during
subscriber bring-up or with a Change of Authorization (CoA) message.
This enables you to customize the redirect URLs for each subscriber.
You can define a default value for the URL that is used if no value
is provided by RADIUS.
You configure the walled garden as a firewall service filter. It filters traffic so that only HTTP traffic destined outside the walled garden is passed to the dynamic service for processing. Just as for static HTTP redirect services, a service profile contains the service rules. You configure a service set outside the dynamic profile to associate the CPCD service profile with a specific ms service interface on an MS-MPC/MS-MIC or a vsp service interface on an MX-SPC3 services card. Within the dynamic profile, you apply the service set and the walled garden service filter to a dynamic interface.
Configuring a Walled Garden as a Firewall Service Filter
When you configure the walled garden as a firewall service filter, traffic that is destined to servers within the walled garden is identified and skipped. Because this traffic does not flow to the line card, handling requirements are reduced.
All other HTTP traffic is destined for addresses outside the walled garden. Because this traffic does not match the filter conditions, it flows to the line card for handling.
You can configure the service filter so that the walled garden contains a single server as the captive portal or a list of servers.
Configure the walled garden with a single server as the captive portal:
Create the service filter.
[edit] user@host# edit firewall family address-family service-filter filter-name
Define a filter term to identify and skip processing for traffic to the captive portal.
Specify filter conditions to match traffic that is destined for the captive portal by specifying the destination address of the captive portal and the destination port.
[edit firewall family inet service-filter filter-name] user@host# set term name from destination-address ip-address user@host# set term name from destination-port port-number
Specify that the matching traffic skips processing on the line card.
[edit firewall family inet service-filter filter-name] user@host# set term name then skip
Define a filter term to identify HTTP traffic from all the traffic that did not match the previous term and send it for processing by CPCD service rules.
Specify one or more HTTP port numbers to match the skipped HTTP traffic.
[edit firewall family inet service-filter filter-name] user@host# set term name from destination-port http-port-number
Specify that the matching traffic is processed by a CPCD service.
[edit firewall family inet service-filter filter-name] user@host# set term name then service
Define a filter term to skip further action for any remaining, non-HTTP traffic.
[edit firewall family inet service-filter filter-name] user@host# set term name then skip
For example, the following configuration creates a filter for IPv4 HTTP traffic, walled-v4, with the captive portal on 192.0.2.0. Traffic matching the address is skipped. Nonmatching traffic goes to term http, where HTTP traffic is picked out of all skipped traffic and sent to be processed according to a CPCD service. Finally, term skip causes all the remaining, non-HTTP traffic to be skipped.
[edit] user@host# edit firewall family inet service-filter walled-v4 [edit firewall family inet service-filter walled-v4] user@host# set term portal from destination-address 192.0.2.0 user@host# set term portal from destination-port 80 user@host# set term portal then skip user@host# set term http from destination-port 80 user@host# set term http then service user@host# set term skip then skip
Configure the walled garden as a list or subnet of servers.
Create the service filter.
[edit] user@host# edit firewall family address-family service-filter filter-name
Define a filter term.
Specify filter conditions to match traffic that is destined for any server in the walled garden by specifying a destination prefix list of servers.
[edit firewall family inet service-filter filter-name] user@host# set term name from destination-prefix-list list-name user@host# set term name from destination-port port-number
Specify that the matching traffic skips processing on the line card.
[edit firewall family inet service-filter filter-name] user@host# set term name then skip
Define a filter term to identify HTTP traffic from all the traffic that did not match the previous term and send it for processing by CPCD service rules.
Specify one or more HTTP port numbers to match the skipped HTTP traffic.
[edit firewall family inet service-filter filter-name] user@host# set term name from destination-port http-port-number
Specify that the matching traffic is processed by a CPCD service.
[edit firewall family inet service-filter filter-name] user@host# set term name then service
Define a filter term to skip further action for any remaining, non-HTTP traffic.
[edit firewall family inet service-filter filter-name] user@host# set term name then skip
(Optional) Define a prefix list that specifies servers within the walled garden. You can specify a subnet or multiple individual addresses.
[edit policy-options] user@host# set prefix-list list- name ip-address/mask user@host# set prefix-list list- name ip-address1 user@host# set prefix-list list- name ip-address2
For example, the following configuration creates a service filter for IPv6 HTTP traffic, walled-v6-list, with a prefix list, wg-list, that specifies two servers in the walled garden. Filter term portal6 identifies IPv6 traffic that is destined for the walled garden. Nonmatching traffic goes to term http6, where HTTP traffic is picked out of all skipped traffic and sent to be processed according to a CPCD service. Finally, term skip causes all the remaining, non-HTTP traffic to skipped.
[edit] user@host# edit firewall family inet6 service-filter walled-v6-list user@host# set term portal6 from destination-prefix-list wg-list user@host# set term portal6 then skip user@host# set term http6 from destination-port [80 8080] user@host# set term http6 then service user@host# set term skip6 then skip [edit policy-options] user@host# set prefix-list wg-list 2001:db8::10.10 user@host# set prefix-list wg-list 2001:db8::10.22
Configuring HTTP Redirect for Local and Remote Redirect Servers
When HTTP requests are made for sites outside the walled garden, CPCD can redirect the traffic to a captive portal for authentication and authorization.
Configure a CPCD service rule that specifies the action to be taken for the HTTP traffic identified by the walled garden service filter and passed to the service. The action you configure depends on whether you are using a local or a remote HTTP redirect server:
If you are using a local HTTP redirect server on the router, you specify the redirect action.
If you are using a remote HTTP redirect server, which resides in a walled garden behind the router, then you cannot simply specify a redirect URL. In this case, the service rule must rewrite the IP destination address for the traffic. The new destination address is the address of the remote HTTP redirect server. The remote server then supplies a redirect URL to send the traffic to a captive portal.
For example, in the following configuration for a local server,
the dynamic profile http-redir-converged includes the CPCD service
rule redir-svc. The rule redirects traffic to a captive portal, http://www.portal.example.com
. The original URL entered
by the subscriber is appended to the redirect URL. The CPCD service
profile redir-prof includes the rule, and will later be applied to
a service interface by a service set.
user@host# edit dynamic-profiles http-redir-converged user@host# edit services captive-portal-content-delivery user@host# edit rule redir-svc user@host# set match-direction input user@host# set term redir1 then redirect http://www.portal.example.com/url=%dest-url%
The following configuration for a remote server creates CPCD service rule rewr-svc that rewrites the original destination address to the address of the remote server, 192.0.2.230.
user@host# edit dynamic-profiles http-redir-converged user@host# edit services captive-portal-content-delivery user@host# edit rule rewr-svc user@host# set match-direction input user@host# set term rewr1 then rewrite destination-address 192.0.2.230
Configuring Parameterization for the Redirect URL
You can optionally choose to parameterize the redirect URL and the rewrite destination address by specifying user-defined variables in the dynamic profile. Parameterizing means that URL or address becomes a dynamic variable. The value is provided by RADIUS when the subscriber is authenticated or when a CoA is received. Consequently, you can use the RADIUS attributes to provide different URLs or destination addresses for different subscribers.
For example, the following configuration shows two user-defined variables, redirect-url and rewrite-da that require externally provided values when they are instantiated. CPCD service rule redir1 specifies traffic is redirected to $redirect-url. CPCD service rule rewr1 specifies that the destination address for the traffic is rewritten to $rewrite-da.
user@host# edit dynamic-profiles http-redir-converged user@host# edit variables user@host# set redirect-url mandatory user@host# set rewrite-da mandatory user@host# edit services captive-portal-content-delivery user@host# edit rule redir-svc user@host# set match-direction input user@host# set term redir1 then redirect $redirect-url user@host# edit rule rewr-svc user@host# set match-direction input user@host# set term rewr1 then rewrite $rewrite-da
Configuring the Service Set to Associate the Service Profile with a Service Interface
Service sets define one or more services to be performed by the MS-MPC/MS-MIC, or by the MX-SPC3 services card if you have enabled Next Gen Services on the MX Series router. For HTTP redirect services, you define a CPCD service profile that includes CPCD rules. The service set applies the CPCD service profile to a specific service interface.
For example, the following configuration creates CPCD service profile redir-prof, which references the CPCD rule redir-svc. Service set cvgd associates the CPCD service profile rewr-prof with the service interface ms-2/0/0.
[edit services captive-portal-content-delivery] user@host# edit profile redir-prof user@host# set cpcd-rules redir-svc user@host# set dynamic [edit services] user@host# edit service-set cvgd user@host# set captive-portal-content-delivery-profile redir-prof user@host# set interface-service service-interface ms-2/0/0
Attaching a CPCD Service Set and Service Filter to a Dynamic Logical Interface
To use the HTTP redirect services, you must attach the CPCD service set to a logical interface. Because the walled garden is configured as a service filter, you must attach it to the same interface as the service set. Traffic arriving on and leaving that interface is filtered by the service filter. Traffic identified for servicing is sent to the MS-MPC or MX-SPC3 service interface where the CPCD profile is applied.
This procedure shows only elements of the dynamic profile configuration that are specific to the converged services configuration. The complete dynamic profile depends on your use case.
For example, the following configuration creates the dynamic profile http-redir-converged. It specifies predefined variables to create the dynamic physical and logical interfaces in the IPv4 address family. The profile attaches service set cvgd and service filter walled-v4 to the dynamic logical interface when it is created at subscriber login. The service set and filter are both applied to the interface input and output.
user@host# edit dynamic-profiles http-redir-converged user@host# edit interfaces $junos-interface-ifd-name user@host# edit unit $junos-underlying-interface-unit user@host# edit family inet user@host# set service input service-set cvgd service-filter walled-v4 user@host# set service output service-set cvgd service-filter walled-v4
Installing a Service Package for CPCD Service
To use CPCD services on an MS-MPC/MS-MIC, or on an MX-SPC3 services card if you have enabled USF on the MX Series router, you configure a service interface on the MS-MIC or MX-SPC3. You must install the required service packages on each MS-MIC that has a service interface or on an MX-SPC3.
For example, the following configuration loads the CPCD services package and the mobile subscriber services package on the MS-MPC in chassis slot 1 and the MS-MIC in slot 0 of the MPC. System log messages are generated for any daemon and for local external applications at all severity levels.
user@host# edit chassis fpc 1 pic 0 adaptive-services service-package [edit chassis fpc 1 pic 0 adaptive-services service-package] user@host# set extension-provider package jservices-cpcd,jservices-mss [edit chassis fpc 1 pic 0 adaptive-services service-package] user@host# set extension-provider syslog daemon any user@host# set extension-provider syslog external any
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.