Fortigate zone based firewall

[Behzadawesome]

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

[Behzadawesome]

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

[Behzadawesome]

yes that is the desired behavior which is the stateful firewall basics. My problem, though is that it allows the traffic.

[live89]

Have you checked my answer to you?

[Behzadawesome]

ac89live wrote:
Have you checked my answer to you?

Hi yes the asymmentic routing is disabled.

[live89]

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

[Behzadawesome]

ac89live wrote:

(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?

[behzadb23]

ac89live wrote:
Have you checked my answer to you?

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

[Behzadawesome]

any update?

[lobstercreed]

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.