Problem with fortigate 30E and network printer

[NeoTrafy]

Hi all, 

Hope this is posted where it's supposed, I'm new in the forum and not so sure how it works.

Recently we changed our previous VPN structure (some old cisco devices) with FortiGate 30E and all was working perfectly till some printers stopped working. 

The main server (windows 2012) can't ping the IP of the printers in few offices (we have the HQ in the subnet 1 and the offices are 2-5). 

The other computers can ping correctly but they doesn't have those printers installed. The clients use RDP to access server and print from there.

It's like if when the tunnel goes off and on again when traffic starts again, the printer IP get stuck. If I go physically and change the IP of the printer to a number available (192.168.2.11 to 192.168.2.12) and install the printer it works again, but I cannot be doing this too often.

Any idea what is happening here?

Thank you in advance, 

Neo.

[Toshi_Esumi]

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.

[Toshi_Esumi]

A typo:

# diag sys session clear

[NeoTrafy]

Sorry for not answering (I rebooted everything during launch time that day and until this happened again had no info to give). 

That command shows 2 session because we have 2 windows server

session info: proto=17 proto_state=00 duration=102388 expire=172 timeout=0 flags=00000000 sockflag=00000000 sockport=0 av_idx=0 use=3 origin-shaper= reply-shaper= per_ip_shaper= ha_id=0 policy_dir=0 tunnel=/ vlan_cos=0/255 state=may_dirty statistic(bytes/packets/allow_err): org=542826/5121/1 reply=0/0/0 tuples=2 tx speed(Bps/kbps): 5/0 rx speed(Bps/kbps): 0/0 orgin->sink: org pre->post, reply pre->post dev=15->4/4->15 gwy=192.168.0.1/0.0.0.0 hook=post dir=org act=snat 192.168.1.SV2:1035->192.168.5.31:161(192.168.0.2:61451) hook=pre dir=reply act=dnat 192.168.5.31:161->192.168.0.2:61451(192.168.1.SV2:1035) misc=0 policy_id=1 auth_info=0 chk_client_info=0 vd=0 serial=0000bca3 tos=ff/ff app_list=0 app=0 url_cat=0 dd_type=0 dd_mode=0 session info: proto=17 proto_state=00 duration=102074 expire=175 timeout=0 flags=00000000 sockflag=00000000 sockport=0 av_idx=0 use=3 origin-shaper= reply-shaper= per_ip_shaper= ha_id=0 policy_dir=0 tunnel=/ vlan_cos=0/255 state=may_dirty statistic(bytes/packets/allow_err): org=1054984/9683/1 reply=0/0/0 tuples=2 tx speed(Bps/kbps): 10/0 rx speed(Bps/kbps): 0/0 orgin->sink: org pre->post, reply pre->post dev=15->4/4->15 gwy=192.168.0.1/0.0.0.0 hook=post dir=org act=snat 192.168.1.SV1:53096->192.168.5.31:161(192.168.0.2:53096) hook=pre dir=reply act=dnat 192.168.5.31:161->192.168.0.2:53096(192.168.1.SV1:53096) misc=0 policy_id=1 auth_info=0 chk_client_info=0 vd=0 serial=0000bcec tos=ff/ff app_list=0 app=0 url_cat=0 dd_type=0 dd_mode=0 total session 2

In the case of the others 2 printers offline now, there are 138 and 131 sessions each.

As you said, clearing the session was enough to temporary fix this but I'd need some help to apply the permanent solution. 

Thanks again, 

Neo.

[Toshi_Esumi]

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.

[Gabrielhm]

The printer program is likely to use a discovery protocol of the broadcast type that will not be forwarded through VLANs. In the policies that are a CLI option only, you can allow broadcast-forward. But in the first place, this will defeat the intent of making VLANs. Your best bet is to find out why the [link=https://printerhow.com]printer how[/link]-outs are "ugly" when configured using IP.