I recently installed shorewall on a bunch of systems and on one of them it won''t start. The machine in question is a Coraid file server, and I suspect that the kernel is missing something that shorewall wants. I already had to set TC_ENABLED=no to get even this far. The problem machine is essentially a Debian system, with a custom kernel from Coraid: % uname -a Linux makki 2.6.16.35-c1 #2 SMP Thu Dec 7 11:29:35 EST 2006 x86_64 GNU/Linux % shorewall debug start 2>/tmp/trace ended with + ''['' 1 -ne 0 '']'' + error_message ''ERROR: Command "/sbin/iptables -A'' FORWARD -m state --state ESTABLISHED,RELATED -j ''ACCEPT" Failed'' + echo '' ERROR: Command "/sbin/iptables -A'' FORWARD -m state --state ESTABLISHED,RELATED -j ''ACCEPT" Failed'' ERROR: Command "/sbin/iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT" Failed + stop_firewall + case $COMMAND in + set +x iptables: No chain/target/match by that name iptables: No chain/target/match by that name and sure enough: shorewall stop shorewall clear iptables --list Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination /sbin/iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT iptables: No chain/target/match by that name Whereas on all other systems the /sbin/iptables command worked at the same point. I already tried setting IP_FORWARDING=Off on the problem system (it does not need forwarding) and the same problem was seen. Here are what I think are the relevant entries from the .config file: CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_IP_FIB_HASH=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_FWMARK=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_VERBOSE=y CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y CONFIG_IP_VS=m CONFIG_IP_VS_TAB_BITS=12 CONFIG_IP_VS_PROTO_TCP=y CONFIG_IP_VS_PROTO_UDP=y CONFIG_IP_VS_PROTO_ESP=y CONFIG_IP_VS_PROTO_AH=y CONFIG_IP_VS_RR=m CONFIG_IP_VS_WRR=m CONFIG_IP_VS_LC=m CONFIG_IP_VS_WLC=m CONFIG_IP_VS_LBLC=m CONFIG_IP_VS_LBLCR=m CONFIG_IP_VS_DH=m CONFIG_IP_VS_SH=m CONFIG_IP_VS_SED=m CONFIG_IP_VS_NQ=m CONFIG_IP_VS_FTP=m CONFIG_IPV6=m CONFIG_IPV6_PRIVACY=y CONFIG_IPV6_TUNNEL=m CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_CT_ACCT=y CONFIG_IP_NF_CONNTRACK_MARK=y CONFIG_IP_NF_CT_PROTO_SCTP=m CONFIG_IP_NF_FTP=m CONFIG_IP_NF_IRC=m CONFIG_IP_NF_TFTP=m CONFIG_IP_NF_AMANDA=m CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP6_NF_QUEUE=m CONFIG_IP_SCTP=m Rebuilding the kernel is not a good option here, is there some other way to work around this? Thanks, David Mathog mathog@caltech.edu Manager, Sequence Analysis Facility, Biology Division, Caltech ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
David Mathog wrote:> > Rebuilding the kernel is not a good option here, is there some other > way to work around this? >It appears that the kernel was built with CONFIG_NETFILTER_XT_MATCH_STATE=n (or whatever the option was called back in 2.6.16; I have no systems running a kernel that old). If you confirm that the option isn''t set then the only course of action available to you is to rebuild the kernel; or abandon any idea of running a stateful firewall on the box. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > > David Mathog wrote: > > > > > Rebuilding the kernel is not a good option here, is there some other > > way to work around this? > > > > It appears that the kernel was built withCONFIG_NETFILTER_XT_MATCH_STATE=n> (or whatever the option was called back in 2.6.16; I have no systemsrunning> a kernel that old).You are correct, it is not set. However, another thing I do not understand is why shorewall is setting the rule that triggers this problem. Reviewing, it came down to: shorewall stop shorewall clear iptables --list Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination /sbin/iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT iptables: No chain/target/match by that name Whereas on all other systems the /sbin/iptables command worked at the same point. I already tried setting IP_FORWARDING=Off and it still did that /sbin/iptables command. What I really want here is just: Chain FORWARD (policy DROP) target prot opt source destination The two relevant pieces from policy are: loc net REJECT net loc DROP I wonder, is it maybe the REJECT in the first line (no matter what the /sbin/iptables command was doing)? Changed that to DROP. Hey, shorewall started! Nmap indicates that it''s working. Thanks, David Mathog mathog@caltech.edu Manager, Sequence Analysis Facility, Biology Division, Caltech ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
David Mathog wrote:> > and it still did that /sbin/iptables command. What I really want here > is just: > > Chain FORWARD (policy DROP) > target prot opt source destination > > The two relevant pieces from policy are: > > loc net REJECT > net loc DROP > > I wonder, is it maybe the REJECT in the first line (no matter what the > /sbin/iptables command was doing)? Changed that to DROP. Hey, > shorewall started! Nmap indicates that it''s working.ONE MORE TIME -- Shorewall is never going to work on this system until you fix the kernel. There is NOTHING that you can do to the configuration to make Shorewall work. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
Tom Estep wrote:> was built with CONFIG_NETFILTER_XT_MATCH_STATE=n > (or whatever the option was called back in 2.6.16;The support folks for the machine in question kindly sent me a 2.6.16.60 kernel with CONFIG_NETFILTER_XT_MATCH_STATE=m Sadly, shorewall won''t start on that either. The problem (now) shows up at: shorewall -vv start ... Clearing Traffic Control/QOS Deleting user chains... Enabling Loopback and DNS Lookups iptables: No chain/target/match by that name Terminated and shorewall debug start 2>/tmp/trace tail -20 /tmp/trace + local base=logdrop + local pf + limit=''--match limit --limit 5/minute --limit-burst 3'' + tag+ command=-A + shift 7 + ''['' -n '''' -a -n '''' '']'' + ''['' -n '''' '']'' ++ printf Shorewall:%s:%s: logdrop DROP + prefix=Shorewall:logdrop:DROP: + ''['' 23 -gt 29 '']'' + case $level in + /sbin/iptables -A logdrop --match limit --limit 5/minute --limit-burst 3 -j LOG --log-level info --log-prefix Shorewall:logdrop:DROP: iptables: No chain/target/match by that name + ''['' 1 -ne 0 '']'' + ''['' -z '''' '']'' + stop_firewall + case $COMMAND in + set +x Terminated Any idea what it needs this time? It appears to be trying to add a rule for a LOG chain, when there is no such chain. The system in question has syslogd running and all messages are logged over the network to another server''s syslogd. Nothing is logged locally because the system disk is a flash drive. Thanks, David Mathog mathog@caltech.edu Manager, Sequence Analysis Facility, Biology Division, Caltech ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
David Mathog wrote:> Tom Estep wrote: > >> was built with CONFIG_NETFILTER_XT_MATCH_STATE=n >> (or whatever the option was called back in 2.6.16; > > The support folks for the machine in question kindly sent me a > 2.6.16.60 kernel with > > CONFIG_NETFILTER_XT_MATCH_STATE=m > > Sadly, shorewall won''t start on that either. The problem (now) shows up > at: > > shorewall -vv start > ... > Clearing Traffic Control/QOS > Deleting user chains... > Enabling Loopback and DNS Lookups > iptables: No chain/target/match by that name > Terminated > > and > > shorewall debug start 2>/tmp/trace > tail -20 /tmp/trace > + local base=logdrop > + local pf > + limit=''--match limit --limit 5/minute --limit-burst 3'' > + tag> + command=-A > + shift 7 > + ''['' -n '''' -a -n '''' '']'' > + ''['' -n '''' '']'' > ++ printf Shorewall:%s:%s: logdrop DROP > + prefix=Shorewall:logdrop:DROP: > + ''['' 23 -gt 29 '']'' > + case $level in > + /sbin/iptables -A logdrop --match limit --limit 5/minute --limit-burst > 3 -j LOG --log-level info --log-prefix Shorewall:logdrop:DROP: > iptables: No chain/target/match by that name > + ''['' 1 -ne 0 '']'' > + ''['' -z '''' '']'' > + stop_firewall > + case $COMMAND in > + set +x > Terminated > > Any idea what it needs this time? It appears to be trying to add a rule > for a LOG chain, when there is no such chain. The system in question > has syslogd running and all messages are logged over the network to > another server''s syslogd. Nothing is logged locally because the system > disk is a flash drive.CONFIG_IP_NF_TARGET_LOG Without that option, your firewall can do no logging. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
Tom Eastep wrote:> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > > David Mathog wrote: > > The support folks for the machine in question kindly sent me a > > 2.6.16.60 kernel with > > > > CONFIG_NETFILTER_XT_MATCH_STATE=m > > > > Sadly, shorewall won''t start on that either.<SNIP>> > CONFIG_IP_NF_TARGET_LOG > > Without that option, your firewall can do no logging.The config file shows that that one is set: CONFIG_IP_NF_TARGET_LOG=m Here are all the CONFIG_IP_NF_* entries: CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_CT_ACCT=y CONFIG_IP_NF_CONNTRACK_MARK=y CONFIG_IP_NF_CT_PROTO_SCTP=m CONFIG_IP_NF_FTP=m CONFIG_IP_NF_IRC=m CONFIG_IP_NF_TFTP=m CONFIG_IP_NF_AMANDA=m CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_LOG=m and all of the CONFIG_NETFILTER* CONFIG_NETFILTER=y CONFIG_NETFILTER_NETLINK=m CONFIG_NETFILTER_NETLINK_QUEUE=m CONFIG_NETFILTER_NETLINK_LOG=m CONFIG_NETFILTER_XTABLES=m CONFIG_NETFILTER_XT_MATCH_MAC=m CONFIG_NETFILTER_XT_MATCH_MARK=m CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m CONFIG_NETFILTER_XT_MATCH_STATE=m Here are all the modules in: /lib/modules/2.6.16.60-c1/kernel/net/ipv4/netfilter ip_conntrack.ko ip_conntrack_amanda.ko ip_conntrack_ftp.ko ip_conntrack_irc.ko ip_conntrack_proto_sctp.ko ip_conntrack_tftp.ko ip_queue.ko ip_tables.ko ipt_LOG.ko ipt_REJECT.ko iptable_filter.ko Is something obvious (to you, clearly it isn''t to me) missing which in turn is effectively disabling CONFIG_IP_NF_TARGET_LOG? Our other linux systems have many more modules in this directory, but for the system in question all we need to do is to restrict access to certain port/address ranges on the public interface. No forwarding, nat, masquerade, etc. are needed. Thanks, David Mathog mathog@caltech.edu Manager, Sequence Analysis Facility, Biology Division, Caltech ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
David Mathog wrote:> Here are all the CONFIG_IP_NF_* entries: > > CONFIG_IP_NF_CONNTRACK=m > CONFIG_IP_NF_CT_ACCT=y > CONFIG_IP_NF_CONNTRACK_MARK=y > CONFIG_IP_NF_CT_PROTO_SCTP=m > CONFIG_IP_NF_FTP=m > CONFIG_IP_NF_IRC=m > CONFIG_IP_NF_TFTP=m > CONFIG_IP_NF_AMANDA=m > CONFIG_IP_NF_QUEUE=m > CONFIG_IP_NF_IPTABLES=m > CONFIG_IP_NF_FILTER=m > CONFIG_IP_NF_TARGET_REJECT=m > CONFIG_IP_NF_TARGET_LOG=m > > and all of the CONFIG_NETFILTER* > > CONFIG_NETFILTER=y > CONFIG_NETFILTER_NETLINK=m > CONFIG_NETFILTER_NETLINK_QUEUE=m > CONFIG_NETFILTER_NETLINK_LOG=m > CONFIG_NETFILTER_XTABLES=m > CONFIG_NETFILTER_XT_MATCH_MAC=m > CONFIG_NETFILTER_XT_MATCH_MARK=m > CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m > CONFIG_NETFILTER_XT_MATCH_STATE=m > > Here are all the modules in: > /lib/modules/2.6.16.60-c1/kernel/net/ipv4/netfilter > > ip_conntrack.ko > ip_conntrack_amanda.ko > ip_conntrack_ftp.ko > ip_conntrack_irc.ko > ip_conntrack_proto_sctp.ko > ip_conntrack_tftp.ko > ip_queue.ko > ip_tables.ko > ipt_LOG.ko > ipt_REJECT.ko > iptable_filter.ko > > Is something obvious (to you, clearly it isn''t to me) missing > which in turn is effectively disabling CONFIG_IP_NF_TARGET_LOG? >This isn''t brain surgery: At a high level, the failing rule parses to: -A logdrop --match limit --limit 5/minute --limit-burst 3 <==================-j LOG --log-level info --log-prefix Shorewall:logdrop:DROP: Shorewall creates ''logdrop'' so we can assume it is there. You have verified that the LOG target is supported. That leaves the match marked with <====== which requires limit match. See http://www.shorewall.net/kernel.htm to figure out which config option that is and on which kernels. You can eliminate the need for that match in your log rules by resetting LOGRATE and LOGBURST in shorewall.conf. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
Tom Eastep wrote:> At a high level, the failing rule parses to: > > -A logdrop > --match limit --limit 5/minute --limit-burst 3 <==================> -j LOG --log-level info --log-prefix Shorewall:logdrop:DROP: > > Shorewall creates ''logdrop'' so we can assume it is there. > > You have verified that the LOG target is supported. > > That leaves the match marked with <====== which requires limit match. See > http://www.shorewall.net/kernel.htm to figure out which config optionthat> is and on which kernels.Actually, I did look there. The issue is that on a general purpose kernel (as at that link) every one of the CONFIG_NETFILTER_XT_MATCH_* modules is set to "m". The system in question runs off of a 500Mb flash drive, space is tight (the system disk is at 87% as is), so the vendor ships as few modules as possible for the kernel. At present it has only 4, out of 17, of these modules. I''m looking for the minimum number of modules to keep shorewall happy, when it is configured to block a few port/address combinations on the public interface. Log limits aren''t something we''d want to do without though, since that could result in the syslogd on the system handling logging for this box getting swamped with messages. Conversely, completely eliminating log messages would mean flying blind, which isn''t great either. Hopefully adding CONFIG_NETFILTER_XT_MATCH_LIMIT=m will be enough. Thanks, David Mathog mathog@caltech.edu Manager, Sequence Analysis Facility, Biology Division, Caltech ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
David Mathog wrote:> Hopefully adding > > CONFIG_NETFILTER_XT_MATCH_LIMIT=m > > will be enough. >Please read what I wrote -- YOU DON''T NEED THE MODULE IF YOU JUST CHANGE YOUR CONFIGURATION. And you might want to look at the minimal kernel config at the bottom of the article I referred you to rather than persisting with this try/fail, try/fail, ... approach. That config uses a 2.6.21 kernel but only the name prefix of the modules have changed -Yom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php