Togan Muftuoglu wrote:

* Robbert Eggermont; on 04 Apr, 2004 wrote:

...

However, when I enable SuSEfirewall2 for this system (using YaST), the firewall (/etc/rc.d/rc5.d/S01SuSEfirewall2_init) blocks ("destination unreachable") all {dns, smb, nfs, nis} traffic until (S14SuSEfirewall2_setup) *after* the {smbfs, nfs, ypbind} services are started...

yes by design. If you look to section 1.3 Techical background, you will see that SuSEfirewall2_init calls close function. I think the idea is until all services are setup close any incoming connection attempts. That is why after setup stage the final stage comes. So SuSEfirewall2 runs actualy 3 times before your actual protection is underway. Note that during the init stage trafic generated by the computer is allowed to pass.

Indeed, but... the return traffic is blocked!?! The services I talk about above are *client* services, so they need to be able to interact with the server(s)... (At least, that's what I'm thinking. :-) So, shouldn't the firewall be (more) completely setup before any network activity occurs (network related services are started)? I don't see any options to partly open up the firewall in the init stage (at least for the {dns, nfs, nis} server responses). Is there a way to do this (or should I do it differently)? Thanks, Robbert Eggermont

Togan Muftuoglu wrote:

* Robbert Eggermont; on 04 Apr, 2004 wrote:

...

Indeed, but... the return traffic is blocked!?! The services I talk about above are *client* services, so they need to be able to interact with the server(s)... (At least, that's what I'm thinking. :-)

So, shouldn't the firewall be (more) completely setup before any network activity occurs (network related services are started)? I don't see any options to partly open up the firewall in the init stage (at least for the {dns, nfs, nis} server responses). Is there a way to do this (or should I do it differently)?

you can change $local_fs to $remote_fs in SuSEFirewall2_setup required for setup action as by default $remote_fs should be $local_fs+nfs and cjamhe $network to $named so dns and networking devices are setup before SuSEfirewall2is called.

Thanks for thinking with me here. :-) The problem is not that SuSEFirewall2_setup is being run too early, the problem is that SuSEFirewall2_setup is being run too *late* (assuming that SuSEFirewall2_setup opens up the firewall enough to allow network interaction for the dns, nfs & nis client services). Details: The way things are "functioning" now is that SuSEFirewall2_init rejects about all inbound traffic except dhcp client traffic, including ansers to the DNS lookups for the nfs/nis server ip addresses. Even if I would specify the ip addresses, all traffic from (the servers to) the nfslock, nfs and nis client services is blocked. SuSEFirewall2_setup is being run *after* these services. If I change $local_fs to $remote_fs in SuSEFirewall2_setup, SuSEFirewall2_setup is moved even further down the line in the bootprocess (which of course does helps nothing). Before trying out every possible combination, I probably need to know the correct order of enabling services... Should/could SuSEFirewall2_setup be run before or after $network? I think SuSEFirewall2_setup requires some data from the dhcp client (such as the machine's ip & nameserver, right?), so then it should run somewhere between S05network and S06syslog (if I were to log to another machine?), or S09portmap (?) or S10nfslock/S10smbfs? And how can I get SuSEFirewall2_setup to run *then*? Thanks again, Robbert