FGT-VM - Firewall policy doesn't function

[spinovski]

Hello team,

I am a Network specialist and worked a lot with FortiGate firewalls, For the first time I wanted to try this FortiGate VM image "FGT-VMv7.4.1.F" on Vmware workstation pro to do a basic LAB, I have configured everything correctly but for some reason the traffic can never go through the FortiGate, it seems that the firewall policy to allow traffic from one port to another doesn't do anything, I am 100 % sure that my config is correct (NAT, allow incoming traffic from Port1 to Port2 as an example, Service "ALL"...etc"

The weird thing is that everything works with it (Interfaces are fine and do respond to Ping, IPSEC "SDWAN" Tunnel are Up and responding) except the firewall policy doesn't do anything.

Is there a specific license for the FGT VM to make the firewall policy work properly ?

Thank you,

[mpapisetty]

Hi @spinovski ,

Did you try running a debug flow trace for the traffic in question? The would tell if the traffic is indeed hitting the policy or not. I would recommend the steps in this KB article and if you can share the logs, we could review them together. 

https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-First-steps-to-troubleshoot-connecti...

[spinovski]

Hello,

Please see my network topology on the picture: 

Traffic from my VPC-1 "192.168.1.2" going across a regular FortiGatev6.4.5, it's able to ping the FGT-VMv7.4.1 Port2 "100.0.0.1" 

VPCS-1> ping 100.0.0.1
84 bytes from 100.0.0.1 icmp_seq=1 ttl=254 time=5.983 ms

However on the other side, Traffic from VPC-2 "10.0.0.2" is unable to reach Port2 Interface of

FortiGate6.4.5 "100.0.0.2"

VPCS-2> ping 100.0.0.2
100.0.0.2 icmp_seq=1 timeout
100.0.0.2 icmp_seq=2 timeout

FortiGate6.4.5 is able to ping the FGT-VM :

FortiGatev6.4.5 #exec ping 100.0.0.1
PING 100.0.0.1 (100.0.0.1): 56 data bytes
64 bytes from 100.0.0.1: icmp_seq=0 ttl=255 time=1.3 ms

I have done a debug flow on both firewalls: 

***** Traffic flow from VPC1 to FGT-VM ******** Works !!!

FortiGatev6.4.5 # id=20085 trace_id=1 func=print_pkt_detail line=5693 msg="vd-root:0 received a packet(proto=1, 192.168.1.2:63018->100.0.0.1:2048) from port1. type=8, code=0, id=63018, seq=1."
id=20085 trace_id=1 func=init_ip_session_common line=5864 msg="allocate a new session-00000006"
id=20085 trace_id=1 func=vf_ip_route_input_common line=2584 msg="find a route: flag=04000000 gw-100.0.0.1 via port2"
id=20085 trace_id=1 func=fw_forward_handler line=796 msg="Allowed by Policy-1: SNAT"
id=20085 trace_id=1 func=__ip_session_run_tuple line=3471 msg="SNAT 192.168.1.2->100.0.0.2:63018"
id=20085 trace_id=1 func=ipd_post_route_handler line=490 msg="out port2 vwl_zone_id 0, state2 0x0, quality 0.
"

*********** Traffic flow from VPC2 to FortiGatev6.4.5 ******** !!! Doesn't work

FGT-VM # id=65308 trace_id=2 func=print_pkt_detail line=5885 msg="vd-root:0 received a packet(proto=1, 10.0.0.2:26667->100.0.0.2:2048) tun_id=0.0.0.0 from port3. type=8, code=0, id=26667, seq=1."
id=65308 trace_id=2 func=init_ip_session_common line=6071 msg="allocate a new session-00000071, tun_id=0.0.0.0"
id=65308 trace_id=2 func=__vf_ip_route_input_rcu line=1999 msg="find a route: flag=00000000 gw-0.0.0.0 via port2"

Thank you,

[Quint021]

Hello @spinovski<,

From review, it seems the route towards 100.0.0.2 may be incomplete. Are you using static/dynamic routing?
It seems that the routing configuration may be incorrect on the VM.

On FGT-VM , can you provide the following commands:
get sys arp
get router info routing-table details 100.0.0.2
diagnose firewall proute list 
get router info routing-table all

Kind Regards,
 

[Quint021]

Hello @spinovski,

Can you also confirm via a debug flow on the Physical Fortigate if you are receiving the ICMP request from VPC2 as well?
Kind Regards,

[HarshChavda]

Hello, 

You can troubleshoot routing issue referring this document: https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-Routing-Issue/ta-p/195727

Document: https://community.fortinet.com/t5/FortiGate/Technical-Tip-Traffic-denied-by-Policy-0/ta-p/194737

[spinovski]

Hello team,

I believe there is no routing issue here, both firewalls are connected to each other "Port2" to Port2 "100.0.0.0/24" 

FGT-VM # get sys arp
Address Age(min) Hardware Addr Interface
10.0.0.2 12 00:50:79:66:68:01 port3
100.0.0.2 13 0c:ea:bf:f1:2b:01 port2   <============= FortiGatev6.4.5 "Port2"

FGT-VM # get router info routing-table details 100.0.0.2

Routing table for VRF=0
Routing entry for 100.0.0.0/24
Known via "connected", distance 0, metric 0, best
* is directly connected, port2

FGT-VM # diagnose firewall proute list
list route policy info(vf=root):

FGT-VM # get router info routing-table all
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
V - BGP VPNv4
* - candidate default

Routing table for VRF=0
C 10.0.0.0/24 is directly connected, port3
C 100.0.0.0/24 is directly connected, port2

I am able to ping the FortiGatev6.4.5 (100.0.0.2) from FGT-VM Port 2 "100.0.0.1"

FGT-VM # exec ping 100.0.0.2
PING 100.0.0.2 (100.0.0.2): 56 data bytes
64 bytes from 100.0.0.2: icmp_seq=0 ttl=255 time=3.7 ms
64 bytes from 100.0.0.2: icmp_seq=1 ttl=255 time=1.4 ms

The weird thing is the internal VPC-2 is able to reach the outside Port2 of FGT-VM "100.0.0.1" but for whatever the reason the FGT-VM refuse to forward the traffic to "100.0.0.2" 

VPCS-2> ping 100.0.0.1
84 bytes from 100.0.0.1 icmp_seq=1 ttl=255 time=0.000 ms
84 bytes from 100.0.0.1 icmp_seq=2 ttl=255 time=0.998 ms

VPCS-2> ping 100.0.0.2
100.0.0.2 icmp_seq=1 timeout

This is a debug flow difference on FGT-VM when pinging "100.0.0.1" versus "100.0.0.2" 

Ping from VPC-2 to "100.0.0.2" ========> Doesn't work !!!!

FGT-VM # 2024-07-05 14:56:34 id=65308 trace_id=4 func=print_pkt_detail line=5885 msg="vd-root:0 received a packet(proto=1, 10.0.0.2:4972->100.0.0.2:2048) tun_id=0.0.0.0 from port3. type=8, code=0, id=4972, seq=1."
2024-07-05 14:56:34 id=65308 trace_id=4 func=init_ip_session_common line=6071 msg="allocate a new session-000001c9, tun_id=0.0.0.0"
2024-07-05 14:56:34 id=65308 trace_id=4 func=__vf_ip_route_input_rcu line=1999 msg="find a route: flag=00000000 gw-0.0.0.0 via port2"

Also there is no traffic session created :

FGT-VM # diagnose sys session list
total session: 0

Ping from VPC-2 to "100.0.0.1" ========> it work !!!!

FGT-VM # 2024-07-05 14:57:01 id=65308 trace_id=5 func=print_pkt_detail line=5885 msg="vd-root:0 received a packet(pro to=1, 10.0.0.2:11628->100.0.0.1:2048) tun_id=0.0.0.0 from port3. type=8, code=0, id=11628, seq=1."
2024-07-05 14:57:01 id=65308 trace_id=5 func=init_ip_session_common line=6071 msg="allocate a new session-000001ce, tun_id=0. 0.0.0"
2024-07-05 14:57:01 id=65308 trace_id=5 func=__vf_ip_route_input_rcu line=1999 msg="find a route: flag=80000000 gw-0.0.0.0 vi a root"
2024-07-05 14:57:01 id=65308 trace_id=5 func=__iprope_tree_check line=535 msg="gnum-100004, use addr/intf hash, len=2"
2024-07-05 14:57:01 id=65308 trace_id=5 func=get_new_addr line=1264 msg="find SNAT: IP-100.0.0.1(from IPPOOL), port-11628"
2024-07-05 14:57:01 id=65308 trace_id=5 func=ip_session_confirm_final line=3112 msg="npu_state=0x0, hook=1"

Traffic session created 

FGT-VM # diagnose sys session list

session info: proto=1 proto_state=00 duration=1 expire=59 timeout=0 refresh_dir=both flags=00000000 socktype=0 sockport=0 av_idx=0 use=3
origin-shaper=
reply-shaper=
per_ip_shaper=
class_id=0 ha_id=0 policy_dir=0 tunnel=/ vlan_cos=0/0
state=local may_dirty
statistic(bytes/packets/allow_err): org=84/1/1 reply=84/1/1 tuples=2
tx speed(Bps/kbps): 0/0 rx speed(Bps/kbps): 0/0
orgin->sink: org pre->in, reply out->post dev=5->14/14->5 gwy=0.0.0.0/0.0.0.0
hook=pre dir=org act=noop 10.0.0.2:50284->100.0.0.1:8(0.0.0.0:0)
hook=post dir=reply act=noop 100.0.0.1:50284->10.0.0.2:0(0.0.0.0:0)
misc=0 policy_id=1 pol_uuid_idx=0 auth_info=0 chk_client_info=0 vd=0
serial=000001e1 tos=ff/ff app_list=0 app=0 url_cat=0
rpdb_link_id=00000000 ngfwid=n/a
npu_state=00000000
no_ofld_reason: local
total session: 1

I suspect the issue is related to NAT,  when traffic from inside to outside the FGT-VM firewall policy is allowing the traffic but doesn't do any NAT for some reason, then means no traffic session created

This type of NAT is SNAT applied by the firewall policy itself: 

FGT-VM # sh firewall policy
config firewall policy
edit 1
set uuid 9a558514-c467-51ee-e1b5-a5c97a9b6046
set srcintf "port3"
set dstintf "port2"
set action accept
set srcaddr "all"
set dstaddr "all"
set schedule "always"
set service "ALL"
set logtraffic all
set nat enable  <=====================
next
end

I will probably try to configure another type of NAT like Central SNAT and see the difference. 

[mpapisetty]

From the debugs, I see that the route lookup is not working as expected. In this line here for non working debug - 

2024-07-05 14:56:34 id=65308 trace_id=4 func=__vf_ip_route_input_rcu line=1999 msg="find a route: flag=00000000 gw-0.0.0.0 via port2"

Finding the route should be directly connected and not with a gateway of 0.0.0.0. Could you also share the kernel routing table to see the entries there? 

get router info kernel

Also, to check the license status, you could run "get system status" for a quick review. 

[spinovski]

Hello team,

I have also tried to activate "Central SNAT" on my FGT-VMv7.4.1, unfortunately it doesn't do any NAT and doesn't create traffic session from Inside to Outside.

I tried another image FGT-VMv7.2.6 on my Vmware Workstation and I got the same issue 

None of normal FortiGate images (6.4.5 & 6.4.7...etc) have this issue except these VM images.

Is there a specific license for VM images to be able to work with NAT ? Does any of Fortinet experts have an opinion on this ?

Your help is very appreciated 

Thank you,

[rvillaroman]

Hi @spinovski,

Are you using VIP or IP pool on your setup? There is a changes on behavior per firmware branch, kindly check this article for information. https://community.fortinet.com/t5/FortiGate/Technical-Tip-IP-pool-and-virtual-IP-behavior-changes-in...