As of leap 42.1 x64 update of a few of my machines, I have an odd problem.

Simple setup ipv4 network with a cpe (e.g. router/nat) device already given and
on the lan side there sits the leap 42.1 x64 machine, that has a (fixed) ipv4
address given by this cpe e.g. via dhcp-v4 or via static ipv4 address on the
lan (rfc1918).

this leap machine has multiple ethernet devices, and acts as a nat-router
itself to the secondary network ethernet card.

machines on this internal-lan e.g. get nat-ed via susefirewall2, pretty simple,
basically machines can do anything outbound, ping, http, email whatever.

so as of the leap 42.1 update of my previously normally working opensuse 13.2
x64 machines, the users on this internal-lan behind the opensuse machine,
complain every few weeks that they cant email (pop3/smpt) or do stuff, except
for e.g. squid proxy running on the opensuse machine, so browsing websites and
all still works.

odd stuff is the opensuse machine can still be reached from the first lan and
also via e.g. portforwarding by the provider router/cpe, e.g. the ssh port is
accessible and I can reach the opensuse machine fine from e.g. ipv4 internet
and all.

Whenever I systemctl restart SuSEfirewall2, the whole situation normalises
again and works again for apparently a few weeks again.

The external ipv4 address changes every now and then via the provider
router/cpe, but that is not the problem here, and I think also the dhcp-v4 of
the opensuse machine is not a problem, also the provider cpe/router always
gives the same ipv4 address to the opensuse leap machine.

the leap machines connectivity itself works fine, I can ping from there also
ping the internal-lan and as I wrote before the squid can fetch webpages and
give them to the machines on the internal-lan.

Only everything with NAT and connection tracking and all apparently dies every
few weeks until a restart of Susefirewall2.

These machines worked happily with 13.2 x64 before.

I have installed conntrack tools, can I provide some logging or capture to give
further details?

Right now I have this one location at the moment that died down on the
internal-lan again and is experiencing this exact bug, so if someone replies
quickly I can provide some info within the next maybe 8 hours or so, but after
that I need to (temporarily) fix the situation again via restarting the
SuSEfirewall2 layer.

Thanks.