Difference between proxying to real and virtual server in proxy-inner-tunnel

[Herwin Weststrate]

Given the following setup:

- Client using PEAP
- Server configured to use proxy-inner-tunnel for PEAP
- proxy_tunneled_request_as_eap disabled
- proxy-inner-tunnel assigns a fixed value to Proxy-To-Realm
- proxy.conf configured for this realm to proxy to localhost:18121
- a virtual server listening on this port, very basic configuration
- users file has user bob enabled

Using eapol_test to authenticate with user bob works fine. The debug log
shows we get a request on 127.0.0.1:18121 with User-Name bob and some
MS-CHAP-attributes. In the end we get an Access-Accept.

Now, I tried to switch to a virtual server by removing
ipaddr/port/secret from the home_server statement, and replacing it with
a virtual_server option. I would expect this to behave the same, but
instead of proxying the inner packet I get the outer packet in the
virtual server and the authentication breaks because we don't have the
inner EAP information.

I've seen this behaviour in both 3.0.15 and the current v3.0.x (commit
8ef4848c34696caa0d61003470d321974049b794). The behaviour is not what I
did expect, so I guess this is a bug. It's also a bug that is pretty to
fix without breaking backwards compatibility.

[Alan DeKok]

Post by Herwin Weststrate
- Client using PEAP
- Server configured to use proxy-inner-tunnel for PEAP
- proxy_tunneled_request_as_eap disabled
- proxy-inner-tunnel assigns a fixed value to Proxy-To-Realm
- proxy.conf configured for this realm to proxy to localhost:18121
- a virtual server listening on this port, very basic configuration
- users file has user bob enabled

OK...

Post by Herwin Weststrate
Using eapol_test to authenticate with user bob works fine. The debug log
shows we get a request on 127.0.0.1:18121 with User-Name bob and some
MS-CHAP-attributes. In the end we get an Access-Accept.

That's good.

Post by Herwin Weststrate
Now, I tried to switch to a virtual server by removing
ipaddr/port/secret from the home_server statement, and replacing it with
a virtual_server option. I would expect this to behave the same, but
instead of proxying the inner packet I get the outer packet in the
virtual server and the authentication breaks because we don't have the
inner EAP information.

Yeah. There's some additional setup required for it to work.

Post by Herwin Weststrate
I've seen this behaviour in both 3.0.15 and the current v3.0.x (commit
8ef4848c34696caa0d61003470d321974049b794). The behaviour is not what I
did expect, so I guess this is a bug. It's also a bug that is pretty to
fix without breaking backwards compatibility.

It might be possible to fix it. To be honest, I don't think anyone really uses it that much.

if you can come up with a patch, I'm prepared to look at it and integrate it. But I don't have time to do it myself.

We're fixing all of these issues by design in v4. But that's still a ways off, unfortunately.

Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.htm

[Herwin Weststrate]

Post by Alan DeKok

Post by Herwin Weststrate
I've seen this behaviour in both 3.0.15 and the current v3.0.x (commit
8ef4848c34696caa0d61003470d321974049b794). The behaviour is not what I
did expect, so I guess this is a bug. It's also a bug that is pretty to
fix without breaking backwards compatibility.

It might be possible to fix it. To be honest, I don't think anyone really uses it that much.
if you can come up with a patch, I'm prepared to look at it and integrate it. But I don't have time to do it myself.

I could have seen that answer coming. I'll try to have a look at it, but
it will take at least a week before I might have the chance to look at it.

Post by Alan DeKok
We're fixing all of these issues by design in v4. But that's still a ways off, unfortunately.

I know