Bug 309092

Summary: SuSE yast2 firewall configuration lacks some features thus requiring the user to use custom rules.
Product: [openSUSE] openSUSE 10.2 Reporter: Olli Artemjev <grey-olli>
Component: YaST2Assignee: Lukas Ocilka <locilka>
Status: RESOLVED WONTFIX QA Contact: Jiri Srain <jsrain>
Severity: Enhancement    
Priority: P4 - Low CC: grey-olli, lnussel
Version: FinalKeywords: accessibility, Bad_Design, UI
Target Milestone: ---   
Hardware: All   
OS: openSUSE 10.2   
Whiteboard:
Found By: Other Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Olli Artemjev 2007-09-10 00:11:32 UTC
If I disallow connects to higher ports (that is OK in many cases) via FW_ALLOW_INCOMING_HIGHPORTS_*="" setting (just leaving it default as recommended), I have no choice in configuration interface to make incoming exceptions on replies to DNS querries. Well, generally that is usually not needed, but after installing cisco vpn client I've noticed on drops (default policy) of DNS replies injected by vpn client (cisco vpn client, if I uderstood right, somehow modifies kernel w/ its own module, which creates interface & injects packets in some place inside the kernel packets routing. That may make connection tracking misunderstand the flow.). 
Well, the bugs are:

1. There's no DNS client in interface configuration (Though there's DHCP & some other clients).
2. There's no direction (in/out) specification method in advanced settings (so I guess allowing a port allows it on INPUT, but not on OUTPUT) & thus I can't specify that replies to port 53 should be accepted - the port 53 is meant to be on my side & no way to specify that it's on remote via GUI.

And in general hidding direction of the flow from _advanced_ settings is a bad idea.

PS: Yes, all of these can be solved via customising extra rules that are not visible via yast2 firewall configuration interface.
Comment 2 Lukas Ocilka 2007-09-11 09:26:56 UTC
1.) DNS Client in general doesn't make sense. If DNS reply doesn't work, it must be a very rare case. Actually DHCP Client should be removed. Other clients might make sense because they, e.g., listen to the broadcast reply or act as servers 'a bit'.

2.) Output cannot be configured, just Input.

Ludwig, what do you think of that?
Comment 3 Ludwig Nussel 2007-09-11 10:28:13 UTC
You are right. DNS replies should just work as iptables consideres them as ESTABLISHED or RELATED. If that's not the case with some proprietary vpn solution then there is nothing we can do about it. DHCP clients use packet sockets that bypass filtering rules so there is normally no need to open then explicitly.
Comment 4 Olli Artemjev 2007-09-11 12:51:29 UTC
For comment #2:

1. The case descibed in my report is dropping DNS _replies_. So, by adding the "DNS client" I mean adding ACCEPT on packets from port 53.

2. What situation did you mean by "Output cannot be configured, just Input"?

For comment #3:
> "is nothing we can do about it"
wrong, you may allow user to implicitly allow replies from udp 53. That will solve problem w/ "some proprietary vpn solution" w/o requirements to open configs w/ text editor.

> is normally no need to open then explicitly
Well.. "normally" is the key. Are you developing a _useful_ interface or just a stub for kitchen dummies? If the second - just ignore my request. :/
Comment 5 Lukas Ocilka 2007-09-11 13:02:20 UTC
I'm sorry but I seems your configuration is really very rare and it seems that the Custom Rules is the best way to go. YaST Firewall interface should not confuse common users with commonly-unneeded stuff. If YaST UI doesn't fit your needs, you can still edit /etc/sysconfig/SuSEfirewall2 file directly.

1.) Might be also caused by a wrong VPN or wrong router configuration. Such packets should be in state RELATED/ESTABLISHED when they arrive to the client's network interface.

2.) In firewall, you can set some rules for incoming packets, not outgoing (yes, iptables can configure both, but not YaST Firewall). Such definition you need "any packets coming from port 53" might be dangerous and doesn't cover the common way of using YaST Firewall. Custom Rules or editing the configuration manually is the way to go.

_useful_ doesn't need to mean _useful-for-the-majority-of-users_ we can't have all features every single user needs, I'm sorry.