Bug 903222

*** Bug 901818 has been marked as a duplicate of this bug. ***

*** Bug 909614 has been marked as a duplicate of this bug. ***

I am also looking for similar functionality within FirewallD.  All I want to do is "block" a specific IP or IP range within FirewallD.

Something like:

firewall-cmd --permanent --zone=(block|drop) --add-sourceip=11.22.33.44.55(/mask)

Forcing the firewall to block or drop packets from sourceip.

With the new firewalld version in rawhide/F-19 support for rules with a source address has been added, also support to bind a source address or an interface permanently to a zone.

There is only support for this in the configuration files and no command line tool and D-Bus interface up to now. This will be added shortly.

For rules with a source address please have a look at:
https://fedoraproject.org/wiki/Features/FirewalldRichLanguage

For binding a source address or an interface permanently to a zone add the following to the zone configuration file in /etc/firewalld/zones:

<zone>
  <interface name="foobar"/>
  <source family="ipv4" address="192.168.0.1"/>
  <source family="ipv6" address="1:2:3:4::"/>
  ...
</zone>

(In reply to Thomas Woerner from comment #4)
> For binding a source address or an interface permanently to a zone add the
> following to the zone configuration file in /etc/firewalld/zones:
> 
> <zone>
>   <interface name="foobar"/>
>   <source family="ipv4" address="192.168.0.1"/>
>   <source family="ipv6" address="1:2:3:4::"/>
>   ...
> </zone>

I'm encountering issues with the above suggestion, and have read [1].  I have the following configuration:

# interface p2p1 in the following "special_dmz.xml" zone:
<?xml version="1.0" encoding="utf-8"?>
<zone>
  <short>Special DMZ</short>
  <description>For interfaces that are publicly-accessible via IPv6 with limited access to your internal network. Only selected incoming connections are accepted.</description>
  <service name="mdns"/>
  <service name="dhcpv6-client"/>
</zone>

# additional "special_internal.xml" configured for "internal" IP addrs:
<?xml version="1.0" encoding="utf-8"?>
<zone>
  <short>Special Internal</short>
  <description>For use on internal networks. Only incoming connections from specified IP source address ranges to specified services are accepted.</description>
  <source family="ipv4" address="10.1.1.0/24"/>
  <source family="ipv4" address="10.2.2.0/24"/>
  <source family="ipv6" address="1:2:3:4::/64"/>
  <service name="ssh"/>
</zone>


Unfortunately, while I expect to see the special_dmz zone "fall through" to the "special_internal" zone for the specified addrs, it does not and all processing seems to stop.  I'm *NOT* an IPTables expert, but based on what I can tell of the difference between -g (GOTO) and -j (JUMP), it appears that with the following ruleset (created by firewalld from the above zones), traffic seems to stop processing at the -j (JUMP) to IN_ZONE_special_dmz_allow since it doesn't return to IN_ZONE_special_dmz and match the source.  (I could be way wrong, but either way, the source binding doesn't seem to do what I think it does).

# Just the IPv4 portion below (IPv6 shows the same behavior)
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -j INPUT_direct
-A INPUT -j INPUT_ZONES
-A INPUT -p icmp -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited

-A INPUT_ZONES -i p2p1 -g IN_ZONE_special_dmz
-A INPUT_ZONES -s 10.1.1.0/24 -j IN_ZONE_special_internal
-A INPUT_ZONES -s 10.2.2.0/24 -j IN_ZONE_special_internal

-A IN_ZONE_special_dmz -j IN_ZONE_special_dmz_log
-A IN_ZONE_special_dmz -j IN_ZONE_special_dmz_deny
-A IN_ZONE_special_dmz -j IN_ZONE_special_dmz_allow
-A IN_ZONE_special_dmz_allow -d 224.0.0.251/32 -p udp -m udp --dport 5353 -m conntrack --ctstate NEW -j ACCEPT

-A IN_ZONE_special_internal -j IN_ZONE_special_internal_log
-A IN_ZONE_special_internal -j IN_ZONE_special_internal_deny
-A IN_ZONE_special_internal -j IN_ZONE_special_internal_allow
-A IN_ZONE_special_internal_allow -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT


[1] https://lists.fedorahosted.org/pipermail/firewalld-users/2013-June/000066.html

After some testing (manually editing the freshly created firewalld rules), it appears that modifying the following from Comment #5 seems to allow processing to continue as expected:

In the INPUT_ZONES chain, the first rule containing the input interface

-A INPUT_ZONES -i p2p1 -g IN_ZONE_special_dmz

needs to be changed from -g (GOTO) to -j (JUMP) to allow the return to INPUT_ZONES, rather than all the way back to INPUT, as follows

-A INPUT_ZONES -i p2p1 -j IN_ZONE_special_dmz

I am not certain if this will create problems for other things, but it corrected the problem described in Comment #5.

(In reply to Anthony Messina from comment #6)
> I am not certain if this will create problems for other things, but it
> corrected the problem described in Comment #5.

The "-g" seems to be added as a part of Bug 912782.

(In reply to Anthony Messina from comment #5)
> Unfortunately, while I expect to see the special_dmz zone "fall through" to
> the "special_internal" zone for the specified addrs, it does not and all
> processing seems to stop.

I think you're building on a false assumption.
The zones are not supposed to interfere/follow each other.

(In reply to Jiri Popelka from comment #8)
> I think you're building on a false assumption.
> The zones are not supposed to interfere/follow each other.

Thanks, Jiri, but I think the issue is that packets that match the interface will never get to the rules that match the source as the interface target is called with GOTO:

-A INPUT -j INPUT_ZONES
-A INPUT -p icmp -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited

-A INPUT_ZONES -i p2p1 -g IN_ZONE_special_dmz
-A INPUT_ZONES -s 10.1.1.0/24 -j IN_ZONE_special_internal

From the ipatables man page for -g, --goto chain
"Unlike the --jump option return will not continue processing in this chain but instead in the chain that called us via --jump."

So packets that come in on p2p1, if not matched in "IN_ZONE_special_dmz" will return to "INPUT_ZONES", since it was the last match that called the JUMP.

With this logic, I can't see how the binding of source addresses actually does anything, since the packets won't hit the rule--they match the rule/zone which is bound to the interface.  If not matched in "-A INPUT_ZONES -i p2p1 -g IN_ZONE_special_dmz", the next rule they match is "-A INPUT -j REJECT --reject-with icmp-host-prohibited".

With
https://git.fedorahosted.org/cgit/firewalld.git/commit/?h=sources&id=b582b315ce185639c991820f958d30f30c3e6e90

we create following chains/rules

-A INPUT -j INPUT_ZONES_SOURCE
-A INPUT -j INPUT_ZONES
-A INPUT -j REJECT --reject-with icmp-host-prohibited

-A INPUT_ZONES_SOURCE -s 1.2.3.0/24 -g IN_ZONE_home
-A INPUT_ZONES_SOURCE -s 6.6.6.0/23 -g IN_ZONE_work
-A INPUT_ZONES -i em1 -g IN_ZONE_home
-A INPUT_ZONES -g IN_ZONE_public

Scratch-build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=5652546

> [18:46] <twoerner> there is currently a bug in firewalld that the source binds do not have a higher priority than interface binds

As i understand it this 'bug' should be fixed with the above commit/chains/rules.

(In reply to Jiri Popelka from comment #10)
> With
> https://git.fedorahosted.org/cgit/firewalld.git/commit/
> ?h=sources&id=b582b315ce185639c991820f958d30f30c3e6e90
> 
> we create following chains/rules
> 
> -A INPUT -j INPUT_ZONES_SOURCE
> -A INPUT -j INPUT_ZONES
> -A INPUT -j REJECT --reject-with icmp-host-prohibited
> 
> -A INPUT_ZONES_SOURCE -s 1.2.3.0/24 -g IN_ZONE_home
> -A INPUT_ZONES_SOURCE -s 6.6.6.0/23 -g IN_ZONE_work
> -A INPUT_ZONES -i em1 -g IN_ZONE_home
> -A INPUT_ZONES -g IN_ZONE_public
> 
> Scratch-build:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=5652546
> 
> > [18:46] <twoerner> there is currently a bug in firewalld that the source binds do not have a higher priority than interface binds
> 
> As i understand it this 'bug' should be fixed with the above
> commit/chains/rules.

I can confirm that the above "fixes" this issue completely (and allows for perfect failover from INPUT_ZONES_SOURCE to INPUT_ZONES)!  This is exactly what I would expect it to do.  Thank you!

OK, merged to master, the commit is now
https://git.fedorahosted.org/cgit/firewalld.git/commit/?id=b582b315ce185639c991820f958d30f30c3e6e90

FYI, using firewalld-0.3.3-3.fc19.noarch, I am able to solve the problems listed in the bug report to this point, however, I get the following error when adding services to a "sources" based zone.  It appears that the local config is not able to override a default template placed in /usr/lib/firewalld/zones

1. Install "/usr/lib/firewalld/zones/special_internal.xml":

<?xml version="1.0" encoding="utf-8"?>
<zone>
  <short>Special Internal</short>
  <description>For use on internal networks. Only incoming connections from specified IP source address ranges to specified services are accepted.</description>
  <source family="ipv4" address="10.1.1.0/24"/>
  <source family="ipv6" address="1:2:3:4::/64"/>
  <service name="ssh"/>
</zone>

2. Now add another service to the special_internal zone:
firewall-cmd --zone special_internal --add-service ipp-client, so the resulting updated zone file in "/etc/firewalld/zones/special_internal.xml" looks like:

<?xml version="1.0" encoding="utf-8"?>
<zone>
  <short>Special Internal</short>
  <description>For use on internal networks. Only incoming connections from specified IP source address ranges to specified services are accepted.</description>
  <source family="ipv4" address="10.1.1.0/24"/>
  <source family="ipv6" address="1:2:3:4::/64"/>
  <service name="ssh"/>
  <service name="ipp-client"/>
</zone>

3. Observe the following error at system boot or firewall-cmd --reload
firewalld[276]: 2013-07-25 21:30:20 ERROR: Failed to load zone file '/etc/firewalld/zones/special_internal.xml':

These should fix it.
https://git.fedorahosted.org/cgit/firewalld.git/commit/?id=43ea096febc6dfa31ec20c4f067b0abfdbc560c4
https://git.fedorahosted.org/cgit/firewalld.git/commit/?id=23e4e351b2588031b0f298537e750b260374d7c1
https://git.fedorahosted.org/cgit/firewalld.git/commit/?id=fde205298e2dfaf39289ee0372ce947a6b599ea5
We'll hopefully make a new release soon so you can continue testing.

Thanks.  I'd welcome the new release as it really makes a difference for complex server support in firewalld.

firewalld-0.3.4-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/firewalld-0.3.4-1.fc19

Package firewalld-0.3.4-1.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing firewalld-0.3.4-1.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-14046/firewalld-0.3.4-1.fc19
then log in and leave karma (feedback).

firewalld-0.3.4-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.