Hot!7.0.X possible IPS bug with VWP and RADIUS

Author
aguerriero
New Member
  • Total Posts : 15
  • Scores: 0
  • Reward points: 0
  • Joined: 2019/11/01 10:49:06
  • Status: offline
2021/09/10 08:01:23 (permalink)
0

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. 
#1

16 Replies Related Threads

    Kangming_FTNT
    Silver Member
    • Total Posts : 63
    • Scores: 2
    • Reward points: 0
    • Joined: 2018/09/17 18:55:22
    • Status: online
    Re: 7.0.X possible IPS bug with VWP and RADIUS 2021/09/10 11:06:46 (permalink)
    0
    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
    #2
    aguerriero
    New Member
    • Total Posts : 15
    • Scores: 0
    • Reward points: 0
    • Joined: 2019/11/01 10:49:06
    • Status: offline
    Re: 7.0.X possible IPS bug with VWP and RADIUS 2021/09/10 11:18:43 (permalink)
    0
    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
    #3
    Kangming_FTNT
    Silver Member
    • Total Posts : 63
    • Scores: 2
    • Reward points: 0
    • Joined: 2018/09/17 18:55:22
    • Status: online
    Re: 7.0.X possible IPS bug with VWP and RADIUS 2021/09/10 11:43:39 (permalink)
    0
    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
    #4
    aguerriero
    New Member
    • Total Posts : 15
    • Scores: 0
    • Reward points: 0
    • Joined: 2019/11/01 10:49:06
    • Status: offline
    Re: 7.0.X possible IPS bug with VWP and RADIUS 2021/09/10 11:47:22 (permalink)
    0
    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. 
    #5
    Kangming_FTNT
    Silver Member
    • Total Posts : 63
    • Scores: 2
    • Reward points: 0
    • Joined: 2018/09/17 18:55:22
    • Status: online
    Re: 7.0.X possible IPS bug with VWP and RADIUS 2021/09/10 11:55:20 (permalink)
    0
    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
    #6
    Kangming_FTNT
    Silver Member
    • Total Posts : 63
    • Scores: 2
    • Reward points: 0
    • Joined: 2018/09/17 18:55:22
    • Status: online
    Re: 7.0.X possible IPS bug with VWP and RADIUS 2021/09/10 12:00:13 (permalink)
    0
     
    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
    #7
    Kangming_FTNT
    Silver Member
    • Total Posts : 63
    • Scores: 2
    • Reward points: 0
    • Joined: 2018/09/17 18:55:22
    • Status: online
    Re: 7.0.X possible IPS bug with VWP and RADIUS 2021/09/10 14:20:32 (permalink)
    0
    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
    #8
    aguerriero
    New Member
    • Total Posts : 15
    • Scores: 0
    • Reward points: 0
    • Joined: 2019/11/01 10:49:06
    • Status: offline
    Re: 7.0.X possible IPS bug with VWP and RADIUS 2021/09/20 13:11:37 (permalink)
    0
    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]
     
    post edited by aguerriero - 2021/09/20 13:16:23
    #9
    Kangming_FTNT
    Silver Member
    • Total Posts : 63
    • Scores: 2
    • Reward points: 0
    • Joined: 2018/09/17 18:55:22
    • Status: online
    Re: 7.0.X possible IPS bug with VWP and RADIUS 2021/09/21 09:50:01 (permalink)
    0
    Does it mean that IPS may have discarded Radius 1813 packets?

    Thanks
    Kangming
    #10
    aguerriero
    New Member
    • Total Posts : 15
    • Scores: 0
    • Reward points: 0
    • Joined: 2019/11/01 10:49:06
    • Status: offline
    Re: 7.0.X possible IPS bug with VWP and RADIUS 2021/09/21 09:54:11 (permalink)
    0
    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
    #11
    Kangming_FTNT
    Silver Member
    • Total Posts : 63
    • Scores: 2
    • Reward points: 0
    • Joined: 2018/09/17 18:55:22
    • Status: online
    Re: 7.0.X possible IPS bug with VWP and RADIUS 2021/09/21 15:16:23 (permalink)
    0
    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

    Thanks
    Kangming
    #12
    Kangming_FTNT
    Silver Member
    • Total Posts : 63
    • Scores: 2
    • Reward points: 0
    • Joined: 2018/09/17 18:55:22
    • Status: online
    Re: 7.0.X possible IPS bug with VWP and RADIUS 2021/09/27 10:29:26 (permalink)
    0
    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.
     
     
     
     

    Thanks
    Kangming
    #13
    aguerriero
    New Member
    • Total Posts : 15
    • Scores: 0
    • Reward points: 0
    • Joined: 2019/11/01 10:49:06
    • Status: offline
    Re: 7.0.X possible IPS bug with VWP and RADIUS 2021/09/28 05:27:17 (permalink)
    0
    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
    #14
    Kangming_FTNT
    Silver Member
    • Total Posts : 63
    • Scores: 2
    • Reward points: 0
    • Joined: 2018/09/17 18:55:22
    • Status: online
    Re: 7.0.X possible IPS bug with VWP and RADIUS 2021/09/28 10:37:32 (permalink)
    0
    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?

    Thanks
    Kangming
    #15
    Kangming_FTNT
    Silver Member
    • Total Posts : 63
    • Scores: 2
    • Reward points: 0
    • Joined: 2018/09/17 18:55:22
    • Status: online
    Re: 7.0.X possible IPS bug with VWP and RADIUS 2021/09/28 10:49:19 (permalink)
    0
    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.

    Thanks
    Kangming
    #16
    aguerriero
    New Member
    • Total Posts : 15
    • Scores: 0
    • Reward points: 0
    • Joined: 2019/11/01 10:49:06
    • Status: offline
    Re: 7.0.X possible IPS bug with VWP and RADIUS 2021/09/28 11:49:49 (permalink)
    0
    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.   
    #17
    Jump to:
    © 2021 APG vNext Commercial Version 5.5