eth0 -> DMZ, public 206.n.n.n
eth1 -> Internal, 10.0.0.n
eth2 -> External, public 75.n.n.n
The box was build with 11.4 and ran fine for many years; it was recently upgraded to 12.3, and continued to run after the upgrade.
Unfortunately, it took a power hit today and now refuses to route traffic! At the box, access to DMZ, Internal, and External is no problem.
ICMP from Internal -> External is acknowledged by the firewall (? - ping with firewall on stops at the box, ping with firewall off times out); no traffic is being passed from Internal to DMZ OR External interfaces, firewall on or off. Interestingly enough, ssh from Internal -> DMZ shows “Connection refused” with the firewall running, but times out with it not running?
Nothing has been logged in /var/log/firewall since the upgrade even with “Log All”, … and “IPV4 forwarding” shows “Unknown” in “Security Overview”.
Has something changed with 12.3 that cause this type of problem? Is “IPv4 Forwarding Unknown” a problem?
Analyzing your box heavily depends on your saying the box was fully functioning for “a long time” after upgrading to 12.3. If it was unstable in any way, then I don’t know if it’d be easy to restore functionality.
Looking at your firewall zones, I notice your DMZ is not the same ip address range(or even close) as your Exterior Zone… Does that mean you were doing some kind of NAT or forwarding from external to your DMZ? If so, then you should document the mappings. Otherwise, I do notice that while your DMZ addresses are not anywhere close to the address range of your External zone, so IMO that’s really weird… using public addresses in your DMZ which might not be routable through the External zone’s addresses.
If I were in your position, I’d probably take another look at your network address ranges and verify you’re doing so properly. The DMZ address range choice will then determine how your DMZ is configured… bridging, forwarding or NAT.
And then, I’d try to configure the SUSE FW from scratch.
Lastly, I wouldn’t ever use PING or TRACE to troubleshoot FW problems… ICMP is likely subject to entirely different rules than IPv4 (or IPv6). Use something like telnet instead.
Thanks for the reply! I had gone through the upgrade, rebooted the machine, and it continued merrily along until the power failure this AM.
Actually, there is a separate T1 handling public traffic for the DMZ; the only reason I assigned DMZ to it was for clarity. The first time I looked at the firewall after the failure it was not tagged at all.
I had thought about that, but in reviewing the underlying config files, making a change in Yast seems to not change the files, so the most important question would how to clear the current config?
OK,. . got it working, but there are some big problems with the Firewall config:
> In trying to fix the problem this AM, I had assigned the 206.n.n.n servers to DMZ; setting that I/F to No Zone and adding a static route fixed that part of the problem (Internal -> 206 network).
I then discovered that outbound traffic on the External I/F had a different problem:
> The 12.3 Firewall on this machine requires an ALLOWED SERVICE for outbound traffic! I had to explicitly add “HTTP Server” to allow port 80 traffic… and then add 443 MANUALLY to allow ssl traffic. As a result, 80/443/8000 <!!> show configured but Closed externally.
This 12.3 upgrade ran for some time and the firewall hosed itself on a power failure/reboot - the 12.3 upgrade included a reboot for the new kernel, why would this reboot cause the firewall configuration to change? Is there a possible mismatch somewhere?
It would really be nice to get the firewall running correctly (allowing outbound traffic without defining an inbound port), so if anyone has at least a thought on that problem it would be greatly appreciated.
Glad to hear you’re making progress.
I haven’t heard that there are significant changes to IP2 but maybe you ran into something
Yes, even in 12.3 I found that some “common” services weren’t defined in SUSE FW and I had to custom define them explicitly but I didn’t think enough them even then to submit a bug feature… I just thought it was a minor inconvenience at the time but dealt with it.