Bug 909614

OK, adding an rsync service was easy, listed files in the firewalld RPM, copied one to /etc/firewalld/services/rsync.xml and changed it to the following, could have used the firewall GUI for this:
<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>rsync</short>
  <description> Define service and port for rsync daemon service.</description>
  <port protocol="tcp" port="873"/>
</service>

After doing:
firewall-cmd --direct --passthrough ipv4 -t filter --line-numbers --list

Was surprised to see all the chains, including the ones for the zones not being used. It seems very wrong to have all the extra, I'm hoping unused, rules but we are doing the forensics to see if we can grasp the intent of this change.

We are used to using a very simple set of rules which seemed to provide all the safety needed after the NAT router which does the port forward for a very small set of services. Below is our rule set. Note the SSHD chain which is used for dynamic drop rules added by the Perl script sshdfilter on root login attempts, ping ssh port, too many attempts, unknown user attempts. The internal network is 10.2.2.0 with a netmask of 255.255.255.0. We are not experts in this so we are looking for constructive help.
# Generated by iptables-save v1.3.5 on Sat Nov 11 12:48:03 2006
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [569:82408]
:RH-Firewall-1-DST - [0:0]
:RH-Firewall-1-INPUT - [0:0]
:SSHD - [0:0]
-A INPUT -j RH-Firewall-1-INPUT 
-A INPUT -p tcp -m tcp --dport 22 -j SSHD 
-A FORWARD -j RH-Firewall-1-INPUT 
-A RH-Firewall-1-DST -d 224.0.0.0/240.0.0.0 -j DROP 
-A RH-Firewall-1-INPUT -i lo -j ACCEPT 
-A RH-Firewall-1-INPUT -s 172.16.0.0/255.240.0.0 -j DROP 
-A RH-Firewall-1-INPUT -s 192.168.0.0/255.255.0.0 -j DROP 
-A RH-Firewall-1-INPUT -s 224.0.0.0/240.0.0.0 -j DROP 
-A RH-Firewall-1-INPUT -s 240.0.0.0/248.0.0.0 -j DROP 
-A RH-Firewall-1-INPUT -s 0.0.0.0/255.0.0.0 -j DROP 
-A RH-Firewall-1-INPUT -d 255.255.255.255 -j DROP 
-A RH-Firewall-1-INPUT -s 169.254.0.0/255.255.0.0 -j DROP 
-A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT 
-A RH-Firewall-1-INPUT -s xxx.76.32.0/255.255.255.0 -p tcp -m tcp --dport 22 -j ACCEPT 
-A RH-Firewall-1-INPUT -s xxx.76.64.0/255.255.255.0 -p tcp -m tcp --dport 22 -j ACCEPT 
-A RH-Firewall-1-INPUT -s 10.2.2.0/255.255.255.0 -p tcp -m tcp --dport 22 -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 22 -j SSHD 
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -s 10.2.2.0/255.255.255.0 -j ACCEPT 
-A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited 
COMMIT
# Completed on Sat Nov 11 12:48:03 2006

(In reply to comment #0)
> - How to define your internal network to accept connections between peer
> nodes?

Specifying source address/port is not yet supported. (bug #903222)

> - The configuration files are now XML where are the XSD files for validation?

We don't have any yet.
 
> direct rules. But what if you would like them to persist across restart.

That's not possible at the moment. (bug #815489)
 
> Migration for this does not seem easily accomplished as iptables now no
> longer functions as before!

iptables (the tool as well as the service) should still work, you just need to disable firewalld service and enable iptables service.
# systemctl stop firewalld.service
# systemctl disable firewalld.service
# systemctl start iptables.service
# systemctl enable iptables.service
# systemctl start ip6tables.service
# systemctl enable ip6tables.service

> Questions seem pretty basic how could we miss better documentation? 

All the documentation we have is
https://fedoraproject.org/wiki/FirewallD
and man pages:
firewall-cmd(1), firewalld(1), firewalld.conf(5), firewalld.zones(5)
firewalld.icmptype(5), firewalld.service(5), firewalld.zone(5)

(In reply to comment #1)
> Was surprised to see all the chains, including the ones for the zones not
> being used.

bug #907375

> Below is our rule set.

Would you mind if I close this bug as duplicate of bug #903222 ?
Because the impossibility of specifying source address
seems to be the blocker here.

After reviewing the referenced bug reports please close this one as a duplicate. I did do a search before, but did not recognize the other reports by the summary titles.

Tried stopping, disabling firewalld.service and then starting and enabling iptables. Will not run. Just in case, we reverted the /etc/sysconfig/iptables file to the default, it still will not run. Even went through a reboot just incase something was fouled up, still no joy.

Fixed the issue, was not getting run as the start of the ypbind service was failing due to a misconfigured dhcp server. Talk about Murphy striking.

*** This bug has been marked as a duplicate of bug 903222 ***