On Aug 10, 2022, at 9:51 AM, zolty <zolty@dzikakuna.net> wrote:
W dniu 10.08.2022 o 14:13, Alan DeKok pisze:
The "No tunneled reply" message is because the code expects to see certain internal structures set correctly. Just setting the reply Packet-Type doesn't work here. The "outer" challenge/response functionality does look for the reply Packet-Type, so that's why it works.
Maybe I'm missing something but if this rlm_perl module works with PAP authentication I assume that it sets proper reply Packet-Type on output (access-challange). Why eap_ttls doesn't get the same reply when module is used inside inner-tunnel?
See my explanation above. I already answered this question.
I'm testing 2 factor authentication for VPN users. It is working when VPN is using PAP as authentication protocol. User first provides his credentials and then VPN client asks for verification code (OTP).
As I said in my previous message, it is very unlikely to work.
What I was trying to achieve is to put this communicaton inside secure tunnel (EAP-TTLS/PAP) - to stop sending unencrypted user credetials over the network.
User credentials are not sent unencrypted over the network. Anyone who tells you that is lying to you. EAP-TTLS + PAP sends user credentials encrypted with TLS, just like when you use HTTPS to log into a web site. It's fine. Even in RADIUS, the passwords are not sent in clear text over the network. For a longer explanation, see: https://networkradius.com/articles/2022/04/11/is-pap-secure.html What you're trying to do won't work, and won't add any security. It's a waste of time and effort. Just use TTLS+PAP. It's fine. Alan DeKok.