Firewall rules, iptables, local NAT configuration, rate limiting, blacklisting, flood protection, all words and phrases that will send your average sysadmin into lunch mode. The defacto firewall implementations provided by the various Linux distributions are (generally speaking) both horrible to create, read and maintain. This gives the impression that firewalls are hard.
Granted, if you want to create and edit your firewall by hand then yes, it can be hard work and yes it can be hard to maintain. That said, coding firewall rules by hand is a bit like coding machine code in binary. Nobody does it, it's pointless.
If you need to write machine code , one generally chooses to use assembly language, which is the sort of level the solutions provided by RedHat and Ubuntu provide. However, most people prefer to code in something that's a little higher level (C for example) which is then converted to machine code by a compiler - in context, this is pretty much what firehol does.
You get to set up a bunch of rules in something approximating readable English, then firehol converts that into raw iptables commands that get executed at kernel level, so it's a sort of compiler or macro language for iptables.
If you look at a raw iptables command, unless you know the syntax it's pretty unreadable and unless you wrote the rules in the first place, there's a good chance it'll be including some subtle nuances you don't fully appreciate or understand.
However, this is what a basic firehol configuration looks like, in this instance we're saying that only interface eth0 is enabled, and it will allow all outgoing traffic, but no incoming.
version 5 interface eth0 public client all accept
Let's get a little more interesting, people often try to break servers on the Internet by throwing malformed packets at them, so we could do with some protection there, and also we would like to respond to pings so we can make sure the server is up, and we would like to be able to ssh to the server, but only from our IP address and nowhere else .. now what does the configuration look like?
version 5 interface eth0 public protection bad-packets server icmp accept server ssh accept src "<my ip address>" client all accept
Horrible isn't it, almost completely unreadable?! Ok, so as it turns out we'd like to add a mail server (SMTP) but we're a little worried about denial of service type attacks, so we'd like to rate limit the connection, and also prevent some known spammy IP's from connecting to the server.
version 5 blacklist full <spammy IP> interface eth0 public protection bad-packets server icmp accept server smtp accept limit 5 100 # max 5/sec average with 100/sec burst server ssh accept src "<my ip address>" client all accept
Ok, so this is all really easy stuff, what about something a little more complex, let's say we have two interfaces, one that's connected to the office network and one that faces the Internet, and we want outgoing connections to be NATted as they pass through the box.
version 5 interface eth0 private policy accept interface eth0 public protection strong server icmp accept client all accept router outgoing_nat inface eth0 outface eth1 masquerade route all accept
Once we have these configs, they can be tested by using firehol try, which will install the new rules and ask you to confirm you're happy with them, and if you don't respond after 20 seconds, it'll revert to the last known / good configuration. So in theory, you can't even cut yourself off from a remote server. I say "in theory", there's always the instance where you change the firewall rules and forget to run firehol try and end up with a broken rule that will cut you off next time you reboot ...
Yes, Ok, there's some syntax to learn, but there is a very good online manual, and due to the nature of the syntax, after many years using firehol I can tell you the syntax (unlike that of raw iptables) is very sticky and once you have it, retention is pretty good.
Quick Q&A; yes it does both SNAT and DNAT, yes it does VLAN's, yes it does multiple masquerades, yes it does multiple routers, yes you can embed raw iptables commands within the configuration, yes you can use BASH variables within the script to make it more readable, yes you can configure custom services / port numbers, yes it will handle IPV4 and IPV6, no, in 10 years I've not come across anything it can't cope with.