7.0.X possible IPS bug with VWP and RADIUS

[aguerriero]

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. 

[aguerriero]

I don't know. The debug and sniffer doesn't show anything happening to those packets if app control or IPS is enabled. I am using the default app and ips profiles.  The minute I disable them, radius works and I get debugs. If I enable either of them radius no longer works.

The same policies work on 6.2.X

[Kangming]

Could you share your configuration?

The following configuration on my side looks normal:

config system virtual-wire-pair edit "VWP" set member "port18" "port23" set wildcard-vlan enable next end

config firewall policy edit 4 set name "ALL-TO-ALL" set srcintf "port18" "port23" set dstintf "port18" "port23" set action accept set srcaddr "all" set dstaddr "all" set schedule "always" set service "ALL" set utm-status enable set inspection-mode proxy set ssl-ssh-profile "certificate-inspection" set av-profile "g-default" set ips-sensor "g-default" set application-list "g-default" set logtraffic all next end

FortiGate-401E (root) # dia sni pa any "port 1812 or port 1813" 4 0 l interfaces=[any] filters=[port 1812 or port 1813] 2021-09-21 15:09:37.350876 port18 in 10.6.30.225.1812 -> 17.24.1.2.10404: udp 20 2021-09-21 15:09:37.350881 port23 out 10.6.30.225.1812 -> 17.24.1.2.10404: udp 20 2021-09-21 15:09:37.351242 port23 in 17.24.1.2.1734 -> 10.6.30.225.1813: udp 135 2021-09-21 15:09:37.351254 port18 out 17.24.1.2.1734 -> 10.6.30.225.1813: udp 135 2021-09-21 15:09:42.359757 port23 in 17.24.1.2.1734 -> 10.6.30.225.1813: udp 139 2021-09-21 15:09:42.359772 port18 out 17.24.1.2.1734 -> 10.6.30.225.1813: udp 139 2021-09-21 15:09:47.360043 port23 in 17.24.1.2.1734 -> 10.6.30.225.1813: udp 139 2021-09-21 15:09:47.360053 port18 out 17.24.1.2.1734 -> 10.6.30.225.1813: udp 139 ^C

[Kangming]

Hello, Could you provide some more detailed information, if this is indeed the issue, we hope to reproduce it and fix it in the next GA version, but it is currently impossible to reproduce this issue in lab. 

Thank you.

[aguerriero]

It is even worse. DHCP doesn't even pass through the device unless IPS and APP are disabled on the all,all,ALL rule. The configuration is just a VWP on the A/B ports of a 60F.

B connects to a peplink and A connects to a ubiquity switch. There is a permit rule in each direction with all, all, ALL. Traffic that doesn't work so far are DHCP and Radius 1813. There are probably other protocols. There are 5 sites with this problem all using a 60F, 7.0.1, and A/B as a VWP.  Even after restoring factory and configuring the fortigate as basic as possible certain traffic will not pass if the all, all, ALL rule at the very bottom of the policies has IPS or APP enabled. Even though higher order rules may match traffic according to the sniffer and diags the mere fact that the all, all, ALL rule exists breaks everything. Enabling the IPS/APP stops all sniffer/diag traffic for DHCP and radius 1813

[Kangming]

Hi Aguerruero,

Thanks for your feedback.

DHCP Discover dropped on virtual wire pair when UTM enabled. It is a known issue and it has been fixed in V7.0.2 (interim). BUG ID 0728647

But the issue Radius 1813 discards, we cannot reproduce it here, and there is no internal bug tracking at present.

What is Radius used for? WIFI user authentication? Device login authentication? There is no such problem in my environment. 1813 can be passed smoothly. Can a packet of Radius 1813 be captured by wireshark?  What kind of usage scenario is your Radius server?

In addition, when Radius 1813 pass fails, does the IPS have any utm-log display?

[Kangming]

Maybe the FGT401F I tested is NP6 platform, FGT60F is np6xlite, I will find a FGT60F to test to see if it can reproduce, thank you.

[aguerriero]

Radius is used for L2TP/IPSEC VPN on a peplink. The peplink is on the 60F port b and the ubiquity switch is on the 60F port a.

I do not get any logs related to radius and all diags and sniffers show nothing for port 1813. This happens if either app control or IPS is enabled.

I have downgraded one of the fortigates to 6.4.7 and radius is working, but 6.4.7 still has the DHCP issue.  I am about ready to start a trouble ticket with fortinet when I can get a person over to one of the sites again. I will let the fortinet rep do all of the captures and log collections he needs.   

[Kangming]

Could you try the latest V7.0.6 version?

[Kangming]

Is there any further progress that can be updated?