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:
After the initial connection, the user would see a connection reset:
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:
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.
About Aruba Networks 
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.