HP Unified Wireless: Portal free user-url

On the Unified wireless solution, guest users can be authenticated through the captive web-portal feature of the portal server.

The network admin could allow some guest traffic to pass without guest authentication to provide a “walled-garden” solution.
This was already possible using the portal free-rule configuration, but the free-rule only supported source/destination IP/TCP/UDP information. It was not possible to include a DNS domain name.

Release 3507P32 (830) and 2507P32 (850/870/20G) now includes a portal free rule for URLs containing a permitted string. In this post a quick overview of how the feature works.

Configuration

Configuration assumes standard Portal authentication has already been configured.
On the controller,  configure the portal user-url rule with the target domain you want to permit. Wildcard * is supported, multiple wildcards as well (e.g. *.mycompany.*).

In the test lab, a test domain test.eu is used:

[ac1]portal user-url *.test.eu free

 

How it works

Normal Portal free-rule ACL operation

When the admin configures manual free-rule entries, these are added to the portal acl static record list. For example:

  # Add static IP based rule
[ac1] portal free-rule 20 destination ip 10.0.1.200 mask 32

  # Verify rule in ACL
[ac1] display portal acl all interface vlan 22
IPv4 portal ACL rules on Vlan-interface22:

 Rule 1 ### This rule applies to the configured Portal server IP
 Inbound interface : all
 Type              : static
 Action            : permit
 Protocol          : 0
 Source:
    IP        : 0.0.0.0
    Mask      : 0.0.0.0
    Port      : any
    MAC       : 0000-0000-0000
    Interface : any
    VLAN      : 22
 Destination:
    IP        : 10.0.22.1
    Mask      : 255.255.255.255
    Port      : any

 Rule 2 ### This rule shows the static configured free-rule
 Inbound interface : all
 Type              : static
 Action            : permit
 Protocol          : 0
 Source:
    IP        : 0.0.0.0
    Mask      : 0.0.0.0
    Port      : any
    MAC       : 0000-0000-0000
    Interface : any
    VLAN      : 22
 Destination:
    IP        : 10.0.1.200
    Mask      : 255.255.255.255
    Port      : any

 Rule 3 ### This rule shows the redirect of port 80 to the TCP cheat software (CPU) process
 Inbound interface : all
 Type              : static
 Action            : redirect
 Protocol          : 6
 Source:
    IP        : 0.0.0.0
    Mask      : 0.0.0.0
    Port      : any
    MAC       : 0000-0000-0000
    Interface : any
    VLAN      : 22
 Destination:
    IP        : 0.0.0.0
    Mask      : 0.0.0.0
    Port      : 80

 Rule 4 ### This rule shows the drop for any other traffic not matching previous rules
 Inbound interface : all
 Type              : static
 Action            : deny
 Protocol          : 0
 Source:
    IP        : 0.0.0.0
    Mask      : 0.0.0.0
    Port      : any
    MAC       : 0000-0000-0000
    Interface : any
    VLAN      : 22
 Destination:
    IP        : 0.0.0.0
    Mask      : 0.0.0.0
    Port      : any

[ac1]

The TCP 80 redirect is the important rule here. All TCP 80 traffic is redirected by the hardware ACL to a software process called TCP CHEAT.

This process will terminate any TCP connection (by spoofing the requested target IP) and when the guest client sends an HTTP GET, it will send an HTTP REDIRECT to the portal server URL.

New Portal user-url feature operation

When the feature was announced, I was wondering if the controller had to be configured with DNS to make this work (after all, some DNS to IP mapping must be made to program the hardware ACLs). I was quite surprised to see the feature works even when no DNS client is configured on the controller. So with wireshark I tried to see what happened.

The result seems to be:

  • Guest user attempts to open http://www.test.eu (test url in the lab setup)
  • DNS resolves to IP 10.0.1.113 (portal auth must allow DNS traffic to pass)
  • Guest device opens TCP 80 session to 10.0.1.113
  • Portal authentication redirects 10.0.1.113 to TCP CHEAT process
  • TCP CHEAT spoofs the TCP session setup to 10.0.1.113
  • Guest device sends HTTP GET to TCP CHEAT process
  • HTTP GET includes in HTTP header : host: http://www.test.eu
  • TCP CHEAT sees match on user-url (*.test.eu)
  • TCP CHEAT registers the spoofed target IP 10.0.1.113 in the portal acl static list
  • TCP CHEAT terminates the spoofed TCP connection
  • Guest user will see a failed connection
  • Guest user re-tries to open http://www.test.eu
  • Guest devices opens TCP 80 session to 10.0.1.113
  • Portal authentication will pass the traffic since 10.0.1.113 is on the portal static acl permit list
  • Guest user now has access to target website
  • Any future users who attempt access to the site are directly permitted, no more failed connections. Users who attempt to directly reach the target 10.0.1.113 IP are also allowed access now (independent of the actual URL they use), since the IP is allowed by the ACL.

In the network trace you can see this:

20141215-portal-free-url-1

 

After the initial connection, the user would see a connection reset:

20141215-portal-free-url-2

At this point, the controller portal free-rule static list has been updated:

<ac1>display portal acl static interface vlan 22
IPv4 portal ACL rules on Vlan-interface22:
 Rule 1
 Inbound interface : all
 Type              : static
 Action            : permit
 Protocol          : 0
 Source:
    IP        : 0.0.0.0
    Mask      : 0.0.0.0
    Port      : any
    MAC       : 0000-0000-0000
    Interface : any
    VLAN      : 22
 Destination:
    IP        : 10.0.22.1
    Mask      : 255.255.255.255
    Port      : any

 Rule 2
 Inbound interface : all
 Type              : static
 Action            : permit
 Protocol          : 0
 Source:
    IP        : 0.0.0.0
    Mask      : 0.0.0.0
    Port      : any
    MAC       : 0000-0000-0000
    Interface : any
    VLAN      : 22
 Destination:
    IP        : 10.0.1.200
    Mask      : 255.255.255.255
    Port      : any

 Rule 3 ### Rule added by TCP CHEAT process based on user-url
 Inbound interface : all
 Type              : static
 Action            : permit
 Protocol          : 0
 Source:
    IP        : N/A
    Mask      : 0.0.0.0
    Port      : any
    MAC       : 0000-0000-0000
    Interface : any
    VLAN      : 22
 Destination:
    IP        : 10.0.1.113
    Mask      : 255.255.255.255
    Port      : any


 Rule 4
 Inbound interface : all
 Type              : static
 Action            : redirect
 Protocol          : 6
 Source:
    IP        : 0.0.0.0
    Mask      : 0.0.0.0
    Port      : any
    MAC       : 0000-0000-0000
    Interface : any
    VLAN      : 22
 Destination:
    IP        : 0.0.0.0
    Mask      : 0.0.0.0
    Port      : 80

 Rule 5
 Inbound interface : all
 Type              : static
 Action            : deny
 Protocol          : 0
 Source:
    IP        : 0.0.0.0
    Mask      : 0.0.0.0
    Port      : any
    MAC       : 0000-0000-0000
    Interface : any
    VLAN      : 22
 Destination:
    IP        : 0.0.0.0
    Mask      : 0.0.0.0
    Port      : any

<ac1>

And the client can access the target server:

20141215-portal-free-url-3

 

These are the cleaned up traces made on the client and the server. The client trace shows 2x TCP session setup (First handled by the TCP CHEAT process, second by real server), the server trace shows only the real TCP session.

Download the 2 network traces here: 20141215-portal-free-user-url-server

Conclusion

Although not bullet-proof (client could spoof the outgoing Host string in the header using a local hosts file to match a permitted rule), this feature makes the configuration of a walled-garden portal much easier on the Unified controller.

This entry was posted in Unified Wireless and tagged , , , , , . Bookmark the permalink.

One Response to HP Unified Wireless: Portal free user-url

  1. peter says:

    This feature (often used for wechat) is very popular in china, but can be indeed very useful to allow connection to a certain site without authentication.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s