Problem with fortigate 30E and network printer

Probably print sessions got stuck but let me verify the topology first. You have Fortigate30Es at HQ and remote locations and they're connected over VPNs (IPSec). Those printers are installed at each remote location but print servers are installed at the RDP terminal server (or maybe at another device at HQ) to do print jobs.

If this is correct then the problem happens only after the VPN connected to the location where the printer is and it comes back up, the print sessions are re-directed toward the next available route, likely the default route, then dies there because the printer's IP is in the private range.

It's not so often, you can clear the stuck session when VPN came back up manually to let a fresh session start. But a permanent solution is to block the private range (remote location subnets) from going toward the default route with a policy.

But first check the stacked session at HQ's FG. You can do like below while it's happening:

# diag sys session filter dst <PRINTER_IP>

# diag sys session list

Then you would get like below. This example is my ping session toward 8.8.8.8.

session info: proto=1 proto_state=00 duration=3 expire=59 timeout=0 flags=00000000 sockflag=00000000 sockport=0 av_idx=0 use=4 origin-shaper= reply-shaper= per_ip_shaper= ha_id=0 policy_dir=0 tunnel=/ vlan_cos=0/255 state=log may_dirty none statistic(bytes/packets/allow_err): org=240/4/1 reply=240/4/1 tuples=2 tx speed(Bps/kbps): 66/0 rx speed(Bps/kbps): 66/0 orgin->sink: org pre->post, reply pre->post dev=8->26/26->8 gwy=[INET_GW]/[MY_PC_IP] hook=post dir=org act=snat [MY_PC_IP]:1->8.8.8.8:8([FG'S_OUTSIDE_IP]:62464) hook=pre dir=reply act=dnat 8.8.8.8:62464->[FG'S_OUTSIDE_IP]:0([MY_PC_IP]:1) misc=0 policy_id=2 auth_info=0 chk_client_info=0 vd=0 serial=02fa733b tos=ff/ff app_list=0 app=0 url_cat=0 dd_type=0 dd_mode=0 npu_state=0x020001 no_offload no_ofld_reason:  disabled-by-policy sflow total session 1

You can determine which direction it's going based on the "gyw=". Then it's not the VPN, you can clear it by:

# diag session clear

Then it should start working again if VPN is up at that time. But it would be a temp fix. You need a policy to block it from happening.

As you saw, it's following the default route (0.0.0.0) and the NAT/toward-the-Internet policy from an interface/zone the servers are coming from to an interface/zone to go out to the internet. You just need to add a new policy specifying the same sets of the interfaces/zones, but adding destination subnets, like 192.168.0.0/16, as destination addresses, then set the action to deny. Then don't forget to move it above the existing policy to be effective. So when the VPNs are down, those printing packets would never go toward the internet. And the sessions.