Difference between proxying to real and virtual server in proxy-inner-tunnel
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
On Dec 4, 2018, at 10:35 AM, Herwin Weststrate <herwin@quarantainenet.nl> 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.
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
participants (2)
-
Alan DeKok -
Herwin Weststrate