FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
Raghu_Kumar
Staff
Staff
Description

This articles describes about the client and server communication through FortiGate, confirming no issue with FortiGate in client-server communication.

Scope FortiGate, all firmware.
Solution

In some scenario when client is trying to access any server inbound or outbound via FortiGate and connection fails or keeps on loading.

 

Check policy(rules), NAT & route using debug flow and packet sniffer.

 

Step 1: Debug Flow

 

# diagnose debug disable

# diagnose debug reset   >>>>> for clearing & starting new debug.

 

# diagnose debug console timestamp en

# diagnose debug flow show function-name en

# diagnose debug flow show iprope en

# diagnose debug flow filter addr “x.x.x.x”    >>>>> IP of the server.

# diagnose debug flow filter port "y"   >>>>> Port used while talking to server.

 

# diagnose debug flow trace start 100   >>>>> number of packets.

# diagnose debug enable

 

In this output user can confirm if traffic is hitting the right policy, If SNAT/DNAT is applied correctly and also if the correct route is chosen.

 

Sample debug packet provided below:

 

Client-Server communication between interfaces LAN - DMZ.

 

2022-07-02 09:51:00 id=20085 trace_id=446 func=print_pkt_detail line=5810 msg="vd-root:0 received a packet(proto=6, 10.10.10.31:41952->192.168.0.17:5666) from lan. flag [S], seq 2726244257

, ack 0, win 14600"

2022-07-02 09:51:00 id=20085 trace_id=446 func=init_ip_session_common line=5981 msg="allocate a new session-0219d47d"

2022-07-02 09:51:00 id=20085 trace_id=446 func=iprope_dnat_check line=5121 msg="in-[lan], out-[]"

2022-07-02 09:51:00 id=20085 trace_id=446 func=iprope_dnat_tree_check line=830 msg="len=0"

2022-07-02 09:51:00 id=20085 trace_id=446 func=iprope_dnat_check line=5134 msg="result: skb_flags-02000000, vid-0, ret-no-match, act-accept, flag-00000000"

2022-07-02 09:51:00 id=20085 trace_id=446 func=vf_ip_route_input_common line=2615 msg="find a route: flag=04000000 gw-192.168.0.17 via dmz" >>>>> confirming the correct gateway and outbound interface chosen.

 

2022-07-02 09:51:00 id=20085 trace_id=446 func=fw_forward_handler line=803 msg="Allowed by Policy-91: SNAT" >>>>> confirming if traffic is hitting the right policy.

 

2022-07-02 09:51:00 id=20085 trace_id=446 func=__ip_session_run_tuple line=3508 msg="SNAT 10.10.10.31->192.168.0.8:41952" >>>>> confirming if source NAT is applied on outbound traffic LAN to DMZ.

 

2022-07-02 09:51:00 id=20085 trace_id=446 func=ipd_post_route_handler line=490 msg="out dmz vwl_zone_id 0, state2 0x1, quality 0".

2022-07-02 09:51:00 id=20085 trace_id=446 func=np6xlite_hif_nturbo_build_vtag line=1093 msg="np6xlite_hif_nturbo_build_vtag:

vtag->magic d153beef, vtag->coretag 64, vtag->vid 0

 

vtag->sip[0] 800a8c0, vtag->sip[1] 0, vtag->sip[2] 0, vtag->sip[3] 0

 

 vtag->sport 57507, vtag->mtu 1500, vtag->flags 12,    vtag->np6_index 1, skb->npu_flag=0xc0880"

 

Policy(rules), NAT & Route, all three are in place and works as expected.

 

Step 2: Packet Sniffer

 

# diagnose sniffer packet any ‘host x.x.x.x’ 4 0 1 >>>>> IP of the server.

 

Note:

For DNAT scenarios (VIP) it is better to run sniffer for source IP as the source is not SNAT-ed.

For SNAT scenarios it is better to run sniffer for the destination IP as the destination won't be NAT-ed.

 

# diagnose sniffer packet any 'host 192.168.0.17' 4 0 1
interfaces=[any]
filters=[host 192.168.0.17]
1.228274 dmz out arp who-has 192.168.0.17 tell 192.168.0.8
1.228468 dmz in arp reply 192.168.0.17 is-at 0:50:56:ac:57:b
3.252369 lan in 10.10.10.31.52194 -> 192.168.0.17.5666: syn 3762829392
3.252397 dmz out 192.168.0.8.52194 -> 192.168.0.17.5666: syn 3762829392 >>>>> NATing done.

16.240523 lan in 10.10.10.31.55642 -> 192.168.0.17.21: syn 2666961218
16.240614 dmz out 192.168.0.8.55642 -> 192.168.0.17.21: syn 2666961218

 

Client(10.10.10.31) is able to reach server(192.168.0.17) SYN packet, but no response from server (SYN-ACK).


17.240255 lan in 10.10.10.31.55642 -> 192.168.0.17.21: syn 2666961218
17.240283 dmz out 192.168.0.8.55642 -> 192.168.0.17.21: syn 2666961218
19.244225 lan in 10.10.10.31.55642 -> 192.168.0.17.21: syn 2666961218
19.244262 dmz out 192.168.0.8.55642 -> 192.168.0.17.21: syn 2666961218
23.252329 lan in 10.10.10.31.55642 -> 192.168.0.17.21: syn 2666961218
23.252364 dmz out 192.168.0.8.55642 -> 192.168.0.17.21: syn 2666961218

 

Note:

User should be able to see 3-way handshake SYN, SYN-ACK, ACK packets between client and server.

Here response SYN-ACK from server 192.168.0.17 are missing.

 

Step 3: To confirm and analyze the packets better, make use of packet capture in FortiGate.

 

To capturing packets from GUI:

 

Go to Network - > Packet Capture and create a new filter.

 

After capturing open the pcap files using wireshark which is a packet capture application for pcap files.

 

Here in this case server uses port 5666.

 

Capture both inbound (LAN interface) and outbound (DMZ interface).

Hosts: 10.10.10.31 & 192.168.0.17

Port: 5666

 

LAN Interface:

 

kr_0-1657029289085.png

 

No response SYN-ACK from the server back to client is seen.

Client IP: 10.10.10.31

Client NATed IP: 192.168.0.8

Server IP: 192.168.0.17

 

DMZ Interface:

 

kr_1-1657029309431.png

 

No response for the NATed IP of the client from the server and waiting for SYN-ACK response can be seen.

Client IP: 10.10.10.31

Client NATed IP: 192.168.0.8

Server IP: 192.168.0.17

 

Note:

One can clearly confirm that the issue is with the server not responding the client and also confirmed FortiGate is not blocking any traffic.

 

In such cases in forward logs for such communication 'Active-session close' logs are seen, also the 'session-ttl configured to 0' is seen which means no limit in policy as well as globally.

Contributors