Comware Portal Redirect for BYOD use

With the HP UAM BYOD Module, any new device will need to be onboarded (registered) to the network.

This onboarding process may include 1 or more steps:

  • Link the device to a User account : Requires access to BYOD Portal and login with an existing UAM or LDAP (AD) account
  • Request a certificate to access the 802.1x secured wireless network

In this article, the focus is on the step to reach the BYOD Portal.

Onboarding Network background

Since the device is unknown to UAM when it connects the first time, it should not be allowed full access, but only access to the BYOD Portal registration page. For this purpose, a limited network will be setup, which is referred to as the “Onboarding network”.

So users connecting to the BYOD Onboarding SSID will initially be placed into a dedicated Onboarding vlan. This will require a L3 Gateway device and a DHCP Scope + Relay for the Onboarding subnet.

This network (vlan) should be restricted by an ACL on the L3 gateway to allow access to the BYOD Portal only.

The BYOD Portal itself (EIP – Endpoint Intelligent Profiling Server component) will be running on the IMC UAM server or on an IMC Slave Server (my preference, since Guests do not get direct access to master IMC Server).

From the new device, the user would need to access http://ip-address-of-eip-server:8080/byod (or :80, depending on the port config).

The Challenge : Getting the user automatically on the BYOD Portal page

Now, you can try to explain users to visit this URL manually after they make a connection, but it would be easier if they would be automatically redirected to the BYOD Portal page when they open a Browser.

The Solution : Comware Portal Redirect

Comware devices have a feature which is known as Portal authentication. Basically Portal authentication means Web Authentication, so when a user tries to access the network, a Web page with username/password login will be presented.

Comware has local and remote portal authentication options:

  • With local portal authentication, a Web page with login information is running on the local device. This is a quite common solution for traditional Guest Web Access. It is still used today for example by the Comware wireless controllers (known as Unified Controllers now). It works fine, but only basic pages are supported.
  • With remote portal authentication, the Portal Web login pages are hosted by an IMC (sub)server. The advantage is more advanced pages, and possibly the same page set for multiple controllers. (in case of local portal, the pages must be manually copied between controllers).

Anyway, in both these cases, Comware had a feature already which could redirect the user traffic to either the local portal page or the IMC hosted portal page.

So the trick with BYOD is : we will not implement Portal authentication on the Comware device (remember, we are trying to use the BYOD solution!), but we can take advantage of the basic URL Redirect function of Comware to get the users to the BYOD page.

In short : no portal authentication, only the portal redirect !

No Portal Authentication ?

But since the Comware device will not perform portal authentication (only the redirect), how can a user ever come “online” ?

Well, from Comware Portal authentication point of view, it will never come online. However, after registering the device on the BYOD Portal page, the next time the device is authenticated, it will be assigned (by UAM RADIUS) to a specific byod mobile or guest vlan. These are different from the onboarding, and they do not have the Portal Redirect enabled on the L3 interfaces , so the BYOD device will be online and will be able to access resources in their final vlan.

Portal Redirect Process

Fine, so here it makes sense to understand how the Portal redirect works. These are the basic steps:

  1. Admin enables Portal authentication on the Onboarding VLAN L3 Interface, this will effectively block all traffic (default portal ACL)
  2. User connects and “should” get an address through DHCP/DHCP Relay.
  3. User opens browser, tries to access http://www.hp.com
  4. User Device will send dns request for http://www.hp.com (to DNS IP Provided by DHCP server)
  5. DNS “should” respond with public IP of http://www.hp.com (default Portal ACL will block this by default!)
  6. User Device will send TCP SYN to public IP on TCP port 80.
  7. On Comware Device, there is a TCP-Cheat process, which will spoof *all* target IP addresses and respond to the TCP SYN (for incoming traffic on TCP port 80)
  8. After TCP 3-way handshake completes (between User Device and TCP-Cheat process), User browser will send HTTP GET
  9. Comware TCP-Cheat will respond with an HTTP ‘moved’ message, which will point the the URL set by the Administrator (for byod setup : http://ip-of -eip:8080/byod for example)
  10. User Browser “should” now connect to the ip-of-eip and show BYOD page (default Portal ACL will block this by default!)

Portal Free-rule Exceptions

Some things to remember here:

  • There is no DNS hi-jack, so DNS must work ! We will need to make sure that DNS Server is reachable. This will be the first exception rule for the default Portal ACL.
  • Initial DHCP will work by default if you configure DHCP Relay, since this initial Address assignment is broadcast based. The DHCP Renewal however, is a unicast exchange between the user device and the DHCP Server. Again, we will need an exception rule for the default Portal ACL.
  • For simple testing, from the user device a connection to http://1.1.1.1 should always work (since it does not rely on DNS)

These exceptions are called “portal free-rules”. Depending on firmware version and hardware, these will be very basic (src/dst IP based) or will support also TCP filtering (would be preferred).

Configuration example for Comware5 device

First we need to define a Portal Server object (this IP will be permitted in the Portal ACL).
The BYOD Portal would run on 10.0.1.100 in this example.

<comware5>sys
System View: return to User View with Ctrl+Z.
[comware5]portal server uam ip 10.0.1.100 url http://10.0.1.100:8080/byod

Enable portal server on Onboarding VLAN Interface, this will activate the default Portal ACL (deny all, redirect tcp port 80 to TCP-Cheat)

[comware5]interface Vlan-interface 21
[comware5-Vlan-interface21]portal server uam method layer3
[comware5-Vlan-interface21]quit
[comware5]

Enable the port free-rule with exceptions (IP addresses which must be reachable : DHCP Server for unicast DHCP Renew, DNS Server IP)
In this example IP 10.0.1.111 would be DHCP and DNS.

[comware5]portal free-rule 10 source any destination ip 10.0.1.111 mask 32

Configuration example for Comware7 device

This example was made with the HP VSR (Virtual Service Router), which is using Comware7.

Like Comware5 config, we need to define a Portal Server object (this IP will be permitted in the Portal ACL).

<comware7>sys
System View: return to User View with Ctrl+Z.
[comware7]portal web-server uam
[comware7-portal-websvr-uam]url http://10.0.1.100:8080/byod
[comware7-portal-websvr-uam]quit

Enable portal server on Onboarding VLAN Interface, this will activate the default Portal ACL (deny all, redirect tcp port 80 to TCP-Cheat)

[comware7]interface Vlan-interface 21
[comware7-Vlan-interface21]portal enable method direct
[comware7-Vlan-interface21]portal apply web-server uam
[comware7]

Enable the port free-rule with the exceptions (IP addresses which must be reachable : DHCP Server for unicast DHCP Renew, DNS Server IP)
In this example IP 10.0.1.111 would be DHCP and DNS and the UDP port 67 and 53 can be used for DHCP and DNS filtering.

[comware7]portal free-rule 20 source ip any destination ip 10.0.1.111 32 udp 67
[comware7]portal free-rule 30 source ip any destination ip 10.0.1.111 32 udp 53

Conclusion

So it does not matter if you are implementing the HP BYOD with MSM or Unified Wireless controllers, a Comware Portal Redirect device is always required for the onboarding redirect. This can be done by an existing Comware device, or through the VSR running on an ESXi host.

This entry was posted in Comware5, Comware7, IMC UAM and tagged , , , , . Bookmark the permalink.

19 Responses to Comware Portal Redirect for BYOD use

  1. Osama.R says:

    Thank you Peter for the detailed explanation,I have a scenario which is pretty similar to what you described and that is as:
    IMC deployed in distributed mode ( Base Platform on one Server, UAM on another, Remote DB/MS SQL Server )
    MSM Controller for wireless Users
    MSR 3040 for Portal Redirection

    Now Portal Redirection is working perfectly fine and has the free Rules added to both IMC servers,DNS and DHCP.

    The SSID is Guest which is MAC-Based Auth, Any user will be redirected to BYOD page and is assigned onboarding VLAN, depending on existing user(LDAP) or self-account register (Guest) user is registered to the cosponsoring VLAN

    The issue:
    Users are able to redirect to the BYOD page and register but the only behavior i need to know if the user moves from onboarding to Guest Vlan by itself or he needs to deassoicate and re-associate which makes no sense.
    In my case, i have to register, then on the same page i authenticate and nothing happens after which i disconnect and connect again to same SSID and now i am connected to Guest VLAN.

    One thing i noticed, while discovering MSM via SNMP on the Base platform, i cannot see any SOAP service inside the configure tab while if i do the same in Centralized IMC (LAB setup) i can view it. Do you know if this is SOAP service on MSM is responsible for moving the user from Onboarding to Guest/Corp VLAN?

    • The vlan assignment is part of the radius access-accept packet, which is sent at the time the authentication takes place.
      When the guest initially makes a connection, the mac is unknown, so the mac-auth is based on the byodanonymous account (and the associated Access Service).

      After the user registers the device, the client device mac address will be linked to the user account, so any future authentication attempts will be processed based on the Access Service associated with the user account. That user Access Service will push the user vlan when the user authenticates.
      The key part is to understand that the new authorization information will only take effect at the next authentication attempt (since the vlan is delivered through the radius access accept).

      There is a Radius standard which allows for the dynamic (radius based) update of the session authorization parameters. This is called CoA (change of authorization). So when the Radius server (UAM) knows that settings have been changed (e.g. when user registers a device), it can push the new vlan or ACL to the access device (radius client).

      Depending on the implementation, the access device will perform re-authentication (which will trigger the new access-accept) or it could apply the new authorization parameters(vlan/acl) on the fly to the existing session.

      In case of the MSM however, CoA is not supported, so a different mechanism had to be used to ensure the user is assigned to the new vlan.
      The MSM supports a SOAP API, which can be used for all kinds of administrative actions (like defining guest users : the MSM Guest Managemenent Software is an example of an application that uses the SOAP interface).
      One of the actions which can be done through the SOAP API is a wireless user disassociate (based on the client mac). Once a wireless user has been disassociated, the client device will try to reconnect, which will trigger a new authentication attempt (and this will result in the new vlan being assigned to the user).

      For the MSM Wireless controllers, the UAM team has implemented this SOAP API in order to have a triggered user disassociated.

      On the MSM Controller, you need to enable the SOAP interface (under management), but SOAP over HTTPS is not supported, so that must be disabled.
      The SOAP settings in IMC are not defined on the platform device, but under the UAM Access Device (radius client). When the MSM Access Device is opened and the device type is set to HP(General) (this is required for MSM!) the SOAP settings can be configured.

      Once this is done, the user will be disassociated after registering a device, and will be reauthenticated and assigned to the new vlan. It just takes 10-30 seconds for the client device to release/renew the IP address for the new subnet.
      On the MSM Controller, you can use the System Log (Unfiltered) to verify if the SOAP disassociate was executed.

  2. Osama.R says:

    Thanks a lot Peter for the descriptive reply. Your explanation solved the issue within seconds: )
    Want to ask one more Question regarding dot1x User Authentication, Windows 7 users are connecting to dot1x SSID with single sign-on and they are passing login credentials in windows format: MS\john. UAM takes “MS\john” as Login and it fails instantly. By modifying SSID profile, when we input the user manually without domain it solves the issue. On the UAM i have tried the following:

    1. Under Service Parameters -> System Settings -> System Parameters -> Username Prefix Conversion Mode : Change to suffix/Remove ( Tried Both )
    2. LDAP Service : LDAP Server : Account Format : Remove Prefix/Unchanged ( Tried Both )
    3. Under Domain Assisted PEAP Authentication : Changed Operating System to Windows Server 2003 or earlier

  3. Rick says:

    You are amazing! Keep up the good work!

  4. Daniel says:

    Peter

    I have a problem, when connect to the network and redirect to the page of byod the message is “The user is not online”. Always the same message with any device.

    You know why?

    Regards

    • Hi Daniel,

      I have had this as well, for me it always happened to be one of these issues:
      * DHCP Server did not have the UAM plugin installed (or plugin was not properly configured/not started).
      This is required, since the pluging will allow the mapping of the user MAC (learned through radius accounting) to the user IP (the incoming source IP on the BYOD portal).
      * The authenticating device (controller/switch) was not configured with radius accounting to the UAM server.
      * The device accessing the BYOD portal had both a wired and wireless connection, and the session to the BYOD was done using the wired connection.
      The result is that the source IP of the incoming connection on the BYOD portal cannot be mapped to the user online MAC address.

      I hope one of these helps for you !

      • Daniel says:

        Hi Peter, thanks for your feedback

        The plugin is installed succesfully, the message is DHCP Service server is running and DHCP Agent is working.

        I,m not sure about my controller Unified 830 is configured with radius accounting, how will i do that?

        Regards

      • Hi Daniel,

        this would a sample configuration to activate a guest SSID with MAC-authentication using the IMC UAM RADIUS for authentication, authorization and accounting.

        Sample includes 1 VLAN, create more VLANs are required by your setup.

        #
        port-security enable
        #
        vlan 19
        #
        radius scheme uam
        server-type extended
        primary authentication 10.0.1.100
        primary accounting 10.0.1.100
        key authentication simple hp
        key accounting simple hp
        user-name-format without-domain
        #

        domain uam
        authentication default none
        authorization default none
        accounting default none
        authentication lan-access radius-scheme uam
        authorization lan-access radius-scheme uam
        accounting lan-access radius-scheme uam
        #
        mac-authentication domain uam
        #
        interface WLAN-ESS19
        port link-type hybrid
        undo port hybrid vlan 1
        port hybrid vlan 19 untagged
        port hybrid pvid vlan 19
        mac-vlan enable
        port-security port-mode mac-authentication
        #

        wlan service-template 19 clear
        ssid sample-unified-guest
        bind WLAN-ESS 19
        service-template enable
        #

  5. Daniel says:

    Thanks Peter,

    Oh yes this had alredy configured, but in the IMC not have to configure anything for this authentication?

    Regards

    • Hi Daniel,

      you should have the normal byod/uam configuration applied on UAM:
      * create access device (radius client) – make sure correct IP address and secret are used (check with wireshark in case of doubt)
      * create an access policy for the byod onboarding vlan (no special auth (like eap), it will access mac-auth/PAP by default)
      * create an access service which contains this access policy
      * bind the byodanonymous user to the access service

      Can also enable more logging under the UAM system log settings.
      This will generate more info in a log file on the IMC server, in the uam\log folder.
      It is kind of a raw log file, but you can find lots of info in there.

  6. Sherwin says:

    Hi Daniel,

    This is my first time to implement HP BYOD solution and i have followed a guide from HP website, specifically, from the UAM BYOD configuration guide. My objective is to perform an auto guest registration.

    My issue is that after I managed to connect to the test SSID then obtain an IP address, I am redirected to a login page that has no other option but to use an existing account.

    Appreciate your help in advance.

    Thanks,
    Sherwin

  7. cartik says:

    Hi Peter,

    When I have the below command on the Unified controller, by client are not able to connect to the SSID.

    port-security port-mode mac-authentication

    “interface WLAN-ESS0
    port link-type hybrid
    undo port hybrid vlan 1
    port hybrid vlan 100 to 101 untagged
    port hybrid pvid vlan 101
    mac-vlan enable
    port-security port-mode mac-authentication

  8. cartik says:

    Got is working, thanks

  9. NeilR says:

    Does the comware portal redirect entry have to be specifically on the L3 Gateway device or on a device connected on the same VLAN?

  10. Augusto says:

    i am having one trouble. all is configured correctly, but when the guest is moved to the portal captive appears ” timeout in connection” would you know what could be ? below the configuration:
    version 5.20.109, Release 2607P32
    #
    sysname HP
    #
    clock timezone Brasilia minus 03:00:00
    #
    dhcp relay server-group 1 ip 172.17.3.12
    #
    radius trap authentication-error-threshold
    radius log packet
    #
    domain default enable system
    #
    dns resolve
    dns proxy enable
    dns server 172.18.46.2
    dns source-interface Vlan-interface3
    #
    telnet server enable
    #
    port-security enable

    portal server spdm ip 172.17.3.12 url http://172.17.3.12:8080/byod
    portal free-rule 30 source ip any destination ip 172.17.3.12 mask 255.255.255.255
    portal free-rule 31 source ip any destination ip 172.17.3.254 mask 255.255.255.255
    #
    ip http acl 199
    #
    mac-authentication timer offline-detect 60
    mac-authentication timer quiet 15
    mac-authentication domain hgg
    #
    wlan country-code US
    #
    wlan auto-ap enable
    wlan auto-persistent enable
    #
    password-recovery enable
    #
    acl number 199
    rule 65534 deny

    vlan 1
    #
    vlan 3
    description vlan portal
    #
    vlan 11
    #
    vlan 13
    description vlan rede notebook
    #
    vlan 14
    description vlan rede movel
    #
    vlan 15
    description vlan guest
    #
    vlan 20
    #
    vlan 58
    description rede wirelless notebook
    #
    vlan 59

    vlan 60
    description rede portal guest
    #
    vlan 61
    description rede guest
    #
    vlan 62
    #
    radius scheme brigadeiro
    server-type extended
    primary authentication 172.17.3.12
    primary accounting 172.17.3.12
    key authentication cipher $c$3$5Wl6413foeKjkaZkf47HLn+WD7Ur9KqYpsE=
    key accounting cipher $c$3$j4+W7qIfzpPywexsBceUCO9dBAyGc0Rgd/w=
    user-name-format without-domain
    #
    domain hgg
    authentication default none
    authorization default none
    accounting default none
    authentication lan-access radius-scheme brigadeiro
    authorization lan-access radius-scheme brigadeiro
    —- More —-
    accounting lan-access radius-scheme brigadeiro
    access-limit disable
    state active
    idle-cut disable
    self-service-url disable
    domain system
    access-limit disable
    state active
    idle-cut disable
    self-service-url disable
    #
    pki domain hgg
    crl check disable
    #
    pki domain spdm
    #
    user-group system
    group-attribute allow-guest
    #
    local-user 00-fe-12-34-56-78
    password cipher $c$3$lSRexWPdXvbwvSGAUwVEZ7ZjsPSdncmlk4klJQeKrgPKn0nO
    service-type lan-access
    local-user 48-86-e8-88-c5-24

    password cipher $c$3$lSRexWPdXvbwvSGAUwVEZ7ZjsPSdncmlk4klJQeKrgPKn0nO
    service-type lan-access
    local-user 48-86-e8-88-c5-24
    password cipher $c$3$s4oDn1fXg5+wYh5uk5sbgjdZdPQceUy8tEbv5VS+2ibMHynw
    service-type lan-access
    local-user admin
    password cipher $c$3$sN2dqFNGIaQZyu/BcFrYYpWxc0up5zPX
    authorization-attribute level 3
    service-type ssh telnet
    service-type web
    #
    wlan guest-tunnel aggregation-ac
    #
    wlan rrm
    dot11a mandatory-rate 6 12 24
    dot11a supported-rate 9 18 36 48 54
    dot11b mandatory-rate 1 2
    dot11b supported-rate 5.5 11
    dot11g mandatory-rate 1 2 5.5 11
    dot11g supported-rate 6 9 12 18 24 36 48 54
    dot11a calibrate-power threshold 80
    dot11bg calibrate-power threshold 80

    wlan service-template 1 crypto
    ssid SPDM MOVEL
    bind WLAN-ESS 0
    cipher-suite ccmp
    security-ie rsn
    ptk-lifetime 604800
    client forwarding-mode local
    service-template enable
    #
    wlan service-template 2 crypto
    ssid SPDM NOTEBOOKS
    bind WLAN-ESS 1
    cipher-suite ccmp
    security-ie rsn
    gtk-rekey method time-based 604800
    client forwarding-mode local
    service-template enable
    #
    wlan service-template 3 clear
    ssid SPDM VISITANTES
    bind WLAN-ESS 2
    service-template enable
    #
    ssl server-policy spdm
    pki-domain spdm
    ssl server-policy hgg
    pki-domain hgg
    #
    interface NULL0
    #
    interface Vlan-interface1
    ip address 172.17.1.254 255.255.255.0
    #
    interface Vlan-interface3
    ip address 172.17.3.254 255.255.255.0
    #
    interface Vlan-interface11
    #
    interface Vlan-interface13
    #
    interface Vlan-interface20
    —- More —-
    interface Vlan-interface60
    ip address 172.17.60.254 255.255.255.0
    dhcp select relay
    dhcp relay server-select 1
    portal server spdm method direct
    #
    interface Vlan-interface61
    ip address 172.17.61.254 255.255.255.0
    #
    interface Vlan-interface62
    ip address 172.17.62.254 255.255.255.0
    #
    interface GigabitEthernet1/0/1
    port link-type hybrid
    port hybrid vlan 3 58 to 62 tagged
    port hybrid vlan 1 untagged
    port hybrid pvid vlan 3
    #
    interface GigabitEthernet1/0/2
    port link-type hybrid
    undo port hybrid vlan 1
    port hybrid vlan 3 58 to 62 tagged
    —- More —-

    interface WLAN-ESS0
    port link-type hybrid
    port hybrid vlan 1 untagged
    port hybrid pvid vlan 59
    mac-vlan enable
    port-security port-mode psk
    port-security tx-key-type 11key
    port-security preshared-key pass-phrase cipher $c$3$ww5nXpLTRpXVRtDNVvZXmwJiPwoNAWKt3axLMOcQwBcO
    #
    interface WLAN-ESS1
    port link-type hybrid
    port hybrid vlan 1 untagged
    port hybrid pvid vlan 58
    mac-vlan enable
    port-security port-mode psk
    port-security tx-key-type 11key
    port-security preshared-key pass-phrase cipher $c$3$C8a3wAs3WAVIAJ4u1XIAfgocl+LwQH84WpjD8a8EBIGj

    interface WLAN-ESS2
    port link-type hybrid
    port hybrid vlan 1 untagged
    port hybrid pvid vlan 61
    mac-vlan enable
    port-security port-mode mac-authentication
    mac-authentication domain hgg
    #
    nqa entry imclinktopologypleaseignore ping
    type icmp-echo
    destination ip 172.17.3.253
    frequency 270000
    #
    wlan ap-group default_group
    ap ap1_dir
    ap ap2_dir

    nqa entry imclinktopologypleaseignore ping
    type icmp-echo
    destination ip 172.17.3.253
    frequency 270000
    #
    wlan ap-group default_group
    ap ap1_dir
    ap ap2_dir
    #
    wlan ap ap1_dir model MSM430-AM id 4
    map-configuration apcfg.txt
    serial-id CN3ADWY0RT
    radio 1
    service-template 1 vlan-id 59
    service-template 2 vlan-id 58
    service-template 3
    radio enable
    radio 2
    service-template 1 vlan-id 59
    service-template 2 vlan-id 58
    service-template 3
    radio enable

    wlan ap ap2_dir model MSM430-AM id 3
    map-configuration apcfg.txt
    serial-id CN41DWY0BK
    radio 1
    service-template 1 vlan-id 59
    service-template 2 vlan-id 58
    service-template 3
    radio enable
    radio 2
    service-template 1 vlan-id 59
    service-template 2 vlan-id 58
    service-template 3
    radio enable
    #
    wlan ips
    malformed-detect-policy default
    signature deauth_flood signature-id 1
    signature broadcast_deauth_flood signature-id 2
    signature disassoc_flood signature-id 3
    signature broadcast_disassoc_flood signature-id 4
    signature eapol_logoff_flood signature-id 5
    —- More —-

    signature broadcast_deauth_flood signature-id 2
    signature disassoc_flood signature-id 3
    signature broadcast_disassoc_flood signature-id 4
    signature eapol_logoff_flood signature-id 5
    signature eap_success_flood signature-id 6
    signature eap_failure_flood signature-id 7
    signature pspoll_flood signature-id 8
    signature cts_flood signature-id 9
    signature rts_flood signature-id 10
    signature addba_req_flood signature-id 11
    signature-policy default
    countermeasure-policy default
    attack-detect-policy default
    virtual-security-domain default
    attack-detect-policy default
    malformed-detect-policy default
    signature-policy default
    countermeasure-policy default
    #
    ip route-static 0.0.0.0 0.0.0.0 172.17.3.250

    snmp-agent
    snmp-agent local-engineid 8000000B034431924278DC
    snmp-agent community read public
    snmp-agent community write private
    snmp-agent sys-info contact lab
    snmp-agent sys-info location lab
    snmp-agent sys-info version v2c v3
    snmp-agent target-host trap address udp-domain 172.17.3.12 params securityname public v2c
    snmp-agent target-host trap address udp-domain 172.17.3.13 params securityname v2c
    #
    nqa schedule imclinktopologypleaseignore ping start-time now lifetime 630720000
    #
    ssh server enable
    #
    ip https acl 199
    ip https ssl-server-policy hgg
    ip https enable

    user-interface con 0
    user-interface vty 0 4
    acl 199 inbound
    authentication-mode scheme
    user privilege level 3
    #

  11. suhaimi says:

    I go trough the step. But i still have problem when the client open browser request eg: http://www.google.com it’s not redirect to byod page.

    But still can use manual http://ip_address:8080/byod/

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