Bugzilla – Bug 811188
yast2-firewall: system unaccessible via interface in internal zone
Last modified: 2013-07-04 07:16:37 UTC
The bug is still present, i have to disable firewall completely to have network printers from my LAN listen on my opensuse. i have tcp and udp blocking exception for port 631,9001, 160:162 , 9100 still nothing helps +++ This bug was initially created as a clone of Bug #498429 +++ User-Agent: Mozilla/5.0 (compatible; Konqueror/4.2; Linux) KHTML/4.2.2 (like Gecko) SUSE I wanted to have my network in an external zone, but allow network printing via cups. So I enabled the cups service in the firewall module of yast, but still no remote printers were listed in the printer module of yast, although several are available in my network. I have to manually add '631' in the field for the external zone in the broadcast section of the firewall module or to modify to receive the printers via cups. Reproducible: Always Actual Results: No remote printers found after enabling the cups service in the firewall module. Expected Results: Remote printers are shown after enabling cups service in the firewall.
You wrote "I enabled the cups service in the firewall module of yast". Please describe in more detail how exactly you did it. I wonder how you did this because since a longer time (since openSUSE 11.3) the cups RPM package does no longer provide /etc/sysconfig/SuSEfirewall2.d/services/cups so that there is no longer a predefined service "cups" available in the YaST firewall module. On my openSUSE 12.3 system, there is no file /etc/sysconfig/SuSEfirewall2.d/services/cups In other words: Since a longer time we do no longer support to remove firewall protection from CUPS easily. Reason: In almost all cases (when the external zone is accessible from a non-trusted network, in particular from the Internet) it is plain wrong to remove firewall protection from CUPS in the external zone. For background information see https://en.opensuse.org/SDB:CUPS_and_SANE_Firewall_settings In exceptional cases if you really need CUPS to be accessible from the external zone (when your particular external zone is only accessible from trusted networks), you must do the firewall settings that are appropriate in your particular case manually.
I didn't write it - i just reopened a bug reported by someone else. Now the 12.3 still suffers from this bug. I tried to fix it by opening the ports I mentioned above. You say it's not recomended to remove firewall protection from CUPS in external zone. I agree - but why do I have to do this just to list the printers shared in my network or why should i disable firewall at all - this is even more risky. I don't want to share the printer connected to my comp to the network. I only want to use printer shared by others. If i want to browse WWW i don't have to open port 80 in my firewall - so why should i behave like this with printers?
See https://en.opensuse.org/SDB:CUPS_and_SANE_Firewall_settings
Thanks for the hint - i read the article What it recommends is to declare my eth0 network interface as internal zone - I have it like that but still cups doesn't show any shared printers from this network unless i disable firewall at all.
Having the interface for the trusted network in the internal zone worked all the time for me and it still works for me under openSUSE 12.3 but only if I set up SuSEfirewall2 manually and not with the YaST firewall module. When I run the YaST firewall module and therein I only set my interface "eth0" (the only existing interface except "lo") to be in the internal zone (I leave all other settings as defaults) and let the YaST firewall module start SuSEfirewall2, then I can no longer access this machine in any way via network (my ssh session on a remote host hangs and it even does no longer respond to a "ping"). In particular CUPS browsing information from remote CUPS servers cannot come in. In contrast when I start SuSEfirewall2 manually as root using # /sbin/SuSEfirewall2 start it works as it did all the time in the past. In particular I get CUPS browsing information from remote CUPS servers via "eth0" with this interface in the internal zone. Therefore the issue is likely a bug in the YaST firewall module or perhaps in a lower level YaST functionality that is reladed to starting and stopping services, compare bnc#800492 My openSUSE 12.3 system it up to date: ----------------------------------------------------------------------------- # zypper -v update Verbosity: 1 Initialising Target Checking whether to refresh metadata for openSUSE-12.3-Non-Oss Checking whether to refresh metadata for openSUSE-12.3-Oss Checking whether to refresh metadata for openSUSE-12.3-Update Checking whether to refresh metadata for openSUSE-12.3-Update-Non-Oss Loading repository data... Reading installed packages... Force resolution: No Nothing to do. ----------------------------------------------------------------------------- I re-assign it to the maintainer of the YaST firewall module for further analysis what exactly goes wrong in YaST here.
Created attachment 537671 [details] Here are my firewall settings for cups set by YaST Firewall
Unfortunately I'm not a cups maintainer. Firewall does nothing special to cups. It allows opening ports, services, setting up broadcast, etc. But it has no built-in support for cups. If anybody, the cups maintainer has to tell which ports have to be open an in which way. Additionally SuSEfirewall2 maintainer could tell you how to do what's needed.
Lukas, please read my comment#1 regarding predefined CUPS firewall settings and my comment#5 regarding what the actual issue is as far as I reproduced it and note what the bug's subject reads.
Regarding attachment#537671 [details] Do not do such settings! Read https://en.opensuse.org/SDB:CUPS_and_SANE_Firewall_settings
Hello, I have a samsung clx3305w printer/scanner system and I want to scan an image via wlan(WPA2). with firewall on scanimage -L No scanners were identified. If you were expecting something different, check that the scanner is plugged in, turned on and detected by the sane-find-scanner tool (if appropriate). Please read the documentation which came with this software (README, FAQ, manpages). cannot find any scanner. I have to set firewall down to find the scanner scanimage -L device `smfp:SAMSUNG CLX-3300 Series on 192.168.178.38' is a SAMSUNG CLX-3300 Series on 192.168.178.38 Scanner How to set a firewall(iptables) rule for scanner that works under firewall and wlan? Any hints? Cheers grepi
Although I'm a maintained of YaST Firewall (UI frontend for SuSEfirewall2), I have to admit, I don't know what you have to change in SuSEfirewall2. Maybe Ludwig could tell us more.
This bug mixes way too many things. - The bug is about the reporter having trouble setting up cups to be open in the external zone. Yes, that setup is complicated. Cups browsing technically requires an open port. Browsing the web is something entirely differnt than cups listening on a open port to get incoming broadcasts so you can "browse" printers. As Johannes already said, in networks where you want to discover printers you have to set the zone to internal (use e.g. fwzs to switch temporarily). - regarding comment #5. This should be fixed (bug 807507). In fact I cannot reproduce. YaST2 firewall does the zone assignment, enabling and starting correctly for me. If there's still something fishy we need a separate report and logs I guess. - regarding comment #10. This doesn't belong here. Different topic. Same answer as for cups though, use the internal zone. So in my opinion this bug can be closed as WONTFIX.
As I wrote in comment#8 my comment#5 describes what the actual issue is as far as I reproduced it at that time. According to https://bugzilla.novell.com/show_bug.cgi?id=804894#c8 (bnc#804894 is a duplicate of bnc#807507) it seems the patch provided in bnc#807507 fixes it. I assume Ludwig Nussel can no longer reproduce it because he has the patch provided in bnc#807507 I don't think it is correct to close this bug as WONTFIX, see https://bugzilla.novell.com/page.cgi?id=fields.html#status "WONTFIX The problem described is a bug which will never be fixed." Instead I think it is a duplicate of bnc#804894 and bnc#807507. *** This bug has been marked as a duplicate of bug 804894 ***