2

I'd like to:

  1. Drop all incoming connections from the external Web except 80 and 443
  2. Allow internal machines on 192.168.0.0/16 to connect to :9000 :8080

Here's what I did to setup my drop zone via firewall-cmd:

echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
sysctl -p
systemctl start firewalld.service
systemctl enable firewalld
firewall-cmd --set-default-zone=drop
firewall-cmd --permanent --zone=drop --add-service=ssh
firewall-cmd --permanent --zone=drop --add-port=80/tcp
firewall-cmd --permanent --zone=drop --add-port=443/tcp
firewall-cmd --zone=drop --permanent --add-rich-rule='rule source address="192.168.0.0/16" port port="9000" protocol="tcp" accept'
firewall-cmd --zone=drop --permanent --add-rich-rule='rule source address="192.168.0.0/16" port port="8080" protocol="tcp" accept'
firewall-cmd --reload

Here's what the active drop zone looks like:

[root@machine ~]# firewall-cmd --zone=drop --list-all
drop (default, active)
  interfaces: eth0 vethadc7c41 vethaef84e2 vethd53fa38
  sources: 
  services: ssh
  ports: 443/tcp 80/tcp
  masquerade: no
  forward-ports: 
  icmp-blocks: 
  rich rules: 
  rule family="ipv4" source address="192.168.0.0/16" port port="9000" protocol="tcp" accept
  rule family="ipv4" source address="192.168.0.0/16" port port="8080" protocol="tcp" accept

This appears OK; however, I run into issues after reload:

[root@machine ~]# systemctl status firewalld -l
firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled)
   Active: active (running) since Sun 2014-12-21 19:48:53 UTC; 2s ago
 Main PID: 21689 (firewalld)
   CGroup: /system.slice/firewalld.service
           └─21689 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid

Dec 21 19:48:53 machine.hostname systemd[1]: Started firewalld - dynamic firewall daemon.
Dec 21 19:48:56 machine.hostname firewalld[21689]: 2014-12-21 19:48:56 ERROR: '/sbin/iptables -t filter -A DROP_allow -s 192.168.0.0/16 -m tcp -p tcp --dport 9000 -m conntrack --ctstate NEW -j ACCEPT' failed: iptables: No chain/target/match by that name.
Dec 21 19:48:56 machine.hostname firewalld[21689]: 2014-12-21 19:48:56 ERROR: '/sbin/iptables -t filter -A DROP_allow -s 192.168.0.0/16 -m tcp -p tcp --dport 9000 -m conntrack --ctstate NEW -j ACCEPT' failed: iptables: No chain/target/match by that name.
Dec 21 19:48:56 machine.hostname firewalld[21689]: 2014-12-21 19:48:56 ERROR: COMMAND_FAILED: '/sbin/iptables -t filter -A DROP_allow -s 192.168.0.0/16 -m tcp -p tcp --dport 9000 -m conntrack --ctstate NEW -j ACCEPT' failed: iptables: No chain/target/match by that name.
Dec 21 19:48:56 machine.hostname firewalld[21689]: 2014-12-21 19:48:56 ERROR: '/sbin/iptables -t filter -A DROP_allow -s 192.168.0.0/16 -m tcp -p tcp --dport 8080 -m conntrack --ctstate NEW -j ACCEPT' failed: iptables: No chain/target/match by that name.
Dec 21 19:48:56 machine.hostname firewalld[21689]: 2014-12-21 19:48:56 ERROR: '/sbin/iptables -t filter -A DROP_allow -s 192.168.0.0/16 -m tcp -p tcp --dport 8080 -m conntrack --ctstate NEW -j ACCEPT' failed: iptables: No chain/target/match by that name.
Dec 21 19:48:56 machine.hostname firewalld[21689]: 2014-12-21 19:48:56 ERROR: COMMAND_FAILED: '/sbin/iptables -t filter -A DROP_allow -s 192.168.0.0/16 -m tcp -p tcp --dport 8080 -m conntrack --ctstate NEW -j ACCEPT' failed: iptables: No chain/target/match by that name.

I'm a bit confused as I believed firewall-cmd to be an abstraction and sort of mutually exclusive with iptables, the latter being something I shouldn't mess with.

Here are my version vitals:

[machine@douglasii ~]# firewall-cmd -V
0.3.9
[machine@douglasii ~]# cat /proc/version
Linux version 3.16.7-x86_64-linode49 (maker@build) (gcc version 4.7.2 (Debian 4.7.2-5) ) #3 SMP Fri Nov 14 16:55:37 EST 2014
[machine@douglasii ~]# cat /etc/redhat-release
CentOS Linux release 7.0.1406 (Core) 
[machine@douglasii ~]# iptables -v
iptables v1.4.21: no command specified
Try `iptables -h' or 'iptables --help' for more information.
editor
  • 373
  • 1
  • 5
  • 20

1 Answers1

3

The Linode kernel you are using doesn't have the modules your firewall wants. This is why you get the error "No chain/target/match by that name."

(And firewalld is a front-end to iptables.)

To resolve the problem, you need to run the kernel provided by the virtual machine, rather than the Linode kernel. Do this by setting the Linode to boot pv-grub-x86_64 and then installing a kernel with yum install kernel if one isn't already installed.

Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
  • Good catch on the fact that I'm using a Linode. I presume this to be a correct answer and will give it a shot. Do you have a guess on what the missing module is (e.g. `conntrack`)? – editor Dec 21 '14 at 20:02
  • Unfortunately this didn't do the trick. I'm on a fresh kernel, same errors. `Linux version 3.10.0-123.13.2.el7.x86_64 (builder@kbuilder.dev.centos.org) (gcc version 4.8.2 20140120 (Red Hat 4.8.2-16) (GCC) )`. Any tips on which module? Installed `conntrack-tools` via yum but it didn't solve. – editor Dec 21 '14 at 20:44
  • @editor Looks like the right kernel. Are you quite sure you're still getting the same error and not a different one? – Michael Hampton Dec 21 '14 at 21:00
  • Unfortunately so https://gist.github.com/buley/2ff20699b0e46c453c50 – editor Dec 21 '14 at 21:04
  • @editor Wait, why are you trying to add rules to the firewalld DROP zone? That's meant to drop all traffic, and not to be extended. Use another zone. – Michael Hampton Dec 21 '14 at 21:05
  • Attempting. My usage of "drop" was that I wanted to, by default, drop all packets to ports I didn't open up. Sounds like I was mistaken. – editor Dec 21 '14 at 21:09
  • @editor You probably want the `public` zone, which was the default zone anyway. – Michael Hampton Dec 21 '14 at 21:12
  • So far, same with both `public` and `trusted` zones https://gist.github.com/buley/e84408d262ef2c138ddb https://gist.github.com/buley/8c47863f751e8f733e2f – editor Dec 21 '14 at 21:14
  • @editor What the...Again, are you sure you're using the right zone? – Michael Hampton Dec 21 '14 at 21:48
  • It appears the issue is not related to zone but rather in the so-called rich rules. Remove them, and the errors go away. It appears I'll need to cook up a different way to open 9000 and 8080 to `192.168.0.0/16` and 80 and 443 to the world. – editor Dec 22 '14 at 00:44