Fortinet Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
aguerriero
New Contributor

7.0.X possible IPS bug with VWP and RADIUS

I am using the default IPS profile and for some reason radius traffic is being blocked but logs are not showing it being blocked. If I disable IPS on the bottom rule and disable certificate inspection radius traffic works.  But if I create a higher rule with the specific source/destination IP address and port the traffic matches the rule and the radius traffic is still blocked.  It is only when I disable the IPS inspection on the bottom rule is when it works. 

17 REPLIES 17
Kangming
Staff
Staff

Hi

Cloud you try to cap Radius packets:

# diagnose sniffer packet any "port 1812 or port 1813" 4 0 l  

 

I will try it in LAB.

Thanks

Kangming

aguerriero

I can see the packets in the capture but the client connected to port B never gets authenticated.  The only time the authentication is successful is if I disable APP/IPS/SSL inspection and only on the bottom rule that is ALL/ALL/ALL. A custom rule with specific /32 addresses doesn't work even if I drag it to the top. 

 

interfaces=[any] filters=[port 1812 or port 1813] 66.219392 b in 10.0.10.1.1645 -> 10.0.10.17.1812: udp 74 66.219468 a out 10.0.10.1.1645 -> 10.0.10.17.1812: udp 74 66.223051 a in 10.0.10.17.1812 -> 10.0.10.1.1645: udp 146 66.223068 b out 10.0.10.17.1812 -> 10.0.10.1.1645: udp 146

Kangming

It seems normal in my environment, my FGT is FGT-VM04.

 

VWP # diagnose sniffer packet any "port 1812 or port 1813" 4 0 l Using Original Sniffing Mode interfaces=[any] filters=[port 1812 or port 1813] 2021-09-10 11:38:58.406011 port2 in 10.6.30.111.11776 -> 10.6.30.225.1812: udp 113 2021-09-10 11:38:58.406552 port3 out 10.6.30.111.11776 -> 10.6.30.225.1812: udp 113 2021-09-10 11:38:58.433666 port3 in 10.6.30.225.1812 -> 10.6.30.111.11776: udp 20 2021-09-10 11:38:58.433767 port2 out 10.6.30.225.1812 -> 10.6.30.111.11776: udp 20

 

What is your FGT model? Can the Radius packets of the VWP interface be directly captured? 

You should be able to know the reason for the rejection by opening and viewing the content in the radius packet through wireshark.

Thanks

Kangming

aguerriero

It is a 60F using a VWP with the A/B ports. The packet isn't being modified. Captured on both sides. It never leaves the fortigate unless the rule is modified.

This is happening on 4 new 60Fs running 7.0.1. 

Kangming

Is Radius used for device login authentication? Or is it used for user authentication such as WIFI? My test is just a Radius user login authentication of an FGT.

 

Please take a debug flow to see if there is an IPS engine involved when it fails:

 

diagnose debug flow filter proto 17 diagnose debug flow filter addr 10.0.10.17 diagnose debug flow filter dport 1812 diagnose debug flow show function-name enable diagnose debug flow show console enable diagnose debug flow trace start 100 diagnose debug enable

Thanks

Kangming

Kangming

 

It may be affected by N-turbo. You can also try to turn off N-turbo. I'll find a hardware firewall to test this issue. My firewall is currently a VM, so there is no N-turbo.

 

Disable N-trubo:

config firewall policy edit 22 (policy id)

set np-acceleration disable

end

Thanks

Kangming

Kangming

Hi 

I found a FGT401E NP6 firewall configured with VWP, and it seems that your issue cannot be reproduced. Cloud you share your configuration and topology diagram with me? My email is kmliu@fortinet.com.

Thanks

Kangming

aguerriero

I found that it is the accounting portion that isn't working. Debugs didn't show anything if APP or IPS inspection is enabled. SSL inspection doesn't seem to matter. I also disabled NP as recommended earlier.  I can create a rule that is higher in the order and set everything to disabled on that specific rule and it is still broken If the all, all, ALL rule exists with any control or inspection enabled the flow and sniffer shows zero traffic on port 1813. This is the capture for when all inspections are disabled.

 

diagnose debug flow filter proto 17 diagnose debug flow filter addr 10.0.5.17 diagnose debug flow filter dport 1812 diagnose debug flow show function-name enable diagnose debug flow show console enable diagnose debug flow trace start 100 diagnose debug enable diagnose sniffer packet any "port 1812" 4 0 l interfaces=[any] filters=[port 1812] id=20085 trace_id=40 func=print_pkt_detail line=5746 msg="vd-root:0 received a packet(proto=17, 10.0.5.128:35575->10.0.5.17:1812) from b. " id=20085 trace_id=40 func=init_ip_session_common line=5918 msg="allocate a new session-00edf706" id=20085 trace_id=40 func=br_fw_forward_handler line=574 msg="Allowed by Policy-8:" id=20085 trace_id=40 func=__if_queue_push_xmit line=394 msg="send out via dev-a, dst-mac-00:15:5d:00:55:06" 2021-09-20 12:09:08.930803 b in 10.0.5.128.35575 -> 10.0.5.17.1812: udp 157 2021-09-20 12:09:08.930883 a out 10.0.5.128.35575 -> 10.0.5.17.1812: udp 157 2021-09-20 12:09:10.413053 a in 10.0.5.17.1812 -> 10.0.5.128.35575: udp 278 2021-09-20 12:09:10.413072 b out 10.0.5.17.1812 -> 10.0.5.128.35575: udp 278

diagnose debug flow filter proto 17 diagnose debug flow filter addr 10.0.5.17 diagnose debug flow filter dport 1813 diagnose debug flow show function-name enable diagnose debug flow show console enable diagnose debug flow trace start 100 diagnose debug enable diagnose sniffer packet any "port 1813" 4 0 l interfaces=[any] filters=[port 1813] id=20085 trace_id=42 func=print_pkt_detail line=5746 msg="vd-root:0 received a packet(proto=17, 10.0.5.128:47051->10.0.5.17:1813) from b. " id=20085 trace_id=42 func=init_ip_session_common line=5918 msg="allocate a new session-00edfcda" id=20085 trace_id=42 func=br_fw_forward_handler line=574 msg="Allowed by Policy-8:" id=20085 trace_id=42 func=__if_queue_push_xmit line=394 msg="send out via dev-a, dst-mac-00:15:5d:00:55:06" 2021-09-20 12:10:05.382523 b in 10.0.5.128.47051 -> 10.0.5.17.1813: udp 167 2021-09-20 12:10:05.382624 a out 10.0.5.128.47051 -> 10.0.5.17.1813: udp 167 2021-09-20 12:10:05.383178 a in 10.0.5.17.1813 -> 10.0.5.128.47051: udp 20 2021-09-20 12:10:05.383195 b out 10.0.5.17.1813 -> 10.0.5.128.47051: udp 20

---------------------------------------------------------------------------------------------------------------------------------------------

This is with either app control or ips enabled. Enabling either one or both causes this. The fortigate does not see the 1813 traffic at all. 

 

diagnose debug flow filter proto 17 diagnose debug flow filter addr 10.0.5.17 diagnose debug flow filter dport 1812 diagnose debug flow show function-name enable diagnose debug flow show console enable diagnose debug flow trace start 100 diagnose debug enable diagnose sniffer packet any "port 1812" 4 0 l interfaces=[any] filters=[port 1812] id=20085 trace_id=44 func=print_pkt_detail line=5746 msg="vd-root:0 received a packet(proto=17, 10.0.5.128:34782->10.0.5.17:1812) from b. " id=20085 trace_id=44 func=init_ip_session_common line=5918 msg="allocate a new session-00ee0b4a" id=20085 trace_id=44 func=br_fw_forward_handler line=574 msg="Allowed by Policy-8:" id=20085 trace_id=44 func=br_route_ipv4 line=328 msg="find a reply route:smac-00:15:5d:00:55:06, dmac-10:56:ca:13:2d:3c, via b" id=20085 trace_id=44 func=br_route_ipv4 line=343 msg="find a route:smac-10:56:ca:13:2d:3c, dmac-00:15:5d:00:55:06, via a" id=20085 trace_id=44 func=__if_queue_push_xmit line=394 msg="send out via dev-a, dst-mac-00:15:5d:00:55:06" id=20085 trace_id=44 func=np6xlite_hif_nturbo_build_vtag line=1101 msg="vtag->magic d153beef, vtag->coretag 72, vtag->vid 0 vtag->sip[0] 0, vtag->sip[1] 0, vtag->sip[2] 0, vtag->sip[3] 0 vtag->sport 0, vtag->mtu 1500, vtag->flags 10, vtag->np6_flag 0x0, skb->npu_flag=0xc0880" 2021-09-20 12:12:44.540100 b in 10.0.5.128.34782 -> 10.0.5.17.1812: udp 157 2021-09-20 12:12:44.540241 a out 10.0.5.128.34782 -> 10.0.5.17.1812: udp 157 2021-09-20 12:12:44.972620 a in 10.0.5.17.1812 -> 10.0.5.128.34782: udp 278 2021-09-20 12:12:44.972641 b out 10.0.5.17.1812 -> 10.0.5.128.34782: udp 278

 

diagnose debug flow filter proto 17 diagnose debug flow filter addr 10.0.5.17 diagnose debug flow filter dport 1813 diagnose debug flow show function-name enable diagnose debug flow show console enable diagnose debug flow trace start 100 diagnose debug enable diagnose sniffer packet any "port 1813" 4 0 l interfaces=[any] filters=[port 1813]

 

Kangming

Does it mean that IPS may have discarded Radius 1813 packets?

Thanks

Kangming