Forwarding stops working

[Dagwyn]

Hello. I have a Fortigate 110C in HA configuration. the problem I am having is that it has started to stop forwarding traffic to an internal server. It has worked fine for many moths and suddenly started to give me problems. I upgraded the firmware to v5.0,build0252 (GA Patch 5) in case but it still behave the same. When I reboot it immediatly starts to work again when the other unit takes over and after that i works for up to two days before failing again. Anyone got any hint in what is going on? The setup is as below. I have configured a virtual ip listening to port 443 on ip #.#.#.141. Then a policy to allow the traffic.

 config system zone
     edit " UntrustZONE" 
             set interface " wan1"              
         set intrazone allow
     next
     edit " TrustZONE" 
             set interface " port1"              
         set intrazone allow
     next
 end
 
 config firewall vip
     edit " FPTimeExt" 
         set extip #.#.#.141
         set extintf " wan1" 
         set portforward enable
         set color 25
         set mappedip 172.29.1.11
         set extport 443
         set mappedport 443
     next
 end
 
 config firewall policy
     edit 20
         set srcintf " UntrustZONE" 
         set dstintf " TrustZONE" 
             set srcaddr " all"              
             set dstaddr " FPTimeExt"              
         set action accept
         set schedule " always" 
             set service " ANY"              
         set logtraffic enable
     next
 end
 

[emnoc]

Do you really need a zone for this? I would rid the zone members and apply the policies directly and see what happens. Have you done any diagnostics; flow, sniffer,etc...... Are you sure no other policies where moved, dropped or changed due to the upgrade. and imho a zone with just one member, is adding more complexity to a fwpolicies & offers no advantage.

[ede_pfau]

@emnoc:

and imho a zone with just one member, is adding more complexity to a fwpolicies & offers no advantage

There is an advantage: by using a zone you can completely rename a port. I cannot see how that would add complexity though, just on the contrary. The OP is probably using zones in transition from a Netscreen/JunOS firewall configuration. @Dagwyn: I remember having read about a recent quirk when using ports in firewall policies which where also members of a zone. I think 5.0.6 fixed that, have a look at the Release Notes. But READ them before upgrading, definitely! Not using zones might be a good idea after all, only for different reasons.

[romanr]

I haven' t found it in the actual release notes, but there was one issue regarding Zones in v5, but that shouldn' t apply here... Policies that used interfaces directly, which were also used in zones would get delete upon upgrade (I think to 5.0.4) - I think this kind of policy was dropped with this release! I would also recommend to sniff and do a flow debug to see why this traffic isn' t processed! Regarding the Zone Topic: It is often very very usefull to start an installation from scratch with using Zones as good as you can! If you might make bigger changes in the network topology this can save days and weeks of work: - Easily add an additional internal vlan, SSID, Remote APs whatever via just some clicks... - Add an additional ISP uplink or migrate uplink connectivity - ... br, Roman

[Dagwyn]

This setup was configured by our supplier when installed. I have on a few occasions started with a fresh config when doing firmware upgrade but have kept the zones, they are not really needed as some has mentioned. I have tried logging the traffic but when it is not working it does not generate ANYTHING.

 # diagnose debug enable
 # diagnose debug flow filter addr
 # diagnose debug flow show console enable
 # diagnose debug flow show function-name enable
 # diagnose debug flow trace start 100
 
 id=13 trace_id=1 func=resolve_ip_tuple_fast line=4299 msg=" vd-root received a packet(proto=6, #.#.86.157:38504->#.#.#.141:443) from wan1." 
 id=13 trace_id=1 func=init_ip_session_common line=4430 msg=" allocate a new session-00015605" 
 id=13 trace_id=1 func=get_new_addr line=2401 msg=" find SNAT: IP-172.29.1.11(from IPPOOL), port-443" 
 id=13 trace_id=1 func=fw_pre_route_handler line=175 msg=" VIP-172.29.1.11:443, outdev-wan1" 
 id=13 trace_id=1 func=__ip_session_run_tuple line=2522 msg=" DNAT #.#.#.141:443->172.29.1.11:443" 
 id=13 trace_id=1 func=vf_ip4_route_input line=1603 msg=" find a route: gw-172.29.1.11 via port1" 
 id=13 trace_id=1 func=__iprope_tree_check line=534 msg=" use addr/intf hash, len=4" 
 id=13 trace_id=1 func=fw_forward_handler line=663 msg=" Allowed by Policy-20:" 
 
 etc.
 

Just realised that it seems as it' s always the same unit that behave like this. When I reboot it switches to the slave and it works for a while. Both units have the same priority.

[romanr]

Is it possible, that there is another device on the outside, that might hook onto that .141 ip address and poisons the ARP table of the outside router?