radsecproxy

radsecproxy@lists.nordu.net

72 discussions

RadSEC implementation
by Samia El Haddouti 22 Jun '18

22 Jun '18

Dear radsecproxy team, I'm Samia El Haddouti, Network Engineer at the Moroccan NREN- MARWAN. I'm the manager of eduroam service in Morocco. We would like to improve our authentication infrastructure based on RADIUS. We are looking to deploy RadSECProxy at our intuitions. Could you please share with us your experience in deploying RADSEC? Best Reagards, Samia ------------------------------- Samia El Haddouti Project Engineer CNRST- MARWAN NREN Phone: +212667679627

1 0

Radsecproxy Release Candidate 1.7.1
by Fabian Mauchle 07 May '18

07 May '18

Dear radsecproxy community, We have finally managed to sort out all the stability issues, and even got dynamic discovery to work reliably. Special thanks to Ralf Paffrath for providing all the debug and crash infos. Before we call this an official release, please help test it. Either clone the master branch on github https://github.com/radsecproxy/radsecproxy.git Or get the source archive here: https://github.com/radsecproxy/radsecproxy/releases Report any issues either on this mailing list or on github: https://github.com/radsecproxy/radsecproxy Thanks and best regards, Fabian -- SWITCH Fabian Mauchle, Network Engineer Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland Phone +41 44 268 15 30, direct +41 44 268 15 39 fabian.mauchle(a)switch.ch, http://www.switch.ch

1 0

change of maintainer
by Fabian Mauchle 08 Apr '18

08 Apr '18

Dear radsecproxy community, End of last year, Linus Nordberg started reaching out, looking for a new maintainer for radsecproxy. After a few weeks of discussion and consideration, I offered to take this job, with some help from Ralf Paffrath. Now that all pieces are in place, we can finally announce that Fabian Mauchle <fabian.mauchle(a)switch.ch> is taking over maintainership of radsecproxy. Many thanks to Linus for your efforts in all those years maintaining radsecproxy, and thanks to all who have contributed to radsecproxy. To relieve Linus from his duties, radsecproxy has moved to a new home on github (https://github.com/radsecproxy/radsecproxy), and a new website: https://radsecproxy.github.io As a last remnant, we agreed to keep this mailing list operational. Best regards, Fabian Mauchle -- SWITCH Fabian Mauchle, Network Engineer Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland Phone +41 44 268 15 30, direct +41 44 268 15 39 fabian.mauchle(a)switch.ch, http://www.switch.ch

4 3

Fw: radsecproxy v1.6.9 on mips
by Sandeep Vadiraj 24 Jan '18

24 Jan '18

________________________________ From: Sandeep Vadiraj Sent: Monday, January 22, 2018 11:41 AM To: linus(a)sunset.se Cc: Aaron Smith Subject: radsecproxy v1.6.9 on mips Hello, We are trying to build the radsecproxy for a mips platform. We are successfully able to make a cross platform build of 1.6.6 and install on the device. But when I try to make a connection to the server at the other end running 1.6.9 proxy it fails. Are these two versions compatible? [Encl. radsecproxy_ap.conf and radsecproxy_server.conf] We are just trying to get the udp traffic to pass through from the ap to the server. Another question is when we make a crossplatform build of 1.6.9 the build is successful but when we try to start the service on the mips device. It actually fails with the following error message # /usr/sbin/radsecproxy pthread_attr_setstacksize failed. Looking at the discussions in the mailing list tried adding the code below to radsecproxy.h: #define PTHREAD_STACK_SIZE 32768 +#if defined(PTHREAD_STACK_MIN) +#if PTHREAD_STACK_MIN > PTHREAD_STACK_SIZE +#undef PTHREAD_STACK_SIZE +#define PTHREAD_STACK_SIZE PTHREAD_STACK_MIN +#endif +#endif Still I could not get it working as it fails with the same error message. Is there any work around for this issue? Look forward to your earliest response. Regards, Sandeep K V

2 2

load balancing across multiple servers in realm config
by Alex Sharaz 08 Jan '18

08 Jan '18

Hi, I've got realm * { server eduroam1.york.ac.uk accountingServer eduroam1.york.ac.uk server eduroam2.york.ac.uk accountingServer eduroam2.york.ac.uk server eduroam3.york.ac.uk accountingServer eduroam3.york.ac.uk server eduroam4.york.ac.uk accountingServer eduroam4.york.ac.uk } in my radsecproxy.conf. Is ther a way to load balance auth request over all the defined servers, or is it a case of "use 1st one till it is unavailable then try the next one" ? Rgds Alex

2 2

RFC 3576 CoA Support
by Yusuf Güngör 08 Jan '18

08 Jan '18

Hi, Radius clients who are behind NAT can successfully initiate traffic to radius server over radsecproxy. Can radius server initiate traffic for CoA requests to clients which are behind NAT over radsecproxy(via already established TLS connection with the clients)?

2 1

Feature request
by Mike Richardson 18 Dec '17

18 Dec '17

Hiya, I was wondering if it was possible to add an extra configuration option to the F-TICKS code in radsecproxy? Currently 'eduroam' is hardcoded into the string. Govroam would like to be able to suggest using radsecproxy to our regional operators and enable F-TICKS to send us back logs. So having a config option where we could set the string to 'govroam' would be ideal. Thanks, Mike -- Mike Richardson Roaming Development Specialist JISC +44 161 667 4683 Govroam huntgroup: 01235 822119 Please email Govroam support (govroam(a)jisc.ac.uk) with any queries or issues. Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.

2 1

race condition when losing ssl connection
by Steffen Klemer 21 Nov '17

21 Nov '17

Hey list, at the very busy (many threads, many packets, 8 cores) DFN radsecproxy we recently got some crashes looking like #0 0x00002aeb05fffe54 in SSL_write (s=0x0, buf=0x2aeb482a1d00, num=20) at ssl_lib.c:989 No locals. #1 0x000000000040ce3c in tlsserverwr (arg=0x2aeb48177620) at tls.c:339 cnt = 0 error = <optimized out> client = 0x2aeb48177620 replyq = 0x2aeb48291e60 reply = 0x2aeb482c2190 #2 0x00002aeb06650064 in start_thread (arg=0x2aeb3212d700) at pthread_create.c:309 __res = <optimized out> pd = 0x2aeb3212d700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {47189645776640, 1280935663696751663, 0, 47190015195840, 15, 47189645776640, 4904604809065540655, 4904632170130975791}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> pagesize_m1 = <optimized out> sp = <optimized out> freesize = <optimized out> __PRETTY_FUNCTION__ = "start_thread" I think this is a race condition among 2 threads in the lines https://git.nordu.net/?p=radsecproxy.git;a=blob;f=tls.c;h=567a6be3491751cb7… and https://git.nordu.net/?p=radsecproxy.git;a=blob;f=tls.c;h=567a6be3491751cb7… (i.e. client->ssl will be nulled before SSL_write() is called ) The attached patch against 1.6.9 fixes this while trying to be non-invasive to the code flow. There is still the chance of running SSL_write on a 'broken' tls connection but this is handled by openssl and 'cnt' anyway -- one could perhaps adjust the debug message then :). The same problem exists for the dtls-case for which I don't have a test case at the moment but a patch could look exactly the same. https://git.nordu.net/?p=radsecproxy.git;a=blob;f=dtls.c;h=f8660925ab28caef… /Steffen -- DFN-Verein Steffen Klemer Alexanderplatz 1 +49 30 884299 307 10178 Berlin klemer(a)dfn.de Germany http://www.dfn.de eduroam Beratung: Tel.: 030 88 42 99 91 21 eduroam technischer Support: Tel.: 030 88 42 99 91 20 email: eduroam(a)dfn.de Fax: 030 88 42 99 370 http://www.dfn.de Vorstand: Prof. Dr. Hans-Joachim Bungartz (Vorsitzender) Dr. Ulrike Gutheil, Dr. Rainer Bockholt Geschäftsführung: Dr. Christian Grimm, Jochem Pattloch

2 3

Resolving 'server' host name again before reconnecting
by Arunashis Ghose 06 Nov '17

06 Nov '17

Hi, We have a setup where the radius server changes it's IP address (maintaining the same DNS name) every night, because a new radius server instance is created and the old one is shut down. As that happens, it seems radsecproxy fails to reconnect to the new one and keeps trying to connect to the old IP address. It doesn't try to resolve the server host name again before trying to reconnect. Is there any configuration settings which can enable this feature in radsecproxy? If not, I feel this feature should be implemented. After a few failed attempts, it should resolve server host name before connecting again. -- Cheers Arun

2 1

Re: [radsecproxy] regular expressions
by Daniel Ehlers 06 Oct '17

06 Oct '17

On 10/06/2017 01:54 AM, Daniel Ehlers wrote: > On 10/05/2017 07:55 PM, Linus Nordberg wrote: >> Hi, >> >> Running radsecproxy with `-d 5' should give you log lines like these, >> which might help debug the issue: >> >> addrealm: constructed regexp %s from %s >> >> >> And again, what's the _double_ backslashes for? > Escaping the dots, all examples in the manual are that way, and > the constructed regex strings from none regex realms > in radsecproxy.c L2073 escape them the same way. > > regards Daniel Oh gosh ... to long no real C coding. That is an escaping sequence. I think the documention is misleading in that point. He is right Alex you should remove the _double_ blackslashes .... regards Daniel >> >> Alex Sharaz <alex.sharaz(a)york.ac.uk> wrote >> Thu, 5 Oct 2017 13:15:44 +0100: >> >>> Nope still doesn't work :-( >>> A >>> >>> On 5 October 2017 at 07:57, Alex Sharaz <alex.sharaz(a)york.ac.uk> wrote: >>> >>>> I’ll double check, but think I’ve already tried that >>>> Rgds >>>> Alex >>>> >>>> Sent from my iPhone 6 plus >>>> >>>>> On 4 Oct 2017, at 20:29, Daniel Ehlers <danielehlers(a)mindeye.net> wrote: >>>>> >>>>>> On 10/04/2017 04:58 PM, Alex Sharaz wrote: >>>>>> Hi, >>>>>> I'm using radsecproxy to pass RADIUS auths from our ORPS machine to the >>>> upstream national radius proxy service . >>>>>> >>>>>> Looking at the log file I'm seeing access-rejects being sent down >>>> generating log entries of the form >>>>>> >>>>>> Oct 4 15:47:09 2017: Access-Reject for user >>>> 0234105273270593(a)wlan.mnc010.mcc234.3gppnetwork.org >>>>>> <mailto:0234105273270593@wlan.mnc010.mcc234.3gppnetwork.org> stationid >>>> 2C-0E-3D-05-37-86 from roaming0.ja.net >>>>>> <http://roaming0.ja.net> (Request Denied) to fromFR (127.0.0.1) >>>>>> >>>>>> What I'd like to do is reject these locally in radsecproxy.conf. I >>>> thought that >>>>>> >>>>>> realm /.*\\.3gppnetwork\\.org$/ { >>>>>> replymessage "Misconfigured client: Rejected by >>>> eduroam1.york.ac.uk <http://eduroam1.york.ac.uk>!"> >> } >>>>>> >>>>>> would stop these from being passed onwards. As the log entry above >>>> shows, it doesn't ! >>>>>> >>>>>> The statement is at the top of my realm statement lists with >>>>>> >>>>>> realm * { >>>>>> server roaming0.ja.net <http://roaming0.ja.net>> >> server roaming1.ja.net <http://roaming1.ja.net>> >> } >>>>>> >>>>>> at the bottom. >>>>>> >>>>>> What's wrong with my realm statement? >>>>>> Rgds >>>>>> Alex >>>>> Hi, >>>>> >>>>> plz try >>>>> >>>>> realm /@.*\\.3gppnetwork\\.org$/ { >>>>> >>>>> didn't checked that with the code, but according to [1] it looks >>>>> like you have to explicitly define a username/domain part separated by >>>> '@'. >>>>> >>>>> regards Daniel >>>>> >>>>> [1] https://software.nordu.net/radsecproxy/doc/1.6/> radsecproxy.conf.html#REALM%20BLOCK >>>>> >>>>> >>>>> _______________________________________________ >>>>> radsecproxy mailing list >>>>> radsecproxy(a)lists.nordu.net >>>>> https://lists.nordu.net/listinfo/radsecproxy> >>> >>> _______________________________________________ >>> radsecproxy mailing list >>> radsecproxy(a)lists.nordu.net >>> https://lists.nordu.net/listinfo/radsecproxy >> _______________________________________________ >> radsecproxy mailing list >> radsecproxy(a)lists.nordu.net >> https://lists.nordu.net/listinfo/radsecproxy >> > >

3 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

radsecproxy