9:19 a.m.
Hi,
On 24 Mar 2021, at 08:55, Paul Dekkers
<paul.dekkers(a)surf.nl> wrote:
Hi,
On 24/03/2021 06:10, Ralf Paffrath wrote:
Can you try "statusServer on” ?
Hi Paul,
Well this would be a simple
example:
server etlr1.eduroam.org {
type tls
tls edupki
}
On 23 Mar 2021, at 12:19, Paul Dekkers
<paul.dekkers(a)surf.nl> wrote:
Hi,
If you have this realm block:
realm /@.+\..+$/ {
server dynamic
server fallback.server.here
accountingResponse on
}
radsecproxy will start to send the request to fallback.server.here because the dynamic
part didn't resolve yet: it's not blocking. Only as soon as the config for the
dynamic realm is in place, when the dynamicLookupCommand had a result, it will continue
with that host.
This results in part of the conversation going via one path, part of it via another.
I can’t notice this behaviour. But maybe I misunderstand you.
What is your dynamic server block configuration? server dynamic {
type tls
statusServer on
tls edupki
dynamicLookupCommand /etc/radsecproxy/naptr-eduroam-lowercase.sh
}
What is the result?
Regards,
Ralf
realm /@.+\..+$/ {
server dynamic
server etlr1.eduroam.org
accountingResponse on
}
If I start the server fresh, the
first EAP request I do for a realm fails. The first packet is not blocking, but forwarded
to the fallback server.
Regards,
Paul
> Regards,
> Ralf
>>
>> Unless there is no fallback of course: or if the fallback is done in the lookup
script (else at the end, which is what I'm using now). So, while this not being
problematic for me ;-) I was wondering if someone else stumbled upon this, and whether we
can have the dynamic lookup blocking for the request? That would allow fallback "as
documented".
>>
>> Regards,
>> Paul
>>
>>
>> _______________________________________________
>> radsecproxy mailing list -- radsecproxy(a)lists.nordu.net
>> To unsubscribe send an email to radsecproxy-leave(a)lists.nordu.net
>
> --
> Dipl. Inform. Ralf Paffrath
> Phone: Tel.: 030 884299-0 (DFN-GS Berlin: Sekretariat)
> Mail: paffrath(a)dfn.de
> Fax: 030 88 42 99 370 | http://www.dfn.de
>
> Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
> Alexanderplatz 1, D - 10178 Berlin
> Vorstand: Prof. Dr. Odej Kao (Vorsitzender) | Dr. Rainer Bockholt | Christian Zens
> Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch
> VR AG Charlottenburg 7729NZ | USt.-ID. DE 1366/23822
>
--
Dipl. Inform. Ralf Paffrath
Phone: Tel.: 030 884299-0 (DFN-GS Berlin: Sekretariat)
Mail: paffrath(a)dfn.de
Fax: 030 88 42 99 370 | http://www.dfn.de
Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
Alexanderplatz 1, D - 10178 Berlin
Vorstand: Prof. Dr. Odej Kao (Vorsitzender) | Dr. Rainer Bockholt | Christian Zens
Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch
VR AG Charlottenburg 7729NZ | USt.-ID. DE 1366/23822
Which radsecproxy version are you running?
This happens with 1.8.1, 1.8.2 as well as 1.7.2. Did not test other versions.
This breaks "the first" authentication
for a realm.
Do you mean the first realm request is lost?