RADIUS Proxy

[Bairdo]

I've had a look into how we could use Chewie and Faucet with a wireless access point running WPA2 Enterprise.

A TP-Link Archer C7 running OpenWRT, OVS, and hostapd was used, see the 'Radius from Access Point' below for how it was configured.

What/Why

• Forward RADIUS Packets that come from another Authenticator to the Authentication Server (RADIUS Server).
• Possible way to have Faucet/Chewie control a Wireless Access Point - Apply ACLs on the Access Point,
• A naive approach would be to just blindly forward on what is received, however:
  • this would not work when proxying for multiple authenticators (the radius.ID is going to be different). - this would not be an issue if there was a different socket pair for each authenticator.
  • Can't have separate RADIUS Secrets between Authenticator and proxy (Chewie), and proxy (Chewie) and RADIUS Server.
  • Blindly forwarding allows an attacker to impersonate either the RADIUS Server or the authenticator,
    and the proxy would pass on any mess it received.

How

Basic process for proxying is:

From Authenticator to RADIUS Server:

RADIUS Request (RReq) received from Authenticator.
Validate RReq.message-authenticator.
Read any RADIUS Attributes e.g. Username, Calling Station (MAC Address), Called Station (SSID/Port).
Replace RReq.id and RReq.request-authenticator.
Recalculate RReq.message-authenticator.
Sends RReq to RADIUS Server.

From RADIUS Server to Authenticator:

RADIUS Response (RRes) received from RADIUS Server.
Validate RRes.response-authenticator, and RRes.message-authenticator.
Read any RADIUS Attributes e.g. Filter ID, Username, Calling Station.
Check the packet Code (Success/Reject).
Replace RRes.id with the original RReq.id that this RRes is response to.
Recalculate RRes.response-authenticator and RRes.message-authenticator.
Send RRes to Authenticator.

What needs to be done

Add 4 new sockets.
RADIUS Accounting needs minimal support so we can be notified of log offs.
2 (Auth & Accounting) for interface to the authenticators.
2 (Auth & Accounting) for the RADIUS Server - keeping this separate from the one forwarding the normal mode's EAP RADIUS packets will make things simpler and hopefully easier to maintain (different lifecycles).

Add tracking of original request.id, request.request-authenticator, and which authenticator it came from to be used on the reply.
And original request.id to new (forwarded) request.id.

Configuration options.

Appendix/General Notes

EAP from Access Point

Using a TPLink Wireless Router running OpenWRT with OVS, I was unable to get Hostapd to pass/take EAP packets that were generated by Chewie, and pass them onto the supplicant.
Appears that Hostapd would intercept them and not forward from Chewie to the supplicant,
or not forward them as the are not successfully connected.

RADIUS from Access Point

A patch exists to allow hostapd to connect to an OVS bridge - https://forum.archive.openwrt.org/viewtopic.php?id=59129,
but I've so far been unable to compile it with the openwrt toolchain. I've now got this patch working except there is a problem getting the name of the ovs bridge to add the interface to from /etc/config/wireless and putting it in the hostapd config is not working (see next comment).

Configured a TPLink Wireless Router running OpenWRT with OVS so that RADIUS Packets that Hostapd sends are put onto the dataplane, along with the users dataplane traffic.
Hostapd attaches the uplink to a Linux Bridge, which in turn is connected to the OVS bridge via a veth pair.
This leaves hostapd in control of the Wireless interface and can use WPA(2) (Enterprise), unencrypted traffic is then put on the dataplane via the Linux Bridge.
Two hosts on the same SSID should not be able to ping each other unless Faucet allows it (see AP Isolate below).

Note:
Not sure if/how this will work with another OpenFlow AP (e.g. An Allied Telesis AP), as I don't have access to one yet.

                                         +-------+
                                         |ETH0   |
                                +------+ |Control|
                                | ETH1 | |Plane  |
+-------------------------------------------------+
|                               +------+ +-------+|
|                                   |       .     |
|                                   |       .     |
|                                   |       .     |
|       +-----------+          +----+-----+ .     |
|       | Linux     |veth1     |          | .     |
|       | Bridge    +----------+   OVS    +^.     |
|       |           |     veth2|          |       |
|       +-----+-----+          +----------+       |
|             |                                   |
|             |                                   |
|       +-----+-----+                             |
|       |           |                             |
|       | Hostapd   |                             |
|       |           |                             |
|       +----+------+                             |
|            |                TP-Link Archer C7   |
|       +-------+                                 |
+-------------------------------------------------+
        | WLAN0 |
        +---+---+
            |
            |
            |
        +---+----+
        |Client  |
        |Android |
        +--------+

AP Isolate

Hostapd needs to be set to AP Isolate mode for Faucet to perform ACLs (we want all traffic to go via OVS).

However despite being allowed to (minimal config with no ACLs), and with ap_isolate and hairpin enabled, the two hosts on the same SSID cannot ping each other. But can ping the outside world.
(I vaguely remember a while ago (> 1 year) that they should be able to, Mohammed also says he used this successfully.)
With hairpin on, hosts fail to obtain an IP address as well.

There is an arp response sent by host B, but A never receives the response.
It is being dropped after Faucet forwards it back toward A - (veth1 & linux bridge show the packet the second time. wlan0 does not)

With ap_isolate disabled, looks like the bridging is being done by the bridge br-wifi.

Multi SSID/Radios?

Create another linux bridge like above and connect it to ovs on a different port.
RADIUS Packets all come from the first SSID's bridge, not the one associated with the SSID the client is on.

OpenWRT Packages used (list may be incomplete)

bridge
hostapd
veth
openvswitch

Logoff

RADIUS Accounting sends a 'session stop' request that contains when the user disconnects.
There are various reasons in 'Acct-Terminate-Cause',
(Idle-Timeout (occurred when I moved away), User-Request (when i turned off wifi on phone), ...)

[Bairdo]

Updated the above comment as have now got the patch here to allow the WLAN to be added to the ovs bridge. https://forum.archive.openwrt.org/viewtopic.php?id=59129

However there are two problems with this

1. Each time you reconfigure the openflow port number the WLAN gets assigned is different, ideally it would always be a constant number. This should be easy enough to change in the patch (add '-- set Interface wlan1 ofport_request=6'). would have to pass in the 6 to hostapd somehow though.

2. the Openwrt /etc/config/wireless has an option 'network_bridge' which is supposed to be translated to the hostapd.conf 'bridge' but this does not occur. In the script /lib/netifd/hostapd.sh from what i can tell this translation should occur but the $network_bridge variable is always empty. I've had a bit a play but no success.