Hot!Fortigate zone based firewall

Author
Behzadawesome
New Member
  • Total Posts : 10
  • Scores: 2
  • Reward points: 0
  • Joined: 2019/06/09 22:44:57
  • Status: offline
2020/06/30 07:10:43 (permalink)
5 (1)

Fortigate zone based firewall

Hi all,
I am trying to test the firewalling feature of Fortigate.
My question/problem is as follows:
I have 3 zones named, INSIDE, OUTSIDE_A, OUTSIDE_B and they have different interface assigned to them.
I was trying to simulate the asymmetic routing which I would expect to be denied by most firewall by default. However, when I have tried to "send the traffic" from INSIDE to the OUTSIDE_A, and the return packet from OUTSIDE_B to INSIDE, the traffic is allowed.
I have only one permit policy which allows all traffic from INSIDE zone to be go out to the OUTSIDE_A zone and there is NO other policy defined in the policies.
The testing protocol is ICMP ping.
 
any help would be appreciated as it is a fundamental problem which I have.
 
Regards
 Behzad
#1

16 Replies Related Threads

    emnoc
    Expert Member
    • Total Posts : 5732
    • Scores: 371
    • Reward points: 0
    • Joined: 2008/03/20 13:30:33
    • Location: AUSTIN TX AREA
    • Status: offline
    Re: Fortigate zone based firewall 2020/06/30 07:17:27 (permalink)
    0
    1st  ; Policy does not control traffic. What do you have in your route table and mainly for the source of the datagram that are returned?
     
    Also you might want to run a "diag debug flow" to get a trace on the traffic and see what is shown. You can search here to see examples of how to set the filter and execution for that command.
     
    Ken Felix
     

    PCNSE 
    NSE 
    StrongSwan  
    #2
    Behzadawesome
    New Member
    • Total Posts : 10
    • Scores: 2
    • Reward points: 0
    • Joined: 2019/06/09 22:44:57
    • Status: offline
    Re: Fortigate zone based firewall 2020/06/30 10:29:04 (permalink)
    0
    Hi emnoc
    first off, thanks for your reply.
    what do u mean the Policy does not control the traffic? do you mean that the IPv4 policy under the security section does not control the traffic?\
     
     
    #3
    emnoc
    Expert Member
    • Total Posts : 5732
    • Scores: 371
    • Reward points: 0
    • Joined: 2008/03/20 13:30:33
    • Location: AUSTIN TX AREA
    • Status: offline
    Re: Fortigate zone based firewall 2020/06/30 10:33:03 (permalink)
    0
    Let me correct that. "it does not control routing the traffic". the routes is looked at 1st to determine what policy to match if any. In your case a "diag debug flow" and it's output would be helpful. The 1st few lines after the start of the trace will have "gw" or "next-hop" in it ( can't which ) and then the matched-policy.
     
    Can you share that ? Sanitize if you have sensitive ip_address
     
    Ken Felix

    PCNSE 
    NSE 
    StrongSwan  
    #4
    ede_pfau
    Expert Member
    • Total Posts : 6340
    • Scores: 533
    • Reward points: 0
    • Joined: 2004/03/09 01:20:18
    • Location: Heidelberg, Germany
    • Status: offline
    Re: Fortigate zone based firewall 2020/07/01 02:04:59 (permalink)
    0
    I can assure you, asymmetric routing is always causing denied traffic (except for if you explicitely allow it).
    Please post your routing table (CLI: get route info rou all). At the moment we can only speculate how you set up your FGT.

    Ede

    " Kernel panic: Aiee, killing interrupt handler!"
    #5
    live89
    Silver Member
    • Total Posts : 72
    • Scores: 0
    • Reward points: 0
    • Joined: 2016/05/11 07:20:42
    • Status: offline
    Re: Fortigate zone based firewall 2020/07/01 05:32:31 (permalink)
    0
    Check this configuration from CLI:
     
    FW1 # config system settings
    FW1 (settings) # get | grep asym
    asymroute           : disable
    asymroute-icmp      : disable
    asymroute6          : disable
    asymroute6-icmp     : disable
     
    They should be disabled

    Thanks
    #6
    emnoc
    Expert Member
    • Total Posts : 5732
    • Scores: 371
    • Reward points: 0
    • Joined: 2008/03/20 13:30:33
    • Location: AUSTIN TX AREA
    • Status: offline
    Re: Fortigate zone based firewall 2020/07/01 08:34:47 (permalink)
    0
    if you use the "diag debug flow" the iprope will show you the route lookedup
     
    e.g  ( focus on the lines that contains )
     
       msg="find a route:
     
     
    That flow should arrive back on the same interface. If you do not have asymmetrical enable you could doa diag sniffer packet any "host x.x.x.x and port abcd" 4  and that will show you ingress/egress interfaces. 
     
    Just remember the function_iprope comes before the policy lookup and match|deny
     
    This might help to analyze your issues
     
    Ken Felix

    PCNSE 
    NSE 
    StrongSwan  
    #7
    sw2090
    Platinum Member
    • Total Posts : 678
    • Scores: 42
    • Reward points: 0
    • Joined: 2017/06/14 01:27:25
    • Location: Regensburg
    • Status: offline
    Re: Fortigate zone based firewall 2020/07/02 07:28:34 (permalink)
    0
    Sounds familiar to mee. 
    If you have a policy that allows subnet a to access subnet b and you ping a host in subnet b from a host in sbunet a then you will get a ping reply even though you don't have a reverse policy.
    I think this is wanted behaviour.  You should be denied if you try to ping a host in subnet a from a host in subnet b for there is no policy that allows that.
     
    #8
    Behzadawesome
    New Member
    • Total Posts : 10
    • Scores: 2
    • Reward points: 0
    • Joined: 2019/06/09 22:44:57
    • Status: offline
    Re: Fortigate zone based firewall 2020/07/03 04:25:48 (permalink)
    0
    Hi all,
    Here is the topology that I have implemented
    here is the topology:
    https://imgur.com/UwtGevB
    Traffic is initiated from PC_A toward PC_B.
    The send traffic is INSIDE TO OUTSIDE_A, then R1 to PC_B.
    The return traffic is PC_B to R2, and then R2 to OUTSIDE_B, and OUTSIDE_B to PC_A
    An IPv4 firewall policy is configured to allow all traffic from INSIDE zone toward OUTSIDE_A is allowed only.
    There are no other rules in the IPv4 firewall policies.
    From Routing point of view, the PC_B IP address is configured on Fortigate to route through the OUTSIDE_A zone.
    I will post the debug output when I have access to the device.
     
    With regards
     Behzad
    #9
    Behzadawesome
    New Member
    • Total Posts : 10
    • Scores: 2
    • Reward points: 0
    • Joined: 2019/06/09 22:44:57
    • Status: offline
    Re: Fortigate zone based firewall 2020/07/03 04:31:26 (permalink)
    0
    yes that is the desired behavior which is the stateful firewall basics. My problem, though is that it allows the traffic.
    #10
    live89
    Silver Member
    • Total Posts : 72
    • Scores: 0
    • Reward points: 0
    • Joined: 2016/05/11 07:20:42
    • Status: offline
    Re: Fortigate zone based firewall 2020/07/03 04:46:31 (permalink)
    0
    Have you checked my answer to you?

    Thanks
    #11
    Behzadawesome
    New Member
    • Total Posts : 10
    • Scores: 2
    • Reward points: 0
    • Joined: 2019/06/09 22:44:57
    • Status: offline
    Re: Fortigate zone based firewall 2020/07/03 04:57:45 (permalink)
    0
    ac89live
    Have you checked my answer to you?

    Hi yes the asymmentic routing is disabled.
     
    #12
    live89
    Silver Member
    • Total Posts : 72
    • Scores: 0
    • Reward points: 0
    • Joined: 2016/05/11 07:20:42
    • Status: offline
    Re: Fortigate zone based firewall 2020/07/03 08:48:34 (permalink)
    0
    ok .. so this got me interested.
    I sat a lab with two fortigates each one has different LAN , (version 6.2.0)
    fortigate-1 is connected to a wan1-router and wan1-router is also connected fortigate-2
    fortigate-1 is also connected to fortigate-2 through wan2 interface
    https://ibb.co/42QfZv1
     
    And I sat the traffic to flow this way , and it worked regardless that asymmetric route is disabled.
    But guess what, I sat on FGT-2 that FGT-1 LAN learned the direct p2p connection and not through the mpls router. ANd when I tried to ping from FGT-1 LAN to FGT-2 LAN and enforced traffic to go through the mpls router , traffic got denied on FGT-2 . See log:
     
    FGT-2 (settings) # id=20085 trace_id=41 func=print_pkt_detail line=5501 msg="vd-root:0 received a packet(proto=1, 10.2.0.1:48896->10.100.77.101:2048) from por
    t5. type=8, code=0, id=48896, seq=0."
    id=20085 trace_id=41 func=init_ip_session_common line=5666 msg="allocate a new session-00011302"
    id=20085 trace_id=41 func=ip_route_input_slow line=2252 msg="reverse path check fail, drop"
    id=20085 trace_id=41 func=ip_session_handle_no_dst line=5750 msg="trace"
    id=20085 trace_id=42 func=print_pkt_detail line=5501 msg="vd-root:0 received a packet(proto=1, 10.2.0.1:48896->10.100.77.101:2048) from port5. type=8, code=0, id=48896,
     seq=1."

     
    After enabling asymmetric route on FGT-2 traffic got Permitted on FGT-2 
     
    FGT-2 (settings) # get | grep asym 
    asymroute : disable
    asymroute-icmp : enable
    asymroute6 : disable
    asymroute6-icmp : disable

     
    And then arrived successfully at FGT-1 without being denied.
     
    FGT-1 # diagnose sniffer packet any 'host 10.100.77.101 and host 10.2.0.1' 4
    interfaces=[any]
    filters=[host 10.100.77.101 and host 10.2.0.1]
    3.770602 mpls out 10.2.0.1 -> 10.100.77.101: icmp: echo request
    3.785696 wan2 in 10.100.77.101 -> 10.2.0.1: icmp: echo reply
    4.770882 mpls out 10.2.0.1 -> 10.100.77.101: icmp: echo request
    4.784904 wan2 in 10.100.77.101 -> 10.2.0.1: icmp: echo reply

     
    (So I guess) this is default behavior to accept outgoing traffic that it returns from different WAN. And default behavior to deny incoming traffic that is coming of different interface other that what is mentined in the routing table (suspecetd spoofed traffic).
     
    Its worth mentioning that this is not the same with SD-WAN while there you have the auxiliary-session command:
    https://docs.fortinet.com/document/fortigate/6.2.3/technical-tip-enabling-auxiliary-session-with-ecmp-or-sd-wan/19/fd47765
     
     

    Thanks
    #13
    Behzadawesome
    New Member
    • Total Posts : 10
    • Scores: 2
    • Reward points: 0
    • Joined: 2019/06/09 22:44:57
    • Status: offline
    Re: Fortigate zone based firewall 2020/07/03 09:13:13 (permalink)
    0
    ac89live
    (So I guess) this is default behavior to accept outgoing traffic that it returns from different WAN. And default behavior to deny incoming traffic that is coming of different interface other that what is mentined in the routing table (suspecetd spoofed traffic).

    So is there anyway to change this behavior to enforce to care about the outgoing zone/interface?
    post edited by Behzadawesome - 2020/07/03 09:20:27
    #14
    behzadb23
    New Member
    • Total Posts : 1
    • Scores: 0
    • Reward points: 0
    • Joined: 2020/07/04 03:09:52
    • Status: offline
    Re: Fortigate zone based firewall 2020/07/04 03:37:42 (permalink)
    0
    ac89live
    Have you checked my answer to you?



    hi, as you can see in the attached file, all of them are disable.

    Attached Image(s)

    #15
    Behzadawesome
    New Member
    • Total Posts : 10
    • Scores: 2
    • Reward points: 0
    • Joined: 2019/06/09 22:44:57
    • Status: offline
    Re: Fortigate zone based firewall 2020/07/05 09:44:33 (permalink)
    0
    any update?
    #16
    lobstercreed
    Gold Member
    • Total Posts : 229
    • Scores: 25
    • Reward points: 0
    • Joined: 2018/11/28 14:57:58
    • Location: Sedalia, MO
    • Status: offline
    Re: Fortigate zone based firewall 2020/07/11 12:27:02 (permalink)
    0
    You need to open a case with Fortinet support to see if this is in fact expected behavior like live89 suggests.  I suspect it is, but they have been known to have a lot of bugs, especially in .0 code that live89 was using.
     
    I don't see the issue with this traffic being allowed though, as the security issue where RPF checks drop packets is when the initiating traffic is coming from the wrong interface (i.e. doesn't match the routing table).  If it comes back from a different interface, who cares?  Assuming these are ISP connections, that means you have an upstream routing problem that won't be resolved by dropping packets.
    #17
    Jump to:
    © 2020 APG vNext Commercial Version 5.5