Re: 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 126.96.36.199.
session info: proto=1 proto_state=00 duration=3 expire=59 timeout=0 flags=00000000 sockflag=00000000 sockport=0 av_idx=0 use=4
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->188.8.131.52:8([FG'S_OUTSIDE_IP]:62464)
hook=pre dir=reply act=dnat 184.108.40.206: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
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.