April 2014 - Freeradius-Users - lists.freeradius.org

Re: Freeradius DHCP IP pool and not correct port for DHCP reply - Re: Freeradius-Users Digest, Vol 108, Issue 6
by Rui Ribeiro 02 Apr '14

02 Apr '14

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(a)deployingradius.com> > To: FreeRadius users mailing list > <freeradius-users(a)lists.freeradius.org> > Subject: Re: Freeradius DHCP IP pool and not correct port for DHCP > reply > Message-ID: <533B0654.8060306(a)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. > > >

1 0

MPPE with PPTP - external module
by P K 01 Apr '14

01 Apr '14

Hi, I'm using multiotp with freeradius for VPN. Since multiotp supports CHAP/MSCHAP, I have the AuthType set to multiotp. The multiotp module has the following: exec multiotp { wait = yes input_pairs = request output_pairs = reply program = "/path/to/multiotp.php %{User-Name} %{User-Password} -src=%{Packet-Src-IP-Address} -chap-challenge=%{CHAP-Challenge} -chap-password=%{CHAP-Password} -ms-chap-challenge=%{MS-CHAP-Challenge} -ms-chap-response=%{MS-CHAP-Response} -ms-chap2-response=%{MS-CHAP2-Response}" shell_escape = yes } VPN works fine with CHAP & MSCHAP with multiotp. The trouble is encryption (PPTP with MPPE). When encryption is selected by the user, VPN fails. The problem is that radius will not send the required MPPE responses(MS-MPPE-Recv-Key, MS-MPPE-Send-Key etc.) to NAS. I note that mschap module has options like use_mppe, require_encryption etc.. How can I get radius to send those when I'm using multiotp module to perform chap/mschap so that PPTP with MPPE works? Thanks.

2 1

rlm_perl - Asymmetric attribute encoding
by Scott Ireland 01 Apr '14

01 Apr '14

I'm seeing some inconsistent handling of encoding/escaping of attributes in rlm_perl between calls to the module (i.e. when setting an attribute in one call and then reading it back in the next). I was expecting "something out, something in", but instead I'm getting "something out, something-modified in". In authorize, my script does an LDAP lookup and then sets the $RAD_CHECK{'Ldap-UserDn'} attribute for later: rlm_perl: Added pair Ldap-UserDn = CN=Ireland\, Scott,OU=[...] In authenticate, I go to read this back but find that the \ in the attribute is coming back to me escaped: rlm_perl: Added pair Ldap-UserDn = CN=Ireland\\, Scott,OU=[...] So, I end up having to strip off the escaping backslashes before using the value. I'm seeing something similar with the State attribute going out in an Access-Challenge and coming back in on the next Access-Request. In authorize, I set $RAD_REPLY{'State'} to the single byte value 0x01 that I send back in an Access-Challenge rlm_perl: Added pair State = ? Sending Access-Challenge of id 253 to [ip] port 63308 State = 0x01 When authorize next sees the follow-up request from the NAS, things look OK in the RADIUS packet: rad_recv: Access-Request packet from host [ip] port 14034, id=254, length=146 State = 0x01 rlm_perl: Added pair State = 0x01 But when I read it in Perl, $RAD_REQUEST{'State'} comes back as the string "0x01", so I have to turn around and pack() this to get back what I put in. The same thing happens for different values as well; for instance, if I were to use the literal 1 as a value, State goes out as 0x31 (the string "1") and comes back in as the string "0x31", which again needs a pack() to fix. I've been able to work around this by doing a bit of extra processing when I read any of these attributes back, but it doesn't really seem like intended behaviour.

2 5

Freeradius DHCP IP pool and not correct port for DHCP reply
by Thomas Bru 01 Apr '14

01 Apr '14

Hello everybody I change the version of Freeradius (2.2.4 -> 3.0.4) beacause I have a problem when I used the DHCP relay feature. When I used the freeradius version 2.2.4, my DHCP relay send DHCP-Request from x.x.x.x:20675o y.y.y.y:67 but the reply packet is y.y.y.y:67 to x.x.x.x:67 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. Someone can help me to solve this problem Thanks in advance Thomas

2 1

Wildcard SSL Certificates
by Sam Fakhreddine 01 Apr '14

01 Apr '14

Hello, Can we use Wildcard SSL Certificates from a third party CA with freeradius servers? Sam Fakhreddine Site Systems Administrator Ledcor Industries Inc., Information Services 7008 Roper Road NW, Edmnoton, AB T6B 3H2 p 780-395-5455 | c 780-996-0763 www.ledcor.com<http://www.ledcor.com> FORWARD. TOGETHER.

5 4

Freeradius DHCP IP pool and not correct port for DHCP reply
by Thomas Bru 01 Apr '14

01 Apr '14

Hello everybody I change the version of Freeradius (2.2.4 -> 3.0.4) beacause I have a problem when I used the DHCP relay feature. When I used the freeradius version 2.2.4, my DHCP relay send DHCP-Request from x.x.x.x:20675o y.y.y.y:67 but the reply packet is y.y.y.y:67 to x.x.x.x:67 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 Someone can help me to solve this problem Thanks in advance Thomas

1 0

Re: Wildcard SSL Certificates
by Sam Fakhreddine 01 Apr '14

01 Apr '14

Well that is too bad. Thanks miroslav Sam Fakhreddine Site Systems Administrator Ledcor Industries Inc., Information Services 7008 Roper Road NW, Edmnoton, AB T6B 3H2 p 780-395-5455 | c 780-996-0763 www.ledcor.com<http://www.ledcor.com> FORWARD. TOGETHER.

1 0

Changing Class attribute from octets to string
by Antonio Modesto Amaral Sousa 01 Apr '14

01 Apr '14

Hello, I need to use the class attribute in order to assign the user to a service plan in a DPI box. The Class attribute is been carried in the acct packets, the problem is that Freeradius is converting it to hexadecimal, I've changed the type from octets to string and restarted the service but it continued to be converted to hex. What can I do to get this attribute to be carried in plain text format? Thanks. --

2 4

What will be new in v3.0.3
by Alan DeKok 01 Apr '14

01 Apr '14

It's been a busy week. In addition to releasing new documentation (http://networkradius.com/doc/) we've been adding more functionality to the server core. As of now, pretty much all of "unlang" is syntax checked when the server starts. This means that errors in conditional checks will be caught: if ("%{no-such-module:foo}" == "bar") { will now cause the server to print a descriptive error, and fail to start. The same applies for update statements: update reply { Filter-Id := "%{no-such-module:foo}" } And switch statements: switch "%{no-such-module:foo}" { and case statements: case "%{no-such-module:foo}" As a side note, "case" statements now support dynamic expansions, which they didn't before. Both "switch" and "case" statements support attribute references: switch &User-Name { case &Filter-Id { ... Will match if User-Name == Filter-Id. This capability gives a bit more flexibility in the use of "switch" and "case". These are small changes. But they should have a large impact on usability. When there's a typo in the configuration, the server will produce a MUCH better error message than it did for version 3.0.2. Alan DeKok.

3 3