Fortiswitch RADIUS Authentication not arrives external RADIUS Server

[fabs]

Hello all,

I am currently setting up 802.x1 EAP-TLS authentication on an external cloud radius server on my FortiSwitch 448E-POE (Fortilink) and am experiencing a minor issue.
Basically, I wanted to do this via TLS TCP (RadSec).
I noticed that the FortiSwitches only send the packets as UDP. Presumably, the current FortiSwitch FW S448EP-v7.6.2-build1085,250526 (GA) does not support TLS over TCP, is that correct? In any case, there is no mention of “set transport-protocol tls” in the radius profile on the switch.
The FGT with FW v7.6.3 build3510 (feature) seems to support this; at least, I can see that the packets are sent as TCP and they also arrive on my RADIUS server.
In any case, I have now adjusted the RADIUS client so that it performs authentication via UDP on the RADIUS server. The query is also successful and arrives at the RADIUS server.

The problem is that when I try to authenticate on a port of the FortiSwitch, no packets arrive at the RADIUS server. In debug mode, I can see that packets are leaving switch 10.255.1.2, but nothing is arriving at the Radius server.

I have also created a firewall policy for testing: incoming interface fortilink_default / outgoing WAN / source all / destination all / service all

Regards

fabss

[Markus_M]

Hi fabs,

on FortiGate try to see if the packets are received and what happens to them.

For one, run a packet capture on CLI and test.

diag sniffer packet any 'port 1812' 4 0 l
If you see the packets coming on some inbound interface, but not leaving, see what the firewall thinks on how to handle such packets:

diag debug flow filter port 1812

diag debug flow show iprope enable

diag debug enable

diag debug flow trace start 5

If the environment is busy with RADIUS requests, 5 might be a value too low; choose another if the screen fills up, without your test. This is only the amount of packets that are shown for policy evaluation, but it also shows routing decisions for the packets.

[fabs]

Hi @Markus_M 

This is the debug:

FGT01 # diag sniffer packet any 'port 1812' 4 0 l
interfaces=[any]
filters=[port 1812]
2025-08-06 14:29:31.274621 port2 in 10.255.1.2.49609 -> 209.xx.xxx.xxx.1812: udp 149
2025-08-06 14:29:31.274630 fortilink in 10.255.1.2.49609 -> 209.xx.xxx.xxx.1812: udp 149
2025-08-06 14:30:09.365959 port2 in 10.255.1.2.36722 -> 209.xx.xxx.xxx.1812: udp 149
2025-08-06 14:30:09.365966 fortilink in 10.255.1.2.36722 -> 209.xx.xxx.xxx.1812: udp 149


FGT01 # id=65308 trace_id=23 func=print_pkt_detail line=6138 msg="vd-root:0 received a packet(proto=17, 10.255.1.2:40719->209.xx.xxx.xxx:1812) tun_id=0.0.0.0 from fortilink. "
id=65308 trace_id=23 func=init_ip_session_common line=6344 msg="allocate a new session-002558a0"
id=65308 trace_id=23 func=iprope_dnat_check line=5541 msg="in-[fortilink], out-[]"
id=65308 trace_id=23 func=iprope_dnat_tree_check line=836 msg="len=0"
id=65308 trace_id=23 func=iprope_dnat_check line=5566 msg="result: skb_flags-02000000, vid-0, ret-no-match, act-accept, flag-00000000"
id=65308 trace_id=23 func=vf_ip_route_input_common line=2615 msg="find a route: flag=04000000 gw-81.xx.xx.xx via wan1"
id=65308 trace_id=23 func=__iprope_fwd_check line=828 msg="in-[fortilink], out-[wan1], skb_flags-02000000, vid-0, app_id: 0, url_cat_id: 0"
id=65308 trace_id=23 func=__iprope_tree_check line=528 msg="gnum-100004, use int hash, slot=71, len=2"
id=65308 trace_id=23 func=__iprope_check_one_policy line=2166 msg="checked gnum-100004 policy-7, ret-no-match, act-accept"
id=65308 trace_id=23 func=__iprope_check_one_policy line=2166 msg="checked gnum-100004 policy-0, ret-matched, act-accept"
id=65308 trace_id=23 func=__iprope_user_identity_check line=1929 msg="ret-matched"
id=65308 trace_id=23 func=__iprope_check_one_policy line=2402 msg="policy-0 is matched, act-drop"
id=65308 trace_id=23 func=__iprope_fwd_check line=865 msg="after iprope_captive_check(): is_captive-0, ret-matched, act-drop, idx-0"
id=65308 trace_id=23 func=iprope_fwd_auth_check line=894 msg="after iprope_captive_check(): is_captive-0, ret-matched, act-drop, idx-0"
id=65308 trace_id=23 func=iprope_shaping_check line=992 msg="in-[fortilink], out-[wan1], skb_flags-02000000, vid-0"
id=65308 trace_id=23 func=__iprope_check line=2432 msg="gnum-100015, check-ffffffbffc02cad0"
id=65308 trace_id=23 func=__iprope_check_one_policy line=2166 msg="checked gnum-100015 policy-1, ret-no-match, act-accept"
id=65308 trace_id=23 func=__iprope_check line=2449 msg="gnum-100015 check result: ret-no-match, act-accept, flag-00000000, flag2-00000000"
id=65308 trace_id=23 func=iprope_policy_group_check line=4961 msg="after check: ret-no-match, act-accept, flag-00000000, flag2-00000000"
id=65308 trace_id=23 func=fw_forward_handler line=839 msg="Denied by forward policy check (policy 0)"

Am I correct in assuming that the firewall policy is not matching and the connection is blocked?
If so, why? I selected “_default.fortilink (_default)” as the incoming interface.

Regards

fabs 

[fabs]

Hello again,

is it possible that I need to add an additional route to the radius server? 

[Markus_M]

Hi fabs,

quite so. See this line:

id=65308 trace_id=23 func=vf_ip_route_input_common line=2615 msg="find a route: flag=04000000 gw-81.xx.xx.xx via wan1

It seems that the traffic is routed towards the wan1, not where it probably is supposed to go. Is that the intended destination IP?

To check the route:

get router info routing details 209.xx.xxx.xx

Sample output from my lab:

FGT # get router info routing detail 192.168.38.38

Routing table for VRF=0
Routing entry for 192.168.38.0/24
 Known via "connected", distance 0, metric 0, best
 * is directly connected, port4

[fabs]

@Markus_M 
The traffic should go via WAN1 because the RADIUS Server is cloud based.
The get router looks ok:

FGT01 # get router info routing details 209.xx.xxx.xxx

Routing table for VRF=0
Routing entry for 0.0.0.0/0
  Known via "static", distance 10, metric 0, best
  * vrf 0 81.xx.xx.xx, via wan1

but what means

id=65308 trace_id=23 func=fw_forward_handler line=839 msg="Denied by forward policy check (policy 0)"

[fabs]

I'm also not able to ping the external RADIUS Server from the switches.
Telnet is also not working.

[Markus_M]

Denied by forward policy check (policy 0)

There is no policy allowing the traffic. If this is really intended to go via wan1, see to use RADSEC or some method to have this traffic encrypted. RADIUS is plaintext mostly.

[fabs]

Hello @Markus_M 
We cannot use RADSEC (TLS TCP) since for my understanding the FortiSwitch 7.6.2 not support Radius TLS via TCP yet. Is this correct?

Further I do not understand why there is no policy which allows the traffic, since I created one policy for testing.
Incoming Interface: _default.fortilink (_default)
Outgoing Interface: WAN1
Source: all
Destination: all
Service: ALL
NAT: enabled

[fabs · Accepted solution]

Okay, I was able to resolve it.
The correct interface is not “_default.fortilink (_default)” but “fortilink”

This was not visible in the GUI, so I had to adjust the policy via CLI.