Forwarding stops working

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.

@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.

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

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.

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?