Description
This article describes some basic troubleshooting of RADIUS over TLS (RADSEC) in the RADIUS over TLS in FortiGate.
Scope
FortiGate 7.4 and above.
Solution
Below is the configuration on the FortiGate to enable Radius over TLS (RADSEC):
config user radius
edit "FAC"
set server "fac.example.com"
set secret ENC +TxEMrLUDsM+RtnLOhNte3brXzgmXgeRLkm6vdpPAJhOO2UpljS4YmnymnpscmAMk9y26cT+hdgRDuo3KeyunYwqO4yLwxOCBvma+pqOFi7mogDObAyDEphlsiYzygsNQe4Njd/N+Qe27RXcxFO7OEURS0IW0faR/DwH0P6MqHVwuLo/YpNMiPCD+YDqIKcNNK+xk7==
set radius-port 2083
set auth-type pap
set transport-protocol tls <-----
next
end
- The above option 'transport-protocol' has been added since v7.4, which gives the options of 'udp/tcp/tls'.
- For wireless users the FortiAP supports RADSec starting version 7.6; in prior versions, it uses UDP 2083 instead of TCP.
- This document explains more on this topic: Add RADSEC client support.
When the radius over TLS(RADSEC) is enabled:
- It could be possible to see 'Can't contact RADIUS server'.
- Make sure that it is possible to telnet the server IP on port 2083 from the firewall, using the below command:
exec telnet x.x.x.x 2083
Note: x.x.x.x is the IP address of the server.
- The above could happen when the TCP port 2083 from the firewall is not allowed on the server or any firewall in transit. By default simple radius uses protocol UDP and ports 1812/1645 and 1813/1646 (for accounting).
- When Radius over TLS (RADSEC) is enabled, the communication shifts to TCP 2083.
- Make sure the TCP 2083 is allowed in the transit firewalls and on the server.
2. Once the connectivity is verified, it can be possible to see 'Error checking RADIUS connectivity'.
- If seeing the above error, check what is the configuration on the firewall done, is it the server FQDN or server IP?
- If it is IP, make sure the certificate shared by the server contains the IP of the server as CN/SAN.
- If it is FQDN, make sure the certificate shared by the server contains the FQDN as the CN/SAN.
- It is possible to validate the same from the fnbamd debugs:
tachyon-kvm36 # [1729] handle_req-Rcvd auth req 652312454 for test01 in opt=0100000d prot=0
[457] __compose_group_list_from_req-Group '', type 1
[51] radius_start-eap_local=0
[885] fnbamd_cfg_get_radius_list-
[369] fnbamd_rad_new-10.14.1.55
[171] __init_rad_setting-Preping auth servers.
[154] __rad_server_push-Inserted rad server '10.14.1.55'. <<<<<< my server is configured with IP 10.14.1.55 instead of FQDN.
[373] fnbamd_rad_new-10.14.1.55 created
[907] fnbamd_cfg_get_radius_list-Total rad servers to try: 1
[925] fnbamd_rad_get_auth_server-
[2378] fnbamd_create_ssl_ctx-SSL CTX is created.
[306] __rad_create_ssl_ctx-SSL CTX is created for rad server 10.14.1.55.
[296] fnbamd_radius_get_next_auth_prot-Next auth prot PAP
[976] __auth_ctx_svr_push-Added addr 10.14.1.55:2083 from rad '10.14.1.55'
[815] __fnbamd_rad_get_next_addr-Next available address of rad '10.14.1.55': 10.14.1.55:2083.
[994] __auth_ctx_start-Connection starts 10.14.1.55:10.14.1.55, addr 10.14.1.55:2083 proto: TCP over TLS <<<<< connection to server on port 2083 is initiated.
[446] __rad_tcps_open-vfid 0, addr 10.14.1.55, src_ip (null), ssl_opt 1284
[478] __rad_tcps_open-Server identity check is enabled. <<<<<<<<<< firewall verified that server identity check is enabled
[492] __rad_tcps_open-Still connecting 10.14.1.55.
[508] __rad_tcps_open-Start rad conn timer.
[830] __rad_start_conn-Socket 11 is created for rad '10.14.1.55'.
[701] __rad_add_job_timer-
[616] fnbamd_pop3_start-test01
[618] create_auth_session-Total 1 server(s) to try
[1780] handle_req-r=4
[2309] __verify_cb-Cert error 64, IP address mismatch. Depth 0. Subject '/CN=fac.example.com' <<<<<< firewall after receiving the cert, verified that IP configured on firewall for Radius is different to the CN received in the cert, in the cert we have received the FQDN fac.example.com.
[404] __rad_tcps_connect-tcps_connect(10.14.1.55) failed: ssl_connect() failed: 167772294 (error:0A000086:SSL routines::certificate verify failed). <----- Firewall generates and error certificate verify failed as the CN mismatch.
[907] __rad_error-Ret 5, st = 0.
[296] fnbamd_radius_get_next_auth_prot-Next auth prot PAP
- The above can also be verified from the pcap:
- In the above screenshot, it is possible to see the firewall sending the SSL Alert (Bad Certificate) error, as there is no matching CN.
- In case they are mismatching and it is wanted to be connected on the firewall, there is a workaround. Follow the below commands:
tachyon-kvm36 # config user radius
tachyon-kvm36 (radius) # edit FAC
tachyon-kvm36 (FAC) # set server-identity-check disable <----- Set this setting to disable.
tachyon-kvm36 (FAC) # end
- The above will make the firewall ignore the identity of the fqdn or IP to that of certificates CN/SAN.
- Let's verify the debug again, after disabling the server-identity-check in RADIUS:
tachyon-kvm36 # [1729] handle_req-Rcvd auth req 652312455 for test01 in opt=0100000d prot=0
[457] __compose_group_list_from_req-Group '', type 1
[51] radius_start-eap_local=0
[885] fnbamd_cfg_get_radius_list-
[369] fnbamd_rad_new-10.14.1.55
[171] __init_rad_setting-Preping auth servers.
[154] __rad_server_push-Inserted rad server '10.14.1.55'.
[373] fnbamd_rad_new-10.14.1.55 created
[907] fnbamd_cfg_get_radius_list-Total rad servers to try: 1
[925] fnbamd_rad_get_auth_server-
[2378] fnbamd_create_ssl_ctx-SSL CTX is created.
[306] __rad_create_ssl_ctx-SSL CTX is created for rad server 10.14.1.55.
[296] fnbamd_radius_get_next_auth_prot-Next auth prot PAP
[976] __auth_ctx_svr_push-Added addr 10.14.1.55:2083 from rad '10.14.1.55'
[815] __fnbamd_rad_get_next_addr-Next available address of rad '10.14.1.55': 10.14.1.55:2083.
[994] __auth_ctx_start-Connection starts 10.14.1.55:10.14.1.55, addr 10.14.1.55:2083 proto: TCP over TLS <----- Connection to server on port 2083 is initiated.
[446] __rad_tcps_open-vfid 0, addr 10.14.1.55, src_ip (null), ssl_opt 1284
[492] __rad_tcps_open-Still connecting 10.14.1.55.
[508] __rad_tcps_open-Start rad conn timer.
[830] __rad_start_conn-Socket 11 is created for rad '10.14.1.55'.
[701] __rad_add_job_timer-
[616] fnbamd_pop3_start-test01
[618] create_auth_session-Total 1 server(s) to try
[1780] handle_req-r=4
[415] __rad_tcps_connect-tcps_connect(10.14.1.55) is established. <----- Connection established to the RADIUS on port 2083 without any cert error.
- If the CN matches the IP/FQDN configured on the firewall and if there is still the same error, check if the firewall has the root that signed the server cert.
- The above can again be verified by using fnbamd:
tachyon-kvm36 # [1729] handle_req-Rcvd auth req 652312476 for test01 in opt=0100000d prot=0
[457] __compose_group_list_from_req-Group '', type 1
[51] radius_start-eap_local=0
[885] fnbamd_cfg_get_radius_list-
[369] fnbamd_rad_new-fac.example.com
[171] __init_rad_setting-Preping auth servers.
[154] __rad_server_push-Inserted rad server 'fac.example.com'.
[373] fnbamd_rad_new-fac.example.com created
[907] fnbamd_cfg_get_radius_list-Total rad servers to try: 1
[925] fnbamd_rad_get_auth_server-
[2378] fnbamd_create_ssl_ctx-SSL CTX is created.
[306] __rad_create_ssl_ctx-SSL CTX is created for rad server fac.example.com.
[296] fnbamd_radius_get_next_auth_prot-Next auth prot PAP
[115] fnbamd_dns_resolv_ex-DNS req ipv4 0x3c 'fac.example.com'
[125] fnbamd_dns_resolv_ex-DNS req ipv6 0x203c 'fac.example.com'
[137] fnbamd_dns_resolv_ex-DNS maintainer started.
[1067] fnbamd_rad_auth_ctx_init-Start rad conn timer.
[701] __rad_add_job_timer-
[616] fnbamd_pop3_start-test01
[618] create_auth_session-Total 1 server(s) to try
[1780] handle_req-r=4
[247] fnbamd_dns_parse_resp-got IPv4 DNS reply, req-id=0x3c
[306] fnbamd_dns_parse_resp-req 0x3c: 10.14.1.55
[1020] __fnbamd_rad_dns_cb-Resolved fac.example.com:fac.example.com to 10.14.1.55, cur stack size:-1
[976] __auth_ctx_svr_push-Added addr 10.14.1.55:2083 from rad 'fac.example.com'
[815] __fnbamd_rad_get_next_addr-Next available address of rad 'fac.example.com': 10.14.1.55:2083.
[994] __auth_ctx_start-Connection starts fac.example.com:fac.example.com, addr 10.14.1.55:2083 proto: TCP over TLS
[446] __rad_tcps_open-vfid 0, addr 10.14.1.55, src_ip (null), ssl_opt 1284
[492] __rad_tcps_open-Still connecting 10.14.1.55.
[508] __rad_tcps_open-Start rad conn timer.
[830] __rad_start_conn-Socket 11 is created for rad 'fac.example.com'.
[247] fnbamd_dns_parse_resp-got IPv6 DNS reply, req-id=0x203c
[266] fnbamd_dns_parse_resp-req 0x3c: wrong dns format, qr=1, opcode=0, qdc=1, ancount=0
[35] __fnbamd_dns_req_del-DNS req 0x3c (0x10240e98) is removed. Current total: 2
[47] __fnbamd_dns_req_del-DNS maintainer stopped.
[1020] __fnbamd_rad_dns_cb-Resolved fac.example.com:fac.example.com to ::, cur stack size:0
[982] __auth_ctx_svr_push-Failed to add addr fac.example.com from rad 'fac.example.com'
[2309] __verify_cb-Cert error 19, self-signed certificate in certificate chain. Depth 1. Subject '/CN=example.com' <<< self-signed certificate chain error, my server sends the cert and root, however firewall do not have the root for example.com which signed the fac.example.com.
[404] __rad_tcps_connect-tcps_connect(10.14.1.55) failed: ssl_connect() failed: 167772294 (error:0A000086:SSL routines::certificate verify failed).
[907] __rad_error-Ret 5, st = 0.
[296] fnbamd_radius_get_next_auth_prot-Next auth prot PAP
- The above can be verified from the pcap as well:
- In the above screenshot, the firewall sends SSL Alert(Unknown CA), which means the firewall does not have the root or chain signed the server cert.
- Once the firewall with root cert or the complete chain is uploaded, the error should not appear.
- If the issue is still there, make sure to collect the below logs on the firewall and create a ticket with TAC.
PUTTY 1:
diagnose sniffer packet any 'host x.x.x.x and port 2083' 6 0 l
PUTTY 2:
diagnose debug reset
diagnose debug application fnbamd -1
diagnose debug enable
Once the above commands are run in the putty sessions accordingly, test the connectivity, and once an error is seen, stop the debugs:
PUTTY 1:
CTRL+C
PUTTY 2:
diagnose debug disable
diagnose debug reset
