HP Unified Wireless: Portal authentication for extended Layer2 guest subnet

This post covers the HP Unified Wireless controller (AC) portal configuration in a scenario of an extended L2 guest subnet configuration.

There are 2 scenario’s to handle guest IP subnets:

  • A new IP subnet, where the AC is the default gateway, performs portal authentication and then routes/NATs the guest traffic to the internet.
  • An existing IP subnet, provided by an existing guest Internet router. The guest internet router will provide DHCP and NAT services for the guests. The AC just needs to provide portal authentication services. Guests who have passed portal authentication, will be L2 forwarded by the AC (not routed).

This post covers the second scenario: Extending the external internet router IP subnet as the guest subnet.

Overview of the configuration steps

  • Configure the external guest VLAN to the AC
  • Configure an open Guest WLAN, it should egress to the VLAN in which the external guest Internet router is connected.
  • Configure the AC with an IP interface in this VLAN
  • Enable portal authentication on this VLAN
  • Configure a portal-free rule for outbound DNS
  • Configure a portal-free rule for default inbound return traffic (from guest internet router)
  • Verify ACL to block wireless users to access the AC web interface
  • Activate ACL to prevent any other management access to the AC guest IP

The example assumes there is a VLAN4001 in the network, there is a guest internet router connected to this VLAN4001. The guest internet router provides DHCP and NAT services to the internet.

The IP subnet of the guest internet router is
The guest internet router has IP

Configuration steps

Configure the external guest VLAN to the AC. This is the VLAN4001.

In this example, I assume that an 830 controller is used. The 830 consists of an internal AC and a L2 switch (2 devices in 1). They are internally interconnected on a default link-agg (BAGG1).

Suppose you connect the guest internet router on G1/0/8 of the 830 switch:

### on the Switch Engine of the 830 ###
 # if you have a console connection on the 830, use 
 # the "oap connect slot 0" command to access the switch console
vlan 4001

 # configure the access port to the internet router
interface g1/0/8
 description External-Guest-Internet-Router
 port access vlan 4001

 # enable the vlan to pass the BAGG to the AC
int bagg1
 description Uplink-to-the-830-AC
 port link-type trunk
 port trunk permit vlan 4001

Now enable the vlan on the 830-AC

### on the AC Engine of the 830 ###
 # use CTRL-K to return from the switch console to the AC console
vlan 4001

 # enable the vlan to pass the BAGG to the Switch Engine
int bagg1
 description Uplink-to-the-830-SW
 port link-type trunk
 port trunk permit vlan 4001

Configure an open Guest WLAN, it will be a central forwarding WLAN,  pushing guests into VLAN4001

 # define the virtual L2 interface for the wireless clients
interface WLAN-ESS21
  # assign it as access port to VLAN 4001
 port access vlan 4001

 # define the wlan template as open ssid
wlan service-template 21 clear
 ssid Guests
 bind WLAN-ESS 21
 service-template enable

Now configure the AC with an IP interface in this external guest VLAN. Make sure this IP address will not be assigned to guests by the guest internet router DHCP server.

interface Vlan-interface4001
 description Guest-internet-portal
 ip address

Verify connectivity to the external guest internet router


Enable a local portal server and portal authentication for this interface

 # enable the local portal server 
portal local-server http

 # define a portal server target object, which points to the local IP
portal server local ip

 # enable portal authentication on the L3 VLAN 4001 interface
interface Vlan-interface4001
 portal server local method layer3

The previous step will immediately block all outgoing traffic for guest users. This will include the DNS traffic of the guest users. You need to make sure that guest DNS is operating, since the portal redirect uses a TCP hijack mechanism. There is no DNS spoofing implemented for the portal redirect.

If you know the IP address of the DNS Server that will be assigned by the guest internet router DHCP server to your guests, you can configure it (this example assumes the google DNS server is given to clients)

Otherwise, you could permit all UDP 53 traffic to pass without portal authentication.

portal free-rule 10 source ip any destination ip mask udp 53

This will allow traffic from guests to the internet.

Now keep in mind that the portal authentication is using hardware ACLs, so this is not  a stateful mechanism. From the AC point of view, the return DNS traffic will be entering the AC from the BAGG1 interface and going to the guest user.

Since we only want to control wireless guests (coming in on the WLAN-ESS21 interface) traffic to the internet (going out on the BAGG1 interface), we can simply permit traffic from the internet (coming in on the BAGG1) as  a free rule. This will ensure that the DNS reply will actually make it back to the client when authentication has not been done yet.

portal free-rule 20 source interface Bridge-Aggregation1 destination any

This is all you need to do to get the L2 pass-through working on the Unified Controller.

IP Access Control for guests

The next steps are included to ensure the guest portal IP interface cannot be used by a guest to attempt internal network access and/or management of the controller.

Access restriction options:

  • Management ACL which blocks wireless users
  • Portal forbidden rule to block routed access to internal network
  • Firewall ACL on the IP interface to block management and routed access to internal network

Management ACL blocking wireless users (default)

By default, the AC has a WLAN ACL which simply rejects all WLANs:

acl number 199
 rule 65534 deny

This ACL is by default bound to the HTTP,HTTPS and VTY interfaces:

ip http acl 199
ip https acl 199
user-interface vty 0 4
 acl 199 inbound

This will ensure guests cannot access the HTTP/HTTPS/telnet/ssh interfaces of the AC. Keep in mind that SNMP would still be open, so another ACL will be required.

Portal forbidden rule to block routed access to internal network

The AC has ip routing enabled by default (cannot be disabled). The guest user will by default get an IP Address and the default gateway from the external DHCP server.  But if a guest user would now make a static route on his local system, he could use the AC IP address of the VLAN 4001:

 # Example manual route on a Windows guest system
route add mask

While it is unlikely that the guest IP subnet will be known on your internal network (so no route back exists), it would still allow a guest to transmit (not receive, since no internal route will exist for the subnet) into your internal network. This should be prevented.

A simple mechanism would be to use the portal forbidden rule:

portal forbidden-rule 10 destination ip mask

The forbidden rules are always effective, so they apply to both authenticated and non-authenticated users. This would prevent the fact that guest users can transmit data into your network (assuming you have a 10/8 network internally).

Firewall ACL on the IP interface to block management and routed access to internal network

With this last step, we will ensure on the L3 VLAN4001 interface, only TCP 80 is allowed to the local IP address. This will prevent:

  • Guest attempts to route traffic to the internal network
  • Guest attempts to use management interface not protected by the default ACL199 (like SNMP!)


 # Enable the firewall at global level
firewall enable

 # define an ACL which only accepts TCP 80 on the Portal IP
 # Portal IP is based on this example configuration (see earlier)
 # all other traffic is dropped (preventing snmp/routed access)
acl number 3001
 rule 0 permit tcp destination 0 destination-port eq www
 rule 20 deny ip
 # activate the ACL on the Portal L3 interface
interface Vlan-interface4001
 firewall packet-filter 3001 inbound

This concludes the Portal configuration with an external guest router/dhcp server.

This entry was posted in Unified Wireless. Bookmark the permalink.

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