Tried to send in traces and such the other day, but they were just too big
and got rejected. Here's a description of the problem; should be enough
without the traces.
We run CentOS 5 with an LDAP directory. Shorewall/iptables hung at the last
line in the following listing:
progress_message2 "Creating action chain Drop"
run_iptables -A Drop -p tcp --dport 113 -j reject
progress_message " Rule \"REJECT - - tcp 113 - - \" added."
run_iptables -A Drop -p all -j dropBcast
A trace of the /sbin/iptables process revealed the iptables process doing an
LDAP query; turned out to be searching for a protocols entry (files was
listed first in nsswitch.conf; I didn't get as far as to see which protocol
it was looking for, or if it was doing a getent for the whole table).
CentOS's authconfig script enables ldap for protocols by default in
/etc/nsswitch.conf. Removing the 'ldap' from the mapping in
nsswitch.confstopped this query and everything worked again.
It seems that this command is being executed in a certain part of the
shorewall script where network access is being blocked. We don't really
care, since we don't put the protocols map in our LDAP directory, but I'm
posting this as an FYI, perhaps for the next person.
One more thing I found: if shorewall stops in mid-flight at at this point,
the iptables rules are left in a state where the LDAP server is still
inaccessible. Rerunning shorewall will hang again, even if the
nsswitch.conf protocols ldap mapping is removed; to get shorewall running
again, either the iptables rules must be cleared, or the passwd ldap mapping
must be temporarily removed.
John
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
