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

classic Classic list List threaded Threaded
3 messages Options
| Threaded
Open this post in threaded view
|

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.

--
Herwin Weststrate
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

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

Alan DeKok-2
On Dec 4, 2018, at 10:35 AM, Herwin Weststrate <[hidden email]> wrote:

>
> 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

  OK...

> 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.

> 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.

> 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.html
| Threaded
Open this post in threaded view
|

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

Herwin Weststrate
On 04-12-18 19:05, Alan DeKok wrote:
>> 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.

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

I know

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