Re: Freeradius DHCP IP pool and not correct port for DHCP
Hi,
Hello Rui
1) Could it be some problem with internal firewall, AppArmor or SELinux? No problem in this side
2) How you are doing the relay? I was auditing our relay with our Cisco Firewall recently and found some nasty side effects due to some lack of understanding of the relay process when configuring the firewall. My DHCP client is behind an IAD with relay the DHCP packet to Freeradius. For the 1st DHCP flow (Discovery-Offer-Request-ACK), everything is OK because it is a broadcast packet.
When the renewal DHCP packets are send using unicast, my client try to reach FreeRadius. he send DHCP request using his IP address with source port 68 and the freeradius IP Address with destinatio port 67. My IAD source pat the flow using a dynamic random port. I received the DHCP packet with source port 10.239.0.2.55175 but the freeradius not replied to 55175 but to 67. The firewall included on the box is statefull and so I dropped the reply DHCP packet. I don't understand why Freeradius will not reply to the initial source port ?
3) This packet trace is not evidently the first requests, but a renewal? You're true, i see the problem only on the renewal (When 50% of the lease time have been reached).
Regards, Rui Ribeiro
Thanks for your help Thomas Cordialement, Thomas BRU Ingénieur Réseaux & Télécoms Pôle Ingénierie Tél. 02 72 73 59 96 tbru@afone.com AFONE - 11, place François Mitterrand - CS 11024 - 49055 ANGERS cedex 02 [t] 0825 168639 - [f] 0820 160 329 - ou composez le 3213 et dites « AFONE » ----- Mail original ----- De: freeradius-users-request@lists.freeradius.org À: freeradius-users@lists.freeradius.org Envoyé: Mercredi 2 Avril 2014 10:08:21 Objet: Freeradius-Users Digest, Vol 108, Issue 8 Send Freeradius-Users mailing list submissions to freeradius-users@lists.freeradius.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.freeradius.org/mailman/listinfo/freeradius-users or, via email, send a message with subject or body 'help' to freeradius-users-request@lists.freeradius.org You can reach the person managing the list at freeradius-users-owner@lists.freeradius.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Freeradius-Users digest..." Today's Topics: 1. Re: Freeradius DHCP IP pool and not correct port for DHCP reply - Re: Freeradius-Users Digest, Vol 108, Issue 6 (Rui Ribeiro) 2. 1. Re: Wildcard SSL Certificates (Angel Franch) - Re: Freeradius-Users Digest, Vol 108, Issue 6 (Rui Ribeiro) 3. Re: use freeeradius 3.0.2 with sqlite fail when loading modules (Arran Cudbard-Bell) 4. Re: panic_action / ptrace: Operation not permitted (Stefan Winter) 5. RE: 3.0.2 / possible bug when proxying with no response from home server (Chaigneau, Nicolas) ---------------------------------------------------------------------- Message: 1 Date: Wed, 2 Apr 2014 06:07:32 +0100 From: Rui Ribeiro <ruyrybeyro@gmail.com> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: Freeradius DHCP IP pool and not correct port for DHCP reply - Re: Freeradius-Users Digest, Vol 108, Issue 6 Message-ID: <CAGnR_r9pGzqvMRZu3T38vvieQWBWv6QA9pSSNP5wEt4JUWisqg@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Hi, 1) Could it be some problem with internal firewall, AppArmor or SELinux? 2) How you are doing the relay? I was auditing our relay with our Cisco Firewall recently and found some nasty side effects due to some lack of understanding of the relay process when configuring the firewall. 3) This packet trace is not evidently the first requests, but a renewal? Regards, Rui Ribeiro
Message: 4 Date: Tue, 01 Apr 2014 14:32:52 -0400 From: Alan DeKok <aland@deployingradius.com> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: Freeradius DHCP IP pool and not correct port for DHCP reply Message-ID: <533B0654.8060306@deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1
Thomas Bru wrote:
On the Bug fixes list , I see the problem was solved using Freeradius 3.0.4 (http://freeradius.org/version3.html, Use correct port when DHCP relaying, ) So I reinstall the Freeradius 3.0.4 on my server but the problem is still present and my server dropped the packets.
17:42:23.875867 IP 10.239.0.2.55175 > 10.225.2.8.67: BOOTP/DHCP, Request from c9:31:cf:d8:af:ec, length 308 17:42:23.932246 IP 10.225.2.8.67 > 10.239.0.2.67: BOOTP/DHCP, Reply, length 300
AS you can see, the request packet from 10.239.0.2 with source port 55175 but will go back to 10.239.0.2 BUT with 67 port.
The correct destination port for DHCP relay packets is 67.
What exactly do you think the problem is?
Alan DeKok.
-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freeradius.org/mailman/private/freeradius-users/attachments/20140402/6d8654f2/attachment-0001.html> ------------------------------ Message: 2 Date: Wed, 2 Apr 2014 06:26:57 +0100 From: Rui Ribeiro <ruyrybeyro@gmail.com> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: 1. Re: Wildcard SSL Certificates (Angel Franch) - Re: Freeradius-Users Digest, Vol 108, Issue 6 Message-ID: <CAGnR_r-TAQMA9o8QGfL4OuRQ5AYn5_NLHmGHVyeKoTRh3XNM=Q@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Hi, Yeah, I also can confirm wildcards dont work with TTLS, never tested them with PEAP. The PEAP code seems to be much more forgiving, TTLS took longer to work, without ticking off the option to ignore the checks of the client certificate on the Windows client. Regards
Message: 1 Date: Tue, 1 Apr 2014 18:14:57 +0200 From: Angel Franch <angel.franch@cnic.es> To: freeradius-users@lists.freeradius.org Subject: Re: Wildcard SSL Certificates Message-ID: <533AE601.4000506@cnic.es> Content-Type: text/plain; charset="ISO-8859-1"
Hello all. My first post.
Windows 7 fails validating wildcard certificate using TTLS. With PEAP it works.
Angel.
On 4/1/2014 5:33 PM, Miroslav Lednicky wrote:
Hello,
We using wildcard certificate and Windows have problem with it. ;-)
Mirek
Dne 1.4.2014 15:58, Sam Fakhreddine napsal(a):
Hello,
Can we use Wildcard SSL Certificates from a third party CA with freeradius servers?
-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freeradius.org/mailman/private/freeradius-users/attachments/20140402/70443324/attachment-0001.html> ------------------------------ Message: 3 Date: Wed, 2 Apr 2014 07:31:53 +0100 From: Arran Cudbard-Bell <a.cudbardb@freeradius.org> To: "kids67.tw" <kids67.tw@yahoo.com.tw>, FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: use freeeradius 3.0.2 with sqlite fail when loading modules Message-ID: <614F4AFF-4117-42AA-AA58-F0C9FE6DD34D@freeradius.org> Content-Type: text/plain; charset="iso-8859-1" On 2 Apr 2014, at 02:33, kids67.tw <kids67.tw@yahoo.com.tw> wrote:
Dear Sir,
I complier freeradius 3.0.2 with sqlite enable and complier successful. But when I run ./radiusd -XC -d ./raddb/ then display below error
...... # Instantiating module "linelog" from file ./raddb//mods-enabled/linelog linelog { filename = "/home/saxontseng/senao_ source/ap_controller/ freeradius/install/LINUX/var/ log/radius/linelog" permissions = 384 format = "This is a log message for %{User-Name}" reference = "%{%{Packet-Type}:-format}" } ./raddb//mods-enabled/sql[26]: Failed to link to module 'rlm_sqlite': rlm_sqlite.so: cannot open shared object file: No such file or directory
And after I check I find only have "rlm_sql_sqlite.so", not find any rlm_sqlite.so.
I just modify site-enable/default and mod-available/sql, make ln to mod-enabled/sql below is my diff with those two config file
You move the sqlite section into the sql section before uncommenting it. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 881 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://lists.freeradius.org/mailman/private/freeradius-users/attachments/20140402/f75edc24/attachment-0001.pgp> ------------------------------ Message: 4 Date: Wed, 02 Apr 2014 08:55:09 +0200 From: Stefan Winter <stefan.winter@restena.lu> To: freeradius-users@lists.freeradius.org Subject: Re: panic_action / ptrace: Operation not permitted Message-ID: <533BB44D.40908@restena.lu> Content-Type: text/plain; charset="iso-8859-1" Hi,
It works fine for me on OSX (10.9.1) and the the yama detection disabled on ubuntu 13.07.
We've used it at customer sites to send out automatic emails when the hosts have gone down with the backtraces, and it seems to work there too (ubuntu 12.04).
Not really sure what else to suggest, sorry.
Well, I found it now :-) My config had security.allow_core_dumps = no. As it happens, that setting is entangled with panic_action's gdb attach. allow_core_dumps modifies PR_SET_DUMPABLE. From the man page of prctl: "PR_SET_DUMPABLE (since Linux 2.3.20) [... bla bla ...] Processes that are not dumpable can not be attached via ptrace(2) PTRACE_ATTACH." So, my bad for producing an inconsistent configuration ;-) It would be very nice if the comments near panic_action could give users a hint though "If your panic_action uses gdb attach (such as the examples below), remember to allow core dumps for this to work (security.allow_core_dumps)." That would avoid some amount of guesswork :-) Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R?seau T?l?informatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x8A39DC66.asc Type: application/pgp-keys Size: 3243 bytes Desc: not available URL: <http://lists.freeradius.org/mailman/private/freeradius-users/attachments/20140402/e4710a2b/attachment-0001.key> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: <http://lists.freeradius.org/mailman/private/freeradius-users/attachments/20140402/e4710a2b/attachment-0001.pgp> ------------------------------ Message: 5 Date: Wed, 2 Apr 2014 08:07:39 +0000 From: "Chaigneau, Nicolas" <nicolas.chaigneau@capgemini.com> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: RE: 3.0.2 / possible bug when proxying with no response from home server Message-ID: <AB94B0B675BDF14189CD5A861DB36C84134C80D1@DE-CM-MBX26.corp.capgemini.com> Content-Type: text/plain; charset="iso-8859-1" OK, thanks. Any hope for a fix soon ? Regards, Nicolas. De : freeradius-users-bounces+nicolas.chaigneau=capgemini.com@lists.freeradius.org [mailto:freeradius-users-bounces+nicolas.chaigneau=capgemini.com@lists.freeradius.org] De la part de Arran Cudbard-Bell Envoy? : mardi 1 avril 2014 09:51 ? : FreeRadius users mailing list Objet : Re: 3.0.2 / possible bug when proxying with no response from home server On 1 Apr 2014, at 08:15, Chaigneau, Nicolas <nicolas.chaigneau@capgemini.com<mailto:nicolas.chaigneau@capgemini.com>> wrote: Thanks for the fix! I still have a question, though. Now, the request goes through: - authorize - pre-proxy (no response from proxy server) - Post-Auth-Type REJECT It does *not* go through "Post-Proxy-Type Fail" anymore. Is that the expected behaviour ? Nope! As show by this handy dandy revised diagram. [cid:image001.png@01CF4E5B.60196060] Arran Cudbard-Bell <a.cudbardb@freeradius.org<mailto:a.cudbardb@freeradius.org>> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2 This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freeradius.org/mailman/private/freeradius-users/attachments/20140402/e123e452/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 43484 bytes Desc: image001.png URL: <http://lists.freeradius.org/mailman/private/freeradius-users/attachments/20140402/e123e452/attachment.png> ------------------------------ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html End of Freeradius-Users Digest, Vol 108, Issue 8 ************************************************
Thomas Bru wrote:
When the renewal DHCP packets are send using unicast, my client try to reach FreeRadius. he send DHCP request using his IP address with source port 68 and the freeradius IP Address with destinatio port 67. My IAD source pat the flow using a dynamic random port.
That is not how DHCP works. DHCP clients use a source port of 68. DHCP relays use a source port of 67. Your IAD (whatever that is) is broken. Replace it with something that does DHCP properly.
I don't understand why Freeradius will not reply to the initial source port ?
Because DHCP is insane. The replies do *not* cause the src/dst ports to be swapped, as with every other UDP protocol.
3) This packet trace is not evidently the first requests, but a renewal? You're true, i see the problem only on the renewal (When 50% of the lease time have been reached).
Then look at the packet traces to see how the first request is different from the renewal. Alan DeKok.
participants (2)
-
Alan DeKok -
Thomas Bru