The HP IMC BYOD solution requires a network device to redirect guest or onboarding users to the BYOD web portal.

This functionality could be provided using almost any Comware 5/7 device (L3 Switches, routers, VSR, but not by the L3-lite such as the 5120 !).

However, when a network has mainly Provision devices, the network required the introduction of a Comware device to make the BYOD solution work.

With the current firmware (K.15.16.0004) of the 5400/3500/3800 series, the Portal redirect function has been introduced on the Provision platform as well. Details can be found in the K.15.16 Advanced Traffic Management Guide, the feature is referred to as BYOD-redirect.

This is the direct link to the ATG K.15.16 PDF:

Click to access emr_na-c04490714-1.pdf

Example configuration

Overview

The example configuration assumes that:

• IMC BYOD has been configured
• Wireless solution has been configured
• DHCP Server and scope for onboarding have been configured
• The Provision switch is the current IP router in the network

This example will only focus on the Portal redirect feature of the Provision switches, by configuring a new IP Routed VLAN 21 which is used for the onboarding.

For the example, the onboarding VLAN will use ID 21. The UAM server has bee configured to assign byodanonymous logins to VLAN21.

The Wireless controller simply respects the UAM RADIUS assigned VLAN and will place the wireless client in VLAN21.

The example shows how a Provision switch is configured to:

• act as the default gateway for this onboarding VLAN 21
• performs DHCP Relay function to the DHCP Server configured with the UAM DHCP Plugin
• perform Portal Redirect function
• configuration of Portal Free-rules and ACLs to ensure onboarding users can reach the BYOD Portal page.

VLAN, IP Gateway and DHCP Relay configuration

This step configures the base VLAN, IP and DHCP Relay

 # Define the Onboarding VLAN
3500(config)# vlan 21
3500(vlan-21)# name "v21-guest-onboard"
 # This is the port connected to the Wireless controller
3500(vlan-21)# tagged 22
 # Set the IP
3500(vlan-21)# ip address 10.0.21.1 255.255.255.0
 # DHCP Server with UAM DHCP Plugin and 
 # DHCP Scope for 10.0.21.0/24
3500(vlan-21)# ip helper-address 10.0.1.111
3500(vlan-21)# exit
3500(config)#

Define Portal Server

This example assumes the UAM BYOD Portal is active on IP 10.0.1.100

 # Define a Portal server object at global level
3500(config)# portal web-server uam url http://10.0.1.100:8080/byod

The redirect URL can point to a hostname as well, but you should realize that the switch needs to program ACLs in the TCAM.  Since a DNS/Hostname cannot be programmed in a switch ACL TCAM, the switch will need to resolve the configured hostname. Once the switch has resolved the hostname, it can program the found IP in the TCAM.

In order for the switch to be able to resolve the DNS name, you should point the Switch to use the DNS Server which can resolve the configured BYOD URL hostname.

Activate Portal function on the Onboarding VLAN

When you enable the portal function on the VLAN, the HTTP hi-jack is activated, as well as an aggressive ACL, which will by default reject all UDP/TCP traffic, except traffic to the Portal server IP (as configured or learned through DNS), which is permitted by default.

Any outgoing traffic to TCP port 80 will be hi-jacked and the client will be sent an HTTP Redirect to the configured Portal server URL.

3500(config)# vlan 21
3500(vlan-21)# portal web-server uam
3500(vlan-21)# exit
3500(config)#

Open infrastructure protocols through Portal Free-rules

Once the portal server function is enabled, any other UDP/TCP traffic is dropped, which includes e.g. DHCP and DNS traffic.

These need to be permitted again to get a functional solution.

 # Permit DHCP traffic
3500(config)# portal free-rule 1 vlan 21 source any udp 68 destination any udp 67
 # Permit DNS traffic
3500(config)# portal free-rule 2 vlan 21 source any destination any udp 53

The above rules may be tweaked based on the actual deployments, so you can restrict the UDP port 53 to the actual DNS Server IP for example.

The configuration guide shows an example where bi-directional rules are created, this would be required if the Provision would not be the default gateway, but just a Layer2 switch role between the clients and the L3 gateway. In this example, the Provision switch is also the L3 Gateway, so the return rules were not required.

Validation

As discussed, the post assumes the other components of the BYOD solution have been configured properly.

When a wireless client now connects to the BYOD SSID, the Wireless controller uses MAC-Authentication with the UAM RADIUS to authenticate the device.

Since UAM does not recognize the initial MAC Address, the device will be authenticated as the byodanonymous user account. The Access Service of the BYOD Anonymous will return VLAN 21 to the Wireless controller.

This is the point where the Wireless client will start using the Provision portal.

Example of the Wireless client who opens a web page

On the Provision device, the portal redirect statistics can be seen:

3500(config)# show portal redirect statistics

 Status and Counters - Portal Redirect Information

  Total Opens           : 0
  Resets Connections    : 0
  Current Opens         : 0
  Packets Received      : 3566
  Packets Sent          : 23
  HTTP Packets Sent     : 5

 Current Connection States :

  SYN_RECVD     : 0
  ESTABLISHED   : 0

3500(config)#

Network Trace

This is the filtered network trace, which shows only the DHCP, DNS and Portal Redirect packets. The lab environment Wireless client opened a browser to test.hpnet.local (which can be seen in the DNS lookup), in the lab DNS Server, this hostname was configured to IP 8.8.8.8 (normally Google DNS), just to simulate an external internet IP.

This is the example pcap file in zip format:

201411-provision-portal-trace-filtered

Additional Note on the Portal ACL

It would have been nice to include some ICMP filters as well in the portal free-rule command. With the current implementation, all TCP/UDP traffic is filtered, but all ICMP is allowed.

If you want to filter ICMP from this onboarding VLAN, a classic ACL needs to be activated on the VLAN Interface for the ICMP filtering.

Since these ACLs seem to be processed 1 after the other, you need to include a classic “permit ip any any” at the end, since the rest of the traffic will be filtered/redirected by the portal ACL rules.

Sample configuration to restrict ICMP to the Default gateway and BYOD Portal only

 # Define the ACL to permit only ICMP to the BYOD Portal and onboarding GW IP
3500(config)# ip access-list extended "100"
3500(config-ext-nacl)# 10 permit icmp any host 10.0.1.100
3500(config-ext-nacl)# 20 permit icmp any host 10.0.21.1
 # Reject all other ICMP
3500(config-ext-nacl)# 30 deny icmp any any
 # Permit all other IP (will be filtered by the Portal ACL system)
3500(config-ext-nacl)# 40 permit ip any any
3500(config-ext-nacl)# exit
3500(config)#

 # Activate ACL on the L3 VLAN Interface
3500(config)# vlan 21
3500(vlan-21)# ip access-group 100 in
3500(vlan-21)# exit
3500(config)#

The result on the Wireless Client is that it can ping the BYOD Server, but not the DHCP Server in the lab example:

Summary

This post showed how to configure a Provision device as BYOD Portal Redirect device. This new feature removes the requirement to have a Comware device in the network to implement the BYOD solution.