- Freeradius-Users - lists.freeradius.org

Send Logs to Remote Log server
by Muhammed Buvaydani 17 Aug '20

17 Aug '20

Hello , I want to send freeradius's logs to another host , that host has Remote Log server , Rsyslog, or Graylog , how can I configure freeradius to do that . thank you

2 1

FreeRadius with Google PAM - Hardcode LDAP Servers for rlm_ldap
by Brandt Winchell 14 Aug '20

14 Aug '20

Hello, I have an issue which I am sure is easy to fix but I cannot find the correct file/setting. Let me explain: Environment: Active Directory - backend authentication. The AD environment is setup as a hub & spoke design. This means not all domain controllers (GC) are accessible from everywhere (by design & security) Freeradius - CentOS7 server FreeRadius-3.0.13 Source Setup: It is basically a setup following this site: https://kb.hillstonenet.com/en/wp-content/uploads/2019/09/SSLVPN-Two-factor… Validations: SSSD = Server joined to the domain fine. Can login to the local server with a domain account. ident tests resolve fine DNS = hostname and any GC server resolves correctly AD search results = **while in subnet80, works correctly** Google Authenticator PAM = **while in subnet80, works correctly** Issue: When I have the FreeRadius server in subnet80 (172.16.80.0/24 hub site and can talk to any GC server), the configuration works fine. So I know the basic configurations are working as designed. When I move the FreeRadius server into subnet 99 (172.16.99.0/24 restricted site that can only talk to 172.16.80.0/24), radius fails to get any results from GC servers. There is a firewall between these subnets. I have configured the following files to specify which GC servers FreeRadius should use: /etc/raddb/mods-available/ldap ldap { server = 'dc01.domain.local' server = 'dc02.domain.local' start_tls = no port = 389 identity = 'CN=ad-read-account,DC=domain,DC=local' password = 'xxxxxxx' base_dn = 'DC=domain,DC=local' /etc/sssd/sssd.conf [sssd] domains = domain.local services = nss, pam [domain/domain.local] id_provider = ad access_provider = ad ad_server = dc01.domain.local ad_backup_server = dc02.domain.local krb5_realm = DOMAIN.LOCAL krb5_server = dc01.domain.local kerb5_backup_server = dc02.domain.local ldap_uri = ldap://dc01.domain.local /etc/krb5.conf [libdefaults] dns_lookup_realm = false dns_lookup_kdc = false [realms] DOMAIN.LOCAL = { kdc = dc01.domain.local kdc = dc02.domain.local [domain_realm} domain.local = DOMAIN.LOCAL .domain.local = DOMAIN.LOCAL When I run "radiusd -CX". I get an ready to process requests for configuration check. When I run "radiusd -X", this is the where the process fails/hangs: rlm_ldap (ldap): Connecting to ldap://dc01.domain.local:389 ldap://dc02.domain.local:389 rlm_ldap (ldap): Waiting for bind result... rlm_ldap (ldap): Bind successful rlm_ldap (ldap): Reserved connection (5) (0) EXPAND (userPrincipalName=%{%{Stripped-User-Name}:-%{User-Name}}) (0) --> (userPrincipalName=user1(a)domain.local) (0) Performing search in "DC=domain,DC=local" with filter "(userPrincipalName=user1(a)domain.local)", scope "sub" (0) Waiting for search result... This will sit there until the LDAP search times out. When I perform a packet capture during this time, what I see: 1 radius performs a DNS query for forestdnszones.domain.local SOA dc01.domain.local 2 dns server responds with records of ALL GC servers 3 radius then tries to connect to a GC server it does not have access to (due to the security restrictions) Resolution: It seems that the FreeRadius LDAP module is trying to find the SRV record for LDAP. Of course DNS responds with all LDAP SRV records. What I need to be able to do is restrict what LDAP servers FreeRadius is trying to use. This seems very similar to SSSD Service Discovery. Any assistance on this one would be appreciated. btw... I cannot post full debug logs due to security but will provide any additional info that might assist with this Thanks

3 4

No Response from radius server
by mohamad buvaydanı 14 Aug '20

14 Aug '20

I have freeradius 3.0 which is installed on ubuntu 18.10 , I am working on hotspot system using Mikrotik with freeradius , I was able to send login Request from Mikrotik to radius server without any problem , but then I enabled Ufw in ubuntu machine , then I disabled UFW , Now Mikrotik can send request to freeradius but freeradius can not send response to Mikrotik , I don't know what is the problem , I disabled UFW and even I removed it from the server ,but still Mikrotik Can not get response from Radius this is the debug of Freeradius (0) [expiration] = noop (0) [logintime] = noop (0) accessperiod: WARNING: Couldn't find check attribute, control:Access-Period, doing nothing... (0) [accessperiod] = noop (0) pap: WARNING: Auth-Type already set. Not setting to PAP (0) [pap] = noop (0) } # authorize = ok (0) Found Auth-Type = Accept (0) Auth-Type = Accept, accepting the user (0) # Executing section post-auth from file /etc/freeradius/3.0/sites-enabled/default (0) post-auth { (0) update { (0) No attributes updated (0) } # update = noop (0) sql: EXPAND .query (0) sql: --> .query (0) sql: Using query template 'query' rlm_sql (sql): Reserved connection (2) (0) sql: EXPAND %{User-Name} (0) sql: --> test (0) sql: SQL-User-Name set to 'test' (0) sql: EXPAND INSERT INTO radpostauth (username, pass, reply, authdate) VALUES ( '%{SQL-User-Name}', '%{%{User-Password}:-%{Chap-Password}}', '%{reply:Packet-Type}', '%S') (0) sql: --> INSERT INTO radpostauth (username, pass, reply, authdate) VALUES ( 'test', '0x8da5209f622859ac89fd640527cb56139a', 'Access-Accept', '2020-08-12 21:07:21') (0) sql: Executing query: INSERT INTO radpostauth (username, pass, reply, authdate) VALUES ( 'test', '0x8da5209f622859ac89fd640527cb56139a', 'Access-Accept', '2020-08-12 21:07:21') (0) sql: SQL query returned: success (0) sql: 1 record(s) updated rlm_sql (sql): Released connection (2) (0) [sql] = ok (0) [exec] = noop (0) policy remove_reply_message_if_eap { (0) if (&reply:EAP-Message && &reply:Reply-Message) { (0) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE (0) else { (0) [noop] = noop (0) } # else = noop (0) } # policy remove_reply_message_if_eap = noop (0) } # post-auth = ok (0) Sent Access-Accept Id 23 from 172.16.1.148:1812 to 172.16.1.252:40180 length 0 as u see from the last line , Freeradius sending Access-accept to Mikrotik , but this response not received by mikroitk and Mikrotik through Login Feild No Response From Radius I tested Mikrotik with another freeradius server and it is working without any problem So , I think there are somethings which prevent the response packet to Mikrotik .

2 1

Seeing dhcp packet drops in latest master
by Chinnapaiyan, Nagamani 13 Aug '20

13 Aug '20

We are seeing packet drops frequently in latest 4.x version(#8c2e4122572a12f43d4ec294d3258a2f0da07b1d). We are not doing scale test, just ~10 DORAs. If I run some 10 testcases(10 DORAs each test case), it fails randomly at any one of the tests. The same testcases were passing around one month before. We have Client -> Freeradius dhcp Relay agent(Load Balancer) -> freeradius dhcp server. I could not capture issue clearly with debug mode as it is slower. So I enabled some of the debug logs in the code. ---------------- diff --git a/src/lib/io/network.c b/src/lib/io/network.c index 7276606..3850725 100644 --- a/src/lib/io/network.c +++ b/src/lib/io/network.c @@ -684,6 +684,7 @@ static void fr_network_read(UNUSED fr_event_list_t *el, int sockfd, UNUSED int f s->listen->fd, sockfd)) return; DEBUG3("Reading data from FD %u", sockfd); + ERROR("DEBLOGJK: Reading data from FD %u", sockfd); if (!s->cd) { cd = (fr_channel_data_t *) fr_message_reserve(s->ms, s->listen->default_message_size); @@ -751,6 +752,7 @@ next_message: s->cd = NULL; DEBUG3("Read %zd byte(s) from FD %u", data_size, sockfd); + ERROR("DEBLOGJK: Read %zd byte(s) from FD %u", data_size, sockfd); nr->stats.in++; s->stats.in++; diff --git a/src/modules/proto_dhcpv4/proto_dhcpv4_udp.c b/src/modules/proto_dhcpv4/proto_dhcpv4_udp.c index 89e7ac9..38736fe 100644 --- a/src/modules/proto_dhcpv4/proto_dhcpv4_udp.c +++ b/src/modules/proto_dhcpv4/proto_dhcpv4_udp.c @@ -159,6 +159,7 @@ static ssize_t mod_read(fr_listen_t *li, void **packet_ctx, fr_time_t *recv_time &address->src_ipaddr, &address->src_port, &address->dst_ipaddr, &address->dst_port, &address->if_index, recv_time_p); + ERROR("DEBLOGJK: proto_dhvpv4_udp"); if (data_size < 0) { DEBUG2("proto_dhvpv4_udp got read error %zd: %s", data_size, fr_strerror()); return data_size; @@ -203,6 +204,9 @@ static ssize_t mod_read(fr_listen_t *li, void **packet_ctx, fr_time_t *recv_time DEBUG2("proto_dhcpv4_udp - Received %s XID %08x length %d %s", dhcp_message_types[message_type], xid, (int) packet_len, thread->name); + ERROR("DEBLOGJK: proto_dhcpv4_udp - Received %s XID %08x length %d %s", + dhcp_message_types[message_type], xid, + (int) packet_len, thread->name); return packet_len; } ------------------- Below are tcpdump and radiusd logs in success case and failure cases. normal time (success case): Client side:(tcpdump) 12:12:36.039499 IP 10.43.18.32.67 > 10.43.18.31.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3a, length 311 12:12:36.106401 IP 10.43.18.48.67 > 10.43.18.32.67: BOOTP/DHCP, Reply, length 768 12:12:36.107826 IP 10.43.18.32.67 > 10.43.18.31.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3a, length 323 12:12:36.113856 IP 10.43.18.48.67 > 10.43.18.32.67: BOOTP/DHCP, Reply, length 768 12:12:36.439471 IP 10.43.18.32.67 > 10.43.18.31.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3b, length 311 12:12:36.442614 IP 10.43.18.48.67 > 10.43.18.32.67: BOOTP/DHCP, Reply, length 328 12:12:36.442895 IP 10.43.18.32.67 > 10.43.18.31.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3b, length 323 12:12:36.445647 IP 10.43.18.48.67 > 10.43.18.32.67: BOOTP/DHCP, Reply, length 328 Relay Agent side:(tcpdump) 12:12:36.041608 IP 10.43.18.32.67 > 10.43.18.31.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3a, length 311 12:12:36.041851 IP 10.43.18.31.67 > 10.43.18.48.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3a, length 312 12:12:36.109916 IP 10.43.18.32.67 > 10.43.18.31.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3a, length 323 12:12:36.110206 IP 10.43.18.31.67 > 10.43.18.48.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3a, length 324 12:12:36.441579 IP 10.43.18.32.67 > 10.43.18.31.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3b, length 311 12:12:36.441894 IP 10.43.18.31.67 > 10.43.18.48.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3b, length 312 12:12:36.444965 IP 10.43.18.32.67 > 10.43.18.31.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3b, length 323 12:12:36.445130 IP 10.43.18.31.67 > 10.43.18.48.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3b, length 324 DHCP server side: (tcpdump + enabled radiusd logs) 12:12:36.041788 IP 10.43.18.31.67 > 10.43.18.48.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3a, length 312 <<tcpdump line Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: Network 0 - DEBLOGJK: Reading data from FD 51 <<< added error logs Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: DEBLOGJK: proto_dhvpv4_udp Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: DEBLOGJK: proto_dhcpv4_udp - Received DHCP-Discover XID 00000000 length 312 dhcpv4_udp server 10.43.18.48 port 67 Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: Network 0 - DEBLOGJK: Read 312 byte(s) from FD 51 Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30937]: DHCP-DISCOVER giaddr=10.43.18.32 chaddr=00:a0:bc:6c:7d:3a 12= 50= 55=DHCP-Subnet-Mask,DHCP-Broadcast-Address,DHCP-Time-Offset,DHCP-Router-Address,DHCP-Domain-Name,DHCP-Domain-Name-Server,DHCP-Hostname 60= 61=0x01afac00000000 82.1=0x0000804bff66 82.2=0x00a0bc6c7d3a 82.6=00a0bc000001(a)perf.test.viasat 82.100=82.1 <<< logs from our module's config Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: (77) ldap - Closing connection (3): Hit idle_timeout, was idle for 207.534324944s Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: rlm_ldap (ldap) - Directory type: OpenLDAP Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30937]: DHCP-LDAP_FOUND LDAP option43 string found for MAC 00:a0:bc:6c:7d:3a. Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: (77) redis_ippool - Closing connection (5): Hit idle_timeout, was idle for 212.217780777s 12:12:36.108074 IP 10.43.18.48.67 > 10.43.18.32.67: BOOTP/DHCP, Reply, length 768 Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30937]: DHCP-OFFER giaddr=10.43.18.32 chaddr=00:a0:bc:6c:7d:3a yiaddr=172.21.0.181 1=255.255.0.0 3=172.21.0.1 6=72.173.31.41,72.173.31.42 43=0x010300a0bc0209555400000000000007030e55543200000000000307030a0009041155545f332e372e332e31302e392e62696e05040a4fff0f1444010002010311050044004407004300430101020103060701bd01bd0101020107008700880101020106c0a8640018070016001701010201031106c0a86400180700a100a11901012642687474703a2f2f6163732e6465762e636d742e7669617361742e696f3a393637352f6c6976652f4350454d616e616765722f435045732f67656e657269635452363927020005280207d02a0e55542e352e322e322e31303530332b040a4fff0f2c0e55542e352e322e322e3130333933330c5554320000000000000029083601ff3b0e55543200000000000307030a00093c125554325f332e372e332e31302e392e62696e3d040a4fff0f3e3c687474703a2f2f31302e37392e3235352e31362f7075622f7677615f696d616765732f7677615f55542e352e322e322e31303530332e7461722e677a3f3c687474703a2f2f31302e37392e3235352e31362f7075622f7677615f696d616765732f7677615f55542e352e322e322e31303339332e7461722e677a400100 51=120 61=0x01afac00000000 82.1=0x0000804bff66 82.2=0x00a0bc6c7d3a 82.6=00a0bc000001(a)perf.test.viasat 82.100= 12:12:36.110060 IP 10.43.18.31.67 > 10.43.18.48.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3a, length 324 Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: Network 0 - DEBLOGJK: Reading data from FD 51 Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: DEBLOGJK: proto_dhvpv4_udp Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: DEBLOGJK: proto_dhcpv4_udp - Received DHCP-Request XID 00000000 length 324 dhcpv4_udp server 10.43.18.48 port 67 Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: Network 0 - DEBLOGJK: Read 324 byte(s) from FD 51 Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30937]: DHCP-REQUEST giaddr=10.43.18.32 chaddr=00:a0:bc:6c:7d:3a ciaddr=10.43.18.32 12= 50=172.21.0.181 55=DHCP-Subnet-Mask,DHCP-Broadcast-Address,DHCP-Time-Offset,DHCP-Router-Address,DHCP-Domain-Name,DHCP-Domain-Name-Server,DHCP-Hostname 60= 61=0x01afac00000000 82.1=0x0000804bff66 82.2=0x00a0bc6c7d3a 82.6=00a0bc000001(a)perf.test.viasat 82.100= Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30937]: DHCP-LDAP_FOUND LDAP option43 string found for MAC 00:a0:bc:6c:7d:3a. Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: (78) Closing connection (7): Hit idle_timeout, was idle for 207.588781775s 12:12:36.115554 IP 10.43.18.48.67 > 10.43.18.32.67: BOOTP/DHCP, Reply, length 768 Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30937]: DHCP-ACK giaddr=10.43.18.32 chaddr=00:a0:bc:6c:7d:3a yiaddr=172.21.0.181 1=255.255.0.0 3=172.21.0.1 6=72.173.31.41,72.173.31.42 12= 43=0x010300a0bc0209555400000000000007030e55543200000000000307030a0009041155545f332e372e332e31302e392e62696e05040a4fff0f1444010002010311050044004407004300430101020103060701bd01bd0101020107008700880101020106c0a8640018070016001701010201031106c0a86400180700a100a11901012642687474703a2f2f6163732e6465762e636d742e7669617361742e696f3a393637352f6c6976652f4350454d616e616765722f435045732f67656e657269635452363927020005280207d02a0e55542e352e322e322e31303530332b040a4fff0f2c0e55542e352e322e322e3130333933330c5554320000000000000029083601ff3b0e55543200000000000307030a00093c125554325f332e372e332e31302e392e62696e3d040a4fff0f3e3c687474703a2f2f31302e37392e3235352e31362f7075622f7677615f696d616765732f7677615f55542e352e322e322e31303530332e7461722e677a3f3c687474703a2f2f31302e37392e3235352e31362f7075622f7677615f696d616765732f7677615f55542e352e322e322e31303339332e7461722e677a400100 51=300 61=0x01afac00000000 82.1=0x0000804bff66 82.2=0x00a0bc6c7d3a 82.6=00a0bc000001(a)perf.test.viasat 82.100= 12:12:36.441821 IP 10.43.18.31.67 > 10.43.18.48.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3b, length 312 Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: Network 0 - DEBLOGJK: Reading data from FD 51 Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: DEBLOGJK: proto_dhvpv4_udp Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: DEBLOGJK: proto_dhcpv4_udp - Received DHCP-Discover XID 00000001 length 312 dhcpv4_udp server 10.43.18.48 port 67 Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: Network 0 - DEBLOGJK: Read 312 byte(s) from FD 51 Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30937]: DHCP-DISCOVER giaddr=10.43.18.32 chaddr=00:a0:bc:6c:7d:3b 12= 50= 55=DHCP-Subnet-Mask,DHCP-Broadcast-Address,DHCP-Time-Offset,DHCP-Router-Address,DHCP-Domain-Name,DHCP-Domain-Name-Server,DHCP-Hostname 60= 61=0x01afac00000000 82.1=0x0000804bff66 82.2=0x00a0bc6c7d3a 82.6=00a0bc000001(a)perf.test.viasat 82.100= 12:12:36.444307 IP 10.43.18.48.67 > 10.43.18.32.67: BOOTP/DHCP, Reply, length 328 Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30937]: DHCP-OFFER giaddr=10.43.18.32 chaddr=00:a0:bc:6c:7d:3b yiaddr=172.18.16.112 1=255.0.0.0 3=172.16.0.1 6=72.173.31.41,72.173.31.42 43= 51=92 61=0x01afac00000000 82.1=0x0000804bff66 82.2=0x00a0bc6c7d3a 82.6=00a0bc000001(a)perf.test.viasat 82.100= 12:12:36.444982 IP 10.43.18.31.67 > 10.43.18.48.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3b, length 324 Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: Network 0 - DEBLOGJK: Reading data from FD 51 Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: DEBLOGJK: proto_dhvpv4_udp Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: DEBLOGJK: proto_dhcpv4_udp - Received DHCP-Request XID 00000001 length 324 dhcpv4_udp server 10.43.18.48 port 67 Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: Network 0 - DEBLOGJK: Read 324 byte(s) from FD 51 Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30937]: DHCP-REQUEST giaddr=10.43.18.32 chaddr=00:a0:bc:6c:7d:3b ciaddr=10.43.18.32 12= 50=172.18.16.112 55=DHCP-Subnet-Mask,DHCP-Broadcast-Address,DHCP-Time-Offset,DHCP-Router-Address,DHCP-Domain-Name,DHCP-Domain-Name-Server,DHCP-Hostname 60= 61=0x01afac00000000 82.1=0x0000804bff66 82.2=0x00a0bc6c7d3a 82.6=00a0bc000001(a)perf.test.viasat 82.100= 12:12:36.447348 IP 10.43.18.48.67 > 10.43.18.32.67: BOOTP/DHCP, Reply, length 328 Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30937]: DHCP-ACK giaddr=10.43.18.32 chaddr=00:a0:bc:6c:7d:3b yiaddr=172.18.16.112 1=255.0.0.0 3=172.16.0.1 6=72.173.31.41,72.173.31.42 12= 43= 51=300 61=0x01afac00000000 82.1=0x0000804bff66 82.2=0x00a0bc6c7d3a 82.6=00a0bc000001(a)perf.test.viasat 82.100= Packet drop: Client side: 12:41:16.748120 IP 10.43.18.32.67 > 10.43.18.31.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3a, length 311 12:41:17.148104 IP 10.43.18.32.67 > 10.43.18.31.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3b, length 311 Relay agent side: 12:41:16.750013 IP 10.43.18.32.67 > 10.43.18.31.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3a, length 311 12:41:16.750285 IP 10.43.18.31.67 > 10.43.18.48.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3a, length 312 12:41:17.150006 IP 10.43.18.32.67 > 10.43.18.31.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3b, length 311 12:41:17.150258 IP 10.43.18.31.67 > 10.43.18.48.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3b, length 312 DHCP server side: 12:41:16.750292 IP 10.43.18.31.67 > 10.43.18.48.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3a, length 312 Aug 13 12:41:16 citests01-dhcp-01-alpha radiusd[30931]: Network 0 - DEBLOGJK: Reading data from FD 51 Aug 13 12:41:16 citests01-dhcp-01-alpha radiusd[30931]: DEBLOGJK: proto_dhvpv4_udp Aug 13 12:41:16 citests01-dhcp-01-alpha radiusd[30931]: DEBLOGJK: proto_dhcpv4_udp - Received DHCP-Discover XID 00000000 length 312 dhcpv4_udp server 10.43.18.48 port 67 Aug 13 12:41:16 citests01-dhcp-01-alpha radiusd[30931]: Network 0 - DEBLOGJK: Read 312 byte(s) from FD 51 12:41:17.150273 IP 10.43.18.31.67 > 10.43.18.48.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3b, length 312 Aug 13 12:41:17 citests01-dhcp-01-alpha radiusd[30931]: Network 0 - DEBLOGJK: Reading data from FD 51 Aug 13 12:41:17 citests01-dhcp-01-alpha radiusd[30931]: DEBLOGJK: proto_dhvpv4_udp Aug 13 12:41:17 citests01-dhcp-01-alpha radiusd[30931]: DEBLOGJK: proto_dhcpv4_udp - Received DHCP-Discover XID 00000001 length 312 dhcpv4_udp server 10.43.18.48 port 67 12:41:17.350309 IP 10.43.18.31.67 > 10.43.18.48.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3c, length 312 Aug 13 12:41:17 citests01-dhcp-01-alpha radiusd[30931]: Network 0 - DEBLOGJK: Reading data from FD 51 Aug 13 12:41:17 citests01-dhcp-01-alpha radiusd[30931]: DEBLOGJK: proto_dhvpv4_udp Aug 13 12:41:17 citests01-dhcp-01-alpha radiusd[30931]: DEBLOGJK: proto_dhcpv4_udp - Received DHCP-Discover XID 00000002 length 312 dhcpv4_udp server 10.43.18.48 port 67 seems packet is delivered to DHCP server, but radiusd is not responding and there are no other error logs in that time. I tried my best to corner out the problem. But, could not tackle the exact use case as it is happening randomly. I suspected these two logs, ldap - Closing connection (3): Hit idle_timeout, was idle for 207.534324944s redis_ippool - Closing connection (5): Hit idle_timeout, was idle for 212.217780777s I tried tweaking that parameter from 60, to 600 then to infinite(0) in redis, redis_ippool and ldap. That didnt help. Please help. Regards, Nagamani Chinnapaiyan

2 1

No Response from radius server
by Muhammed Buvaydani 13 Aug '20

13 Aug '20

I have freeradius 3.0 which is installed on ubuntu 18.10 , I am working on hotspot system using Mikrotik with freeradius , I was able to send login Request from Mikrotik to radius server without any problem , but then I enabled Ufw in ubuntu machine , then I disabled UFW , Now Mikrotik can send request to freeradius but freeradius can not send response to Mikrotik , I don't know what is the problem , I disabled UFW and even I removed it from the server ,but still Mikrotik Can not get response from Radius this is the debug of Freeradius (0) [expiration] = noop (0) [logintime] = noop (0) accessperiod: WARNING: Couldn't find check attribute, control:Access-Period, doing nothing... (0) [accessperiod] = noop (0) pap: WARNING: Auth-Type already set. Not setting to PAP (0) [pap] = noop (0) } # authorize = ok (0) Found Auth-Type = Accept (0) Auth-Type = Accept, accepting the user (0) # Executing section post-auth from file /etc/freeradius/3.0/sites-enabled/default (0) post-auth { (0) update { (0) No attributes updated (0) } # update = noop (0) sql: EXPAND .query (0) sql: --> .query (0) sql: Using query template 'query' rlm_sql (sql): Reserved connection (2) (0) sql: EXPAND %{User-Name} (0) sql: --> test (0) sql: SQL-User-Name set to 'test' (0) sql: EXPAND INSERT INTO radpostauth (username, pass, reply, authdate) VALUES ( '%{SQL-User-Name}', '%{%{User-Password}:-%{Chap-Password}}', '%{reply:Packet-Type}', '%S') (0) sql: --> INSERT INTO radpostauth (username, pass, reply, authdate) VALUES ( 'test', '0x8da5209f622859ac89fd640527cb56139a', 'Access-Accept', '2020-08-12 21:07:21') (0) sql: Executing query: INSERT INTO radpostauth (username, pass, reply, authdate) VALUES ( 'test', '0x8da5209f622859ac89fd640527cb56139a', 'Access-Accept', '2020-08-12 21:07:21') (0) sql: SQL query returned: success (0) sql: 1 record(s) updated rlm_sql (sql): Released connection (2) (0) [sql] = ok (0) [exec] = noop (0) policy remove_reply_message_if_eap { (0) if (&reply:EAP-Message && &reply:Reply-Message) { (0) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE (0) else { (0) [noop] = noop (0) } # else = noop (0) } # policy remove_reply_message_if_eap = noop (0) } # post-auth = ok (0) Sent Access-Accept Id 23 from 172.16.1.148:1812<http://172.16.1.148:1812/> to 172.16.1.252:40180<http://172.16.1.252:40180/> length 0 as u see from the last line , Freeradius sending Access-accept to Mikrotik , but this response not received by mikroitk and Mikrotik through Login Feild No Response From Radius I tested Mikrotik with another freeradius server and it is working without any problem So , I think there are somethings which prevent the response packet to Mikrotik . [1562314050593]

2 1

Re: FreeTDS affected_rows_count Problem, Virtual Servers - nas_table Server Column Problem
by Ali Arslan 12 Aug '20

12 Aug '20

Hello, Today i will post 2 problems together that i have already sent by 2 different emails but still i cannot resolve without taking side ways. I will give earlier email links but both of the problems will be stated completely here again not to make reader to consult other sources of the problem statement: Note: Though i overcome the problems here i thought you may need to know about them to make already the best radius server on the globe better. 1- FreeTDS affected_rows_count Problem earlier email: http://freeradius.1045715.n5.nabble.com/mssql-freetds-interim-update-proble… 2- Virtual Servers - nas_table Server Column Problem earlier email http://freeradius.1045715.n5.nabble.com/Virtual-Servers-amp-nas-table-Serve… Problem Statement 1- FreeTDS affected_rows_count Problem Since rlm_sql_freetds does not get the true affected rows count it continues to insert new records in radacct table for the same session in interim updates. I attached debug output (debug_freetds.txt). Some lines from debug that will summarize the problem are as follows: (3) WISPSQL: Executing query: UPDATE radacct SET AcctInterval = DATEDIFF(second, AcctUpdateTime, GETDATE()), AcctUpdateTime = GETDATE(), AcctStopTime = NULL, AcctSessionTime = 121, FramedIPAddress = '192.168.10.255', AcctInputOctets = convert(bigint, '0' * POWER(2.0, 32)) | '95438', AcctOutputOctets = convert(bigint, '0' * POWER(2.0, 32)) | '45977' WHERE AcctUniqueId = '69913b8866eac834270ab589229ef6ab' (3) WISPSQL: SQL query returned: success (3) WISPSQL: -1 record(s) updated (3) WISPSQL: Trying next query... (3) WISPSQL: EXPAND IF NOT EXISTS(SELECT 1 FROM radacct WHERE AcctUniqueId = '%{Acct-Unique-Session-Id}') INSERT INTO radacct (AcctSessionId, AcctUniqueId, UserName, Realm, NASIPAddress, NASPortId, NASPortType, AcctStartTime, AcctUpdateTime, AcctStopTime, AcctSessionTime, AcctAuthentic, ConnectInfoStart, ConnectInfoStop, AcctInputOctets, AcctOutputOctets, CalledStationId, CallingStationId, AcctTerminateCause, ServiceType, FramedProtocol, FramedIPAddress) VALUES('%{Acct-Session-Id}', '%{Acct-Unique-Session-Id}', '%{SQL-User-Name}', '%{Realm}', '%{%{Packet-Src-IP-Address}:-%{NAS-IP-Address}}', '%{%{NAS-Port-Id}:-%{NAS-Port}}', '%{NAS-Port-Type}', DATEADD(second, -1 * (%{%{Acct-Session-Time}:-0}), GETDATE()), GETDATE(), NULL, %{%{Acct-Session-Time}:-NULL}, '%{Acct-Authentic}', '%{Connect-Info}', NULL, convert(bigint, '%{%{Acct-Input-Gigawords}:-0}' * POWER(2.0, 32)) | '%{%{Acct-Input-Octets}:-0}', convert(bigint, '%{%{Acct-Output-Gigawords}:-0}' * POWER(2.0, 32)) | '%{%{Acct-Output-Octets}:-0}', '%{Called-Station-Id}', '%{Calling-Station-Id}', NULL, '%{Service-Type}', '%{Framed-Protocol}', '%{Framed-IP-Address}') (3) WISPSQL: --> IF NOT EXISTS(SELECT 1 FROM radacct WHERE AcctUniqueId = '69913b8866eac834270ab589229ef6ab') INSERT INTO radacct (AcctSessionId, AcctUniqueId, UserName, Realm, NASIPAddress, NASPortId, NASPortType, AcctStartTime, AcctUpdateTime, AcctStopTime, AcctSessionTime, AcctAuthentic, ConnectInfoStart, ConnectInfoStop, AcctInputOctets, AcctOutputOctets, CalledStationId, CallingStationId, AcctTerminateCause, ServiceType, FramedProtocol, FramedIPAddress) VALUES('81600002', '69913b8866eac834270ab589229ef6ab', 'test@orbit', '', '192.168.1.200', 'LAN', 'Ethernet', DATEADD(second, -1 * (121), GETDATE()), GETDATE(), NULL, 121, 'RADIUS', '', NULL, convert(bigint, '0' * POWER(2.0, 32)) | '95438', convert(bigint, '0' * POWER(2.0, 32)) | '45977', 'PPPoE', 'D8:C4:97:15:C1:F8', NULL, 'Framed-User', 'PPP', '192.168.10.255') (3) WISPSQL: Executing query: IF NOT EXISTS(SELECT 1 FROM radacct WHERE AcctUniqueId = '69913b8866eac834270ab589229ef6ab') INSERT INTO radacct (AcctSessionId, AcctUniqueId, UserName, Realm, NASIPAddress, NASPortId, NASPortType, AcctStartTime, AcctUpdateTime, AcctStopTime, AcctSessionTime, AcctAuthentic, ConnectInfoStart, ConnectInfoStop, AcctInputOctets, AcctOutputOctets, CalledStationId, CallingStationId, AcctTerminateCause, ServiceType, FramedProtocol, FramedIPAddress) VALUES('81600002', '69913b8866eac834270ab589229ef6ab', 'test@orbit', '', '192.168.1.200', 'LAN', 'Ethernet', DATEADD(second, -1 * (121), GETDATE()), GETDATE(), NULL, 121, 'RADIUS', '', NULL, convert(bigint, '0' * POWER(2.0, 32)) | '95438', convert(bigint, '0' * POWER(2.0, 32)) | '45977', 'PPPoE', 'D8:C4:97:15:C1:F8', NULL, 'Framed-User', 'PPP', '192.168.10.255') (3) WISPSQL: SQL query returned: success (3) WISPSQL: -1 record(s) updated (3) WISPSQL: No additional queries configured rlm_sql (WISPSQL): Released connection (8) (3) [WISPSQL] = noop (3) update control { (3) EXPAND %{User-Name} (3) --> test@orbit (3) SQL-User-Name set to 'test@orbit' rlm_sql (WISPSQL): Reserved connection (7) Here update runs and returns success (3) WISPSQL: SQL query returned: success (3) WISPSQL: -1 record(s) updated but since it does not return true updated rows count (-1 record(s) updated) so it tries to insert new record (3) WISPSQL: Executing query: IF NOT EXISTS(SELECT 1 FROM radacct WHERE AcctUniqueId = '69913b8866eac834270ab589229ef6ab') INSERT INTO radacct (AcctSessionId, AcctUniqueId, UserName, Realm, NASIPAddress, NASPortId, NASPortType, AcctStartTime, AcctUpdateTime, AcctStopTime, AcctSessionTime, AcctAuthentic, ConnectInfoStart, ConnectInfoStop, AcctInputOctets, AcctOutputOctets, CalledStationId, CallingStationId, AcctTerminateCause, ServiceType, FramedProtocol, FramedIPAddress) VALUES('81600002', '69913b8866eac834270ab589229ef6ab', 'test@orbit', '', '192.168.1.200', 'LAN', 'Ethernet', DATEADD(second, -1 * (121), GETDATE()), GETDATE(), NULL, 121, 'RADIUS', '', NULL, convert(bigint, '0' * POWER(2.0, 32)) | '95438', convert(bigint, '0' * POWER(2.0, 32)) | '45977', 'PPPoE', 'D8:C4:97:15:C1:F8', NULL, 'Framed-User', 'PPP', '192.168.10.255') (3) WISPSQL: SQL query returned: success (3) WISPSQL: -1 record(s) updated To disable insert i check if there is already a record for the same session IF NOT EXISTS(SELECT 1 FROM radacct WHERE AcctUniqueId = '%{Acct-Unique-Session-Id}') To check true affected rows count i added an unlang statement in accounting section, it does not do anything but just to check if sql server returns true count: update control { Tmp-Integer-0 = "%{WISPSQL:SELECT @@ROWCOUNT}" } (3) EXPAND %{WISPSQL:SELECT @@ROWCOUNT} (3) --> 1 (3) Tmp-Integer-0 = 1 as seen it returns count as 1. I also checked affected rows count by freetds utility tsql and saw that it returns true values with select @@ROWCOUNT statement. I downloaded freeradius source code from gitHub to see if i can find anything about the way it gets affected rows count: the 2 methods in rlm_sql_freetds.c file related are: static int sql_num_rows(rlm_sql_handle_t *handle, UNUSED rlm_sql_config_t *config) { rlm_sql_freetds_conn_t *conn = handle->conn; CS_INT num; if (ct_res_info(conn->command, CS_ROW_COUNT, &num, CS_UNUSED, NULL) != CS_SUCCEED) { ERROR("rlm_sql_freetds: error retrieving row count"); return RLM_SQL_ERROR; } return num; } static int sql_affected_rows(rlm_sql_handle_t *handle, rlm_sql_config_t *config) { return sql_num_rows(handle, config); } the second being a recall of the first. Here ct_res_info method (cannot find its definition) returns affected_rows count, may be its a freetds library method or calling a method from library, and seems that that freetds library method does not do its job. Can't it be possible to use a direct call to sql server to get @@ROWSCOUNT by a select statment to get affected rows count? 2- Virtual Servers - nas_table Server Column Problem I want to use vertiaul servers and add specific clients to specific servers. And to do that i set Server columns of nas_table records with virtual server name for wich i want to attach. I encountered 2 problems with this method: 1 - Multiple clients cannot be added to the same virtual server, if tried get error like: rlm_sql (sql): Processing generate_sql_clients rlm_sql (sql): Executing select query: SELECT Id, IPAddress, ShortName, 'other', Secret, ISNULL(Server, '') FROM nas WHERE IsActive = 1 rlm_sql (sql): Adding client 10.5.50.1 (home) to default clients list rlm_sql (10.5.50.1): Client "home" (sql) added rlm_sql (sql): Adding client 192.168.1.210 (citylight) to default clients list Failed to associate clients with virtual server default Failed to add client, possible duplicate? Although there is no other client with same Name (IPAddress) it cannot add second client. 2- If it gets an Access-Request it errors with "from unknown client" even if the client is added and same client works if it is made global, some lines from debug: rlm_sql (WISPSQL): Adding client 192.168.1.200 (orbitalanya) to WISPServer clients list rlm_sql (192.168.1.200): Client "orbitalanya" (WISPSQL) added Error with Access-Request: Ignoring request to auth address * port 2812 bound to server WISPServer from unknown client 192.168.1.200 port 49390 proto udp I attached debug output as file debug_VirtualServers.txt I got an answer from Mr. Alan DeKok on Wed, Jul 29 at 2:59 PM for my previous email for the same problem. >> I've pushed a fix. You can download the latest version of v3.0.x from gthub. Alan DeKok I have downloaded source https://github.com/FreeRADIUS/freeradius-server/archive/v3.0.x.zip and installed 3.0.22 but still get same error. Is it wrong version or do i do something wrong with configuration? Thanks.

2 2

RE: EAP-TLS Signature Check Failure
by Peter Bance 12 Aug '20

12 Aug '20

2 months later, a quick update on this topic (apologies, I may have broken the threading as I don't have a copy of the original e-mails any more!), just so there's an online reference here for anyone encountering the same error. Turns out I was wrong about it being Windows and OpenSSL getting muddled over TLS 1.2 vs. 1.3... To recap: Windows 10 clients, corporate WiFi network using EAP-TLS to RADIUS with machine certificate (SCEP) authentication only. Error in Freeradius logs: (6) eap_tls: ERROR: TLS Alert write:fatal:decrypt error tls: TLS_accept: Error in error (6) eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read) (6) eap_tls: ERROR: error:0407E086:rsa routines:RSA_verify_PKCS1_PSS_mgf1:last octet invalid (6) eap_tls: ERROR: error:1417B07B:SSL routines:tls_process_cert_verify:bad signature (6) eap_tls: ERROR: System call (I/O) error (-1) (6) eap_tls: ERROR: TLS receive handshake failed during operation (6) eap_tls: ERROR: [eaptls process] = fail After encountering the error on a few machines again, even with "tls_max_version" set, I delved into the guts of Windows again, and found the error (which isn't helpful or descriptive) was actually caused because: * Some machine certificates had were stored/managed by the "Microsoft Platform Crypto Provider" (TPM-backed) * Built-in security measures control access to keys in that CSP, and it cannot be used non-interactively * Windows WiFi profile was set to auto-join (non-interactive) * Windows couldn't get the key, so $deity knows what signature it was sending * OpenSSL rightly got confused The solution: Ensure machine certificate keys are stored in the "Microsoft Software Key Storage Provider" (or another CSP/KSP that permits non-interactive use). All is well again, and I'm close to shutting down NPS :-) -- Peter Bance Information Security Adviser Alan DeKok wrote: > A final update on this, in case anyone here's interested (or to "wrap > up" for anyone stumbling across this thread online) - I fixed it, and > Windows clients are now happily joining WiFi. It's a beautiful thing to > behold :-) > > In the end, I had to force OpenSSL on FreeRADIUS to stop offering > TLS1.3 ciphers using the mods/eap config: > > tls_max_version = "1.2" Good to hear. > It seems there may be a bug in OpenSSL 1.1.1 such that even though the > negotiation resulted in a TLS 1.2 session, the weird back-port of TLS > 1.3 ciphers into TLS 1.2 confused things (a lot), and it tried checking > for TLS 1.3 style signatures inappropriately. Weird, but OK. It's OpenSSL :( Alan DeKok.

1 0

Windows 10 does not response EAP-Request/Identity from Switch after sucessfuly authentication of 802.1X
by luckydog xf 12 Aug '20

12 Aug '20

Hello, This may not be a question of Freeradius, but I post it here to see whether someone ran into the same issue before and found a way to fix it. We're running H3C switch, configure eap authentication, client is windows 10 and uses certificate authentication. Initially windows 10 can be online and soon after that it goes offline. By checking freeradius log, we can see that accounting Acct-Status-Type is Start and later becomes Stop. We use wireshark to capture packets of windows 10 and find that, after it's successfully online, Switch sends EAP-Request/Identity to it and expects a response. Yet windows 10 ignores it. Switch sends a 'Stop' to Freeradius when it's timeout. The whole process is listed http://www.h3c.com/en/Support/Resource_Center/Technical_Documents/Home/Swit… [ EAP relay ] section. 11. After the client comes online, the access device periodically sends handshake requests to check whether the client is still online. By default, if two consecutive handshake attempts fail, the device logs off the client. 12. Upon receiving a handshake request, the client returns a response. If the client fails to return a response after a number of consecutive handshake attempts (two by default), the access device logs off the client. This handshake mechanism enables timely release of the network resources used by 802.1X users that have abnormally gone offline. So it's quite weird, why does Windows 10 ignore it ? Appreciated for any help. Thanks.

1 1

MSCHAPV2 + OpenLDAP
by Клеусов Владимир Сергеевич 11 Aug '20

11 Aug '20

Hi Source data: OpenLDAP FreeRADIUS Version 3.0.21 I am trying to configure authentication via freeradius client VPN. Users in OpenLDAP . The problem is that the standard MacOS vpn client works via ms chap v2 (in the debut mode, I see the Client is using MS-CHAPv2). I would be grateful for help if someone had experience setting up in this configuration.

7 13

EXEC : possible to update pairs directly?
by FRANKS, Andy (SHREWSBURY AND TELFORD HOSPITAL NHS TRUST) 11 Aug '20

11 Aug '20

Hi all, Just researching possibilities to help me around the upgrades I need to do to move from old operating systems and FR3.1. I tried v4 for a while, and may go back to that, but am struggling with the exec module race condition - the dilemma is that I can't spend too long redoing what we used to do in exec. I've gone back to v3.0.22 to see what I can do there, but missed the SQL maps bit quite a bit so have do a few quick tests to see what I can achieve in the exec module, expanding my knowledge as it were. The following url contains an example that would be useful, but I can't get it working in 3.0.22 : https://stackoverflow.com/questions/26442693/freeradius-reading-attributes-… In the example Arran says : "Version 3 supports attribute assignment similar to what you've posted, but it'd be: update { control: += `/usr/bin/php -f /web/auth.php '%{NAS-Identifier} %{Calling-Station-Id}'` } Then modify your script output to be: Auth-Type = Accept reply:WISPr-Bandwidth-Max-Up = xxx .. " The key question is the inclusion of "reply:" attribute in an update { control : } section - it would be useful to be able to update any pairs via exec, not just the control (in this example), as you can do directly via Update [ Reply:reply-message := .. Control:auth-type := .. } When I try the example above, FR 3.0.22 can't parse the output: ERROR: Failed parsing output from: /usr/bin/php -f /etc/freeradius/sql_active_device_check_accounting.php -- '--hostname %{control:Hostname} --username %{request:User-Name} --nasipaddress %{request:NAS-IP-Address} --nasport %{request:NAS-Port} --macaddresslimit %{%{control:MacAddressLimit}:-0}': Expecting operator (0) ERROR: Program returned code (0) and output 'Auth-Type = Accept,reply:WISPr-Bandwidth-Max-Up = 123' It works if removing the reply: specifier from the "reply:WISPr-Bandwidth-Max-Up", i.e. Program returned code (0) and output 'Auth-Type = Accept,WISPr-Bandwidth-Max-Up = 123' (0) control::Auth-Type = Accept (0) control::WISPr-Bandwidth-Max-Up = 123 It's not the end of the world to have to copy the attributes from one "set" to another, but was hoping to be a bit cleaner if possible. IT's possible I just don't have the right syntax. Also happy taking advice on how best to replicate sql maps and attribute pair functionality best, possibly in python or perl I suppose, although those seem more "fixed" at a glance than exec. Thanks! Andy ******************************************************************************************************************** This message may contain confidential information. If you are not the intended recipient please inform the sender that you have received the message in error before deleting it. Please do not disclose, copy or distribute information in this e-mail or take any action in relation to its contents. To do so is strictly prohibited and may be unlawful. Thank you for your co-operation. NHSmail is the secure email and directory service available for all NHS staff in England and Scotland. NHSmail is approved for exchanging patient data and other sensitive information with NHSmail and other accredited email services. For more information and to find out how you can switch, https://portal.nhs.net/help/joiningnhsmail

2 2