Application Assurance — HTTP and HTTPS Redirect

The redirect policy is configured as follows:

*A:Dut-C>config>app-assure>group# info
----------------------------------------------
       http-redirect "policy-redirect" create
          description "redirects certain http traffic to a portal"
          template 5
          tcp-client-reset
          redirect-url "http://192.0.2.1/redirect_main.html?OriginalURL=$URL"
          no shutdown
       exit
----------------------------------------------

The preceding configuration defines:

• The template to be used ("template 5" means that macro substitution will be used). This allows the operator to append additional information to the redirect information, which can be used by the redirect portal to offer more details about why the subscriber was redirected or to offer more personalized services.

• Traffic that cannot be redirected will be TCP reset. This provides immediate feedback to the subscriber that the service requested is not available. The client application will not have to wait for the TCP session to expire.

• The redirect URL. The original URL will be appended.

The application "Captive Portal" is created and used in the app-filter that contains the redirect server address, as follows:

*A:Dut-C>config>app-assure>group# info
----------------------------------------------
    policy
        begin
        application "Captive Portal" create
            description "HTTP Redirect portal"
            app-group "Web"
        exit
 
        app-filter
            entry 200 create
                server-address eq 192.0.2.1/32
                application "Captive Portal"
                no shutdown
            exit
        exit
        commit
    exit
----------------------------------------------

The preceding configuration defines:

• An application called "Captive Portal"

• An app-filter using destination address 192.0.2.1 (the address of the redirect server) and linking it to the application "Captive Portal"

The following configuration defines a charging group and an application. The charging group created is assigned to the application.

*A:Dut-C>config>app-assure>group# info
----------------------------------------------
  policy 
    begin 
    charging-group "allow-list" create 
    description " Charging group for redirect portal and URLs in the allow-list" 
       exit 
 
  application "Captive Portal" create 
    description "HTTP Redirect Portal" 
    app-group "Web" 
      charging-group "allow-list" 
       exit 
    commit
----------------------------------------------

Nokia recommends defining a charging group for the URLs in the allow-list. Even though an application (or several applications) can be configured, defining a charging group provides a simpler approach; AA application group mappings are not affected, and it is easier to configure AQPs. The redirect pages are usually free-of-charge, so configuring a charging group is the preferred way to aggregate these URLs.

As well as the redirect portal, DNS traffic should also be assigned to the "allow-list" charging group. Before performing an HTTP request, the subscriber's browser will first make a DNS request to resolve the hostname. Therefore, DNS traffic should be allowed.

This example assumes that the operator has loaded an AppDB configuration in the system. The AppDB contains the configuration (app-group, application, app-filter) for DNS traffic. The default application for DNS is as follows:

application "DNS" create
  description "Domain Name System"
  app-group "Network Infrastructure"
exit

This preceding configuration should be modified as follows:

*A:Dut-C>config>app-assure>group# info
----------------------------------------------
policy
   begin
   application "DNS" create
      description "Domain Name System"
      app-group "Network Infrastructure"
      charging-group "allow-list"
   exit
   commit
----------------------------------------------

The following configuration creates a new application that contains all the allowed URLs. The application is assigned to the "allow-list" charging group.

*A:Dut-C>config>app-assure>group# info
----------------------------------------------
 policy 
   begin
     application "URL-allow-list" create
       description "URLs to be allowed"
       app-group "Web"
       charging-group "allow-list"
     exit
   commit
----------------------------------------------

The following configuration creates an app-filter for the URLs in the allow-list. The configuration contains the URL and assigns it to an application.

*A:Dut-C>config>app-assure>group# info
----------------------------------------------
 policy 
   begin
   app-filter
   entry 61001 create
     description "dummy allowed domain"
     expression 1 http-host eq "*.domain.com$"
     application "URL-allow-list"
     no shutdown
   exit
   commit
----------------------------------------------

The operator can extend the preceding configuration and add more URLs to the allow-list.

The following configuration defines:

• An ASO that will be used as a policy criterion to decide whether redirection will occur. The ASO is called "redirect" and has two values: "no" and "yes". The default value will be "no" (do not redirect).

• An AQP to perform redirection. The match criteria will be the preceding ASO and the value of the charging group. If the match criteria are met, the action will be to drop and redirect the flow using the "policy-redirect" defined.

*A:Dut-C>config>app-assure>group# info
----------------------------------------------
       policy
           begin
           app-service-options
               characteristic "redirect" create
                   value "no"
                   value "yes"
                   default-value "no"
               exit
           exit
 
           app-qos-policy
               entry 400 create
                   match
                       charging-group neq "allow-list"
                       characteristic "redirect" eq "yes"
                   exit
                   action
                       drop
                       http-redirect "policy-redirect" flow-type dropped-flows
                   exit
                   no shutdown
               exit
            exit
            commit
----------------------------------------------

Having the charging group as match criteria is a future-proof solution: the configuration can easily be adapted in the future (if, for example, additional URLs should be allowed).

The following show commands can be used to verify the configuration and correct possible errors.

The following command shows the redirect policy:

*A:Dut-C# show application-assurance group 1 http-redirect "policy-redirect" detail
 
===============================================================================
Application Assurance Group 1 HTTP Redirect policy-redirect
===============================================================================
Description        : redirects certain http traffic to a portal
Template           : 5
                   : Redirect supporting macro substitution using HTTP 302
Redirect URL       : http://10.99.99.40/redirect_main.html?OriginalURL=$URL
Captive Redirect   : No
    Redirect HTTPS : No
    VLAN ID        : N/A
Admin Status       : Up
AQP Ref            : Yes
 
-------------------------------------------------------------------------------
Group 1
-------------------------------------------------------------------------------
Redirects Sent        : 0
Client Resets Sent    : 0
Redirects Not Sent    :
    Out of Resources  : 0
    Config Errors     : 0
    Other Errors      : 0
 
-------------------------------------------------------------------------------
Total
-------------------------------------------------------------------------------
Redirects Sent        : 0
Client Resets Sent    : 0
Redirects Not Sent    :
    Out of Resources  : 0
    Config Errors     : 0
    Other Errors      : 0
===============================================================================

The preceding command provides the following information:

• The template used, along with a definition of that template

• The URL that the subscriber will be redirected to

• Whether this is a captive redirect and whether HTTPS will be redirected

• The admin status of the policy. An admin status of "Down" indicates that the policy is not in use.

• Whether this policy is referenced by an AQP. If it is not referenced, it is not used.

• "Redirects Sent" indicates the number of times that AA has sent a redirect message.

• "Client Resets Sent" indicates the number of times that TCP reset was sent.

• "Out of Resources" indicates the number of times that a redirect was not sent. The reasons relate to exhaustion of ISA resources (for example, memory).

• "Config Errors": for example, a command is in shutdown state

• "Other Errors": errors that are not in any of the preceding two categories

The following command shows the "Captive Portal" application:

*A:Dut-C# show application-assurance group 1 policy application "Captive Portal"
 
===============================================================================
Application Instance "Captive Portal"
===============================================================================
Description    : HTTP Redirect portal
App Group      : Web
Export Id      : none
Charging Group : allow-list
 
References
-------------------------------------------------------------------------------
AA Sub Stat    : none
Cflowd         : none
AQP Entries    :
App Filters    :
          200
 
Reference Counts
-----------------------------------
No. of cflowd references      : 0
No. of AQP entry references   : 0
No. of app filter references  : 1
===============================================================================

The preceding command provides the following information:

• The charging group assigned

• The app-filters linked (200)

The following command shows the app-filter for the redirect portal:

*A:Dut-C# show application-assurance group 1 policy app-filter 200
 
app-filter
    entry 200 create (0 flows, 0 B)
        server-address eq 10.99.99.40/32
        application "Captive Portal"
        no shutdown
    exit
exit

Using the preceding command, the operator can verify the number of flows and bytes matched and, therefore, determine if traffic toward the redirect portal was classified.

Show the AQP for redirection:

*A:Dut-C# show application-assurance group 1 policy app-qos-policy 400
 
===============================================================================
Application QOS Policy Entry 400 (Application Based Policy)
===============================================================================
Description : (Not Specified)
Admin State : in-service
Hits        : 0 flows
Conflicts   : 0 flows
 
Match :
    Charging Group           : neq allow-list
    ASO Characteristics      :
        redirect             : eq yes
 
Action :
    Drop                         : yes
    HTTP Redirect                : policy-redirect flow-type dropped-flows
===============================================================================

Using the preceding display, the operator can verify whether flows are matched to the AQP.

• QUIC is a protocol originally developed by Google to reduce end-to-end latency. It is used by Google services and browsers (Chrome). Because QUIC cannot be redirected, traffic that would have been redirected may be dropped instead. This can be achieved in two ways:

  1. Allow UDP traffic on port 53 and block all other UDP traffic.

     QUIC is over UDP. Therefore, by allowing UDP on port 53 and blocking all other traffic, the operator can perform DNS requests, but all other UDP traffic (including QUIC) will be blocked.

  2. Create an application to block UDP traffic on port 443 at the first packet.

     QUIC is running on port 443. Therefore, the following app-filter will block QUIC traffic (UDP traffic on port 443). The "first-packet-validate" option is used for applications using a well-known TCP/UDP port and ensures that the policy will be applied from the first packet, while allowing AA to detect an unexpected application to the well-known port.

     policy
        begin
        application "UDP 443 Validate" create
           description "First Packet Verify application for any UDP on port 443 
                       such as QUIC"
           app-group "Web"
        exit
        app-filter
           entry 700 create
              ip-protocol-num eq udp
              server-port eq 443 first-packet-validate
              application "UDP 443 Validate"
              no shutdown
           exit
        exit
        commit
     

• Some mobile OSs (for example, Android) generate an HTTP request to a predefined "test URL" to verify that Internet access exists. The HTTP request is sent immediately after the device connects to a WiFi network. Even though the HTTP requests are generated in the background, redirecting these URLs will result in the redirect response to be presented in the web browser.

  Depending on the operator's use case, these URLs may be redirected. Redirecting these URLs may affect the DNS cache of the mobile device. The device thinks that it does not have full Internet access. On Android devices, the subscriber will see a message similar to the following:

  

  The app-filter for the redirect server was configured using the server IP address (server-address eq 192.0.2.1/32). The app-filter for the redirect server can also be configured using a host (or any other HTTP-related) expression. An example configuration follows:

  app-filter
     entry 200 create
         expression 1 http-host eq "*.redirect_domain.com$"
         application "Captive Portal"
         no shutdown
     exit
  exit
  

  The preceding configuration will classify HTTP traffic when the hostname is "*.redirect_domain.com$".

  If this configuration approach is chosen, the operator must be certain that the app-filter will classify all the traffic toward the redirect portal. There may be cases where some content may be fetched from additional locations too (for example, "*.content_domain.com$"); therefore, additional app-filters should be configured.

  To ensure that the configuration is correct and complete, a trace can be analyzed.

AA redirect errors describes what each AA redirect error means.

The following configuration will create and populate a DNS IP cache:

• DNS responses for the host "*.domain1.com$". Traffic to www.domain.com will be allowed.

• responses only from the DNS server with IP address 8.1.17.21 (which is considered a trusted DNS server)

*A:Dut-C>config>app-assure>group# info
----------------------------------------------
      dns-ip-cache "domain1-cache" create
          description "dns cache for domain1"
          dns-match
              domain "domain1" expression "*.domain1.com$"
              server-address 8.1.17.21
          exit
          no shutdown
      exit
----------------------------------------------

The following configuration will create a default subscriber policy to snoop DNS responses. This AQP is used to populate the cache.

No match criteria are needed. AA will only analyze the DNS traffic to populate the cache.

*A:Dut-C>config>app-assure>group# info
----------------------------------------------
policy
    begin
    app-qos-policy
        entry 50 create
            action
               dns-ip-cache "domain1-cache"
            exit
            no shutdown
        exit
    exit
    commit
exit
----------------------------------------------

The following will configure a captive redirect policy for the redirect portal. The configuration defines the redirect URL. Using macro substitution, the original URL that the subscriber requested will be appended in the redirect URL. Non-HTTP traffic will be TCP reset. The template specifies that the redirect template be used: "template 5" defines macro substitution using HTTP 302. HTTPS traffic will also be redirected.

*A:Dut-C>config>app-assure>group# info
----------------------------------------------
http-redirect "capt-redirect" create
    template 5
    tcp-client-reset
    redirect-url "http:// 192.0.2.1/redirect_main.html?OriginalURL=$URL"
    captive-redirect
        redirect-https
    exit
    no shutdown
exit
----------------------------------------------

The preceding configuration did not define the VLAN ID. The VLAN ID refers to an AA IP aa-interface that the operators need to create within the subscriber service (IES or VPRN) for ESM subscribers, and is used by the ISA to respond to the subscriber. Operators need to create one interface per AA ISA card.

The VLAN ID does not need to be defined if the ISA group aa-sub-scale mode is configured for DSM.

HTTP redirection shows the high-level message flow of HTTP redirection.

As shown in HTTP redirection:

• The subscriber attempts to access a site.

• The SR OS node determines that traffic will be redirected. No traffic will be allowed to pass.

• The SR OS node returns an HTTP response message indicating the redirect.

• The browser automatically generates a new request toward the redirect portal.

• The content of the redirect page is shown to the subscriber.

Access to domain included in the allow-list versus HTTPS redirect shows how HTTP access to a domain included in the allow-list is granted, while access to an HTTPS site is redirected.

As shown in Access to domain included in the allow-list versus HTTPS redirect:

• The subscriber first attempts to access www.domain1.com. This site has been configured as a allowed site in SR OS.

• The subscriber next attempts to access the HTTPS site www.portal.com. This portal is not an allowed one. Therefore, the system will perform HTTPS redirection.

The system will return a self-signed Nokia certificate, similar to the following.

• If the subscriber accepts the new certificate, a new SSL tunnel will be established and a new request toward the redirect server will be generated.

• Finally, the subscriber will see the contents of the redirect page.

The following session filter is configured to:

• Allow DNS traffic (UDP traffic on port 53)

• Allow domains included in the DNS IP cache (traffic to www.domain1.com)

• Allow traffic to the redirect portal (portal IP address: 192.0.2.1)

• Redirect all other TCP traffic to the redirect portal

*A:Dut-C>config>app-assure>group# info
----------------------------------------------
session-filter "capt_redirect" create
    description "Session filter for captive redirect policy"
    default-action deny
    entry 5 create
        match
            ip-protocol-num udp
            dst-port eq 53
        exit
        action permit
    exit
    entry 10 create
        match
            dst-ip dns-ip-cache "domain1-cache"
         exit
         action permit
    exit
    entry 15 create
        description "Allow traffic to the redirect landing page server"
        match
            ip-protocol-num tcp
            dst-ip 192.0.2.1/32
            dst-port eq 80
        exit
        action permit
    exit
    entry 20 create
        match
            ip-protocol-num tcp
        exit
        action http-redirect "capt-redirect"
    exit
exit
----------------------------------------------

Operators can verify their configuration as follows.

The following command shows the session filter together with the number of flows matched:

*A:Dut-C# show application-assurance group 1 session-filter "capt_redirect"
 
===============================================================================
AA Session Filter Instance "capt_redirect"
===============================================================================
Description    : Session filter for captive redirect policy
Default Action : deny
    Event Log  : (Not Specified)
AQP Entries    :
-------------------------------------------------------------------------------
Filter Match Criteria
-------------------------------------------------------------------------------
Entry          : 5
Description    : (Not Specified)
IP Protocol    : udp
Dest Port      : eq 53
Action         : permit
    Event Log  : (Not Specified)
Hits           : 0 flows
-------------------------------------------------------------------------------
Entry          : 10
Description    : (Not Specified)
IP Protocol    : none
Dest IP Cache  : domain1-cache
Action         : permit
    Event Log  : (Not Specified)
Hits           : 0 flows
-------------------------------------------------------------------------------
Entry          : 15
Description    : Allow traffic to the redirect landing page server
IP Protocol    : tcp
Dest IP        : 192.0.2.1/32
Dest Port      : eq 80
Action         : permit
    Event Log  : (Not Specified)
Hits           : 0 flows
-------------------------------------------------------------------------------
Entry          : 20
Description    : (Not Specified)
IP Protocol    : tcp
Action         : http-redirect capt-redirect
    Event Log  : (Not Specified)
Hits           : 0 flows
-------------------------------------------------------------------------------
No. of entries   : 4
===============================================================================

The preceding show output provides the following information:

• The "Default Action" specifies the action to take if a packet does not match any of the filters defined in the session filter (deny).

• The filters defined are:

  • Allowing DNS traffic (UDP traffic on port 53, entry 5)

  • Allowing traffic matching the DNS IP cache (entry 10)

  • Allowing traffic to the redirect portal (entry 15)

  • Redirecting all other traffic (entry 20)

• The "Hits" counter on each filter provides information about how many flows matched the corresponding filter.

The following command shows the DNS IP cache:

*A:Dut-C# show application-assurance group 1 dns-ip-cache "domain1-cache"

===============================================================================
Application Assurance Group 1 dns-ip-cache "domain1-cache"
===============================================================================
Admin Status                : Up
AQP Ref                     : Yes
Domain expressions          : 1 (out of 32)
Server addresses            : 1 (out of 64)
High watermark              : 90%
Low watermark               : 80%
Cache size                  : 10
-------------------------------------------------------------------------------
ISA                        Usage         (%)        Alarm             Hit Count
                                                    State
-------------------------------------------------------------------------------
1/2                            0        0.00        clear                     0
3/1                            0        0.00        clear                     0
===============================================================================

The preceding command shows:

• The administrative status of the DNS IP cache ("Up"). An administrative status of "Down" indicates that the DNS IP cache is not in use.

• Whether the DNS IP cache created is referenced by an AQP

• The number of configured domain expressions (in the example: "*.domain1.com$") and the maximum value (shown in brackets)

• The number of server addresses and the maximum value (shown in brackets)

• The number of times a cache lookup was successful ("Hit Count"). A hit count of 0 indicates a possible configuration error.

The following command shows information about the HTTP redirect:

*A:Dut-C# show application-assurance group 1 http-redirect "capt-redirect" detail
 
===============================================================================
Application Assurance Group 1 HTTP Redirect capt-redirect
===============================================================================
Description        : (Not Specified)
Template           : 5
                   : Redirect supporting macro substitution using HTTP 302
Redirect URL       : http://192.0.2.1/redirect_main.html?OriginalURL=$URL
Captive Redirect   : Yes
    Redirect HTTPS : Yes
    VLAN ID        : N/A
Admin Status       : Up
AQP Ref            : No
 
-------------------------------------------------------------------------------
Group 1
-------------------------------------------------------------------------------
Redirects Sent        : 0
Client Resets Sent    : 0
Redirects Not Sent    :
    Out of Resources  : 0
    Config Errors     : 0
    Other Errors      : 0
 
-------------------------------------------------------------------------------
Total
-------------------------------------------------------------------------------
Redirects Sent        : 0
Client Resets Sent    : 0
Redirects Not Sent    :
    Out of Resources  : 0
    Config Errors     : 0
    Other Errors      : 0
===============================================================================

The preceding output provides the following information:

• The template used and description about the template

• The redirect URL

• Whether this is a captive redirect and whether HTTPS will be redirected also

• The VLAN ID. Captive redirect uses the provisioned VLAN ID to send the HTTP response to the subscribers; therefore, this VLAN ID must be properly assigned in the same VPN as the subscriber (not needed for DSM).

• The admin status of the redirect. An admin status of "Down" indicates that the policy is not in use.

• "Redirects Sent" indicates the number of times that AA has sent a redirect message.

• "Client Resets Sent" indicates the number of times that TCP reset was sent.

• "Out of Resources" indicates the number of times that a redirect was not sent. The reasons relate to exhaustion of resources in ISA (such as memory).

• "Config Errors": for example, a command is in shutdown state

• "Other Errors": errors that are not in any of the preceding two categories

Based on an FTP server with IP address 192.168.1.100, the operator can dump the contents of the DNS IP cache, as follows:

*A:Dut-C# tools dump application-assurance group 1 dns-ip-cache "domain1-cache" url ftp://username:password@192.168.1.100/path/to/mylog.log

The preceding command will generate a text file, containing the following:

=====================================================
Application-Assurance dns-ip-cache "domain1-cache"
Current Time:          "11/08/2017 12:45:32" (UTC)
  group:               1
  isa:                 3/2
  admin state:         no shutdown
  max-entries:         10
=====================================================
ip-address  creationTime(UTC)  lastUpdated(sec)  numDNSResponses   lastMatchTime(UTC)  numTimesMatched
 
Total entries in-use:   0
 
=====================================================

The log file shows the number of times that a cache entry was matched (numDNSResponses) and the number of times that traffic to this address was sent (numTimesMarches).

HTTPS redirect is not available in Releases earlier than SR OS 14.0 (the session will simply be TCP reset).

Some browsers store certificates of popular sites. If the subscriber tries to access one of those sites, the browser will not accept the AA-signed certificate and the redirect page will never be displayed. The subscriber does not have an option to accept the certificate.

If the operator wants to configure an HTTPS redirect (either on VSR since Rel. 14.0 or in CMG since Rel.10.0), the FW ASL License is mandatory. It is needed to enable the use of the session filter by the captive redirect.

When using the standard HTTP redirect, there is no need for an aa-interface. However, when using the captive redirect, the operator needs one aa-interface per VPN service, not one interface per subscriber VLAN. To associate the redirect policy with the subscriber in the correct VPN for captive redirect, the operator needs to use ASO/ASO override, which will point to a redirect policy per VPN-this redirect policy will point to an aa-interface in the correct VPN service.

Captive redirect is special in the sense that no traffic is allowed from the Internet (apart from the traffic to the redirect portal).

HTTPS captive redirect cannot be used with ESM subscribers on L2-aware NAT. The forwarding model used for L2-aware NAT does not allow the use of HTTPS captive redirect. If configured, the session filter will be hit, but no TCP message will be sent to the subscriber. The AA statistics will show discarded packets.