Someone else is going to have to help you with firewalld. My guess is either the first command you tried is not how it intends you to block single addresses or it is not intended as a granular replacement for iptables.
As to:
good question. You are on linux, so you are in the land of netfilter. Why use something that just obscures your access to netfilter? But that’s just my preference.
I think you need to use something other than blocking the return traffic. You could remove that address from the routing table completely:
ip rule add to 78.129.196.116 blackhole priority 10
and then your host would not even think 78.129.196.116 was a reachable address.
That didn’t appear to work:
[tarulia@localhost]~% sudo ip rule add to 78.129.169.116 blackhole priority 10
[tarulia@localhost]~% sudo ip rule list
0: from all lookup local
10: from all to 78.129.169.116 blackhole
32766: from all lookup main
32767: from all lookup default
[tarulia@localhost]~% wget theaudiodb.com
--2019-09-13 18:13:44-- http://theaudiodb.com/
Resolving theaudiodb.com (theaudiodb.com)... 78.129.196.116
Connecting to theaudiodb.com (theaudiodb.com)|78.129.196.116|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://theaudiodb.com/ [following]
--2019-09-13 18:13:44-- https://theaudiodb.com/
Connecting to theaudiodb.com (theaudiodb.com)|78.129.196.116|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 31328 (31K) [text/html]
Saving to: ‘index.html.1’
index.html.1 100%[=================================================>] 30.59K --.-KB/s in 0.001s
2019-09-13 18:13:44 (23.0 MB/s) - ‘index.html.1’ saved [31328/31328]
Do I still need the iptables rule in that case?
/edit
oops, mistyped IP address 
[tarulia@localhost]~% sudo ip rule add to 78.129.196.116 blackhole priority 10
[tarulia@localhost]~% sudo ip rule list
0: from all lookup local
10: from all to 78.129.196.116 blackhole
32766: from all lookup main
32767: from all lookup default
[tarulia@localhost]~% wget theaudiodb.com
--2019-09-13 18:15:51-- http://theaudiodb.com/
Resolving theaudiodb.com (theaudiodb.com)... 78.129.196.116
Connecting to theaudiodb.com (theaudiodb.com)|78.129.196.116|:80... failed: Invalid argument.
Well… that worked, but I’m still wondering if this is not possible with Firewalld… I mean everything I read sounds like it would.
You probably can block the return traffic with firewalld. But I have no idea how to do it. Good luck.
For my curiousity, when you added the block rule to the output chain, did you set 78.129.196.116 as the source (-s 78.129.196.116) or destination (-d 78.129.196.116) address? If you forget to set it as the destination rather than source, that would explain why wget was still able to reach 78.129.196.116.
Which yes… I did 
Just tried it again and it works with OUTPUT and -d:
[root@localhost tarulia]# iptables -I OUTPUT -d 78.129.196.116 -p tcp -j REJECT
[root@localhost tarulia]# ip rule del to 78.129.196.116
[root@localhost tarulia]# ip rule list
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
[root@localhost tarulia]# iptables -L OUTPUT --line-numbers
Chain OUTPUT (policy ACCEPT)
num target prot opt source destination
1 REJECT tcp -- anywhere 78.129.196.116 reject-with icmp-port-unreachable
2 ACCEPT all -- anywhere anywhere
3 OUTPUT_direct all -- anywhere anywhere
[root@localhost tarulia]# exit
exit
[tarulia@localhost]~% wget theaudiodb.com
--2019-09-13 18:29:27-- http://theaudiodb.com/
Resolving theaudiodb.com (theaudiodb.com)... 78.129.196.116
Connecting to theaudiodb.com (theaudiodb.com)|78.129.196.116|:80... failed: Connection refused.
That is the bane of the command line: single character flags where the keys are right next to each other either of which creates a valid command but completely changes the tenor of the command.
Yeah, gotta be real careful what you’re typing
Anyway, thanks for the help.
If anyone still has a solution for Firewalld, would be very interested. Doesn’t really make sense that it shouldn’t work with that…
So I guess I missed the part where your host IP you want blocked is the IP that you are wget’ing from?
I think that shows how firewalld intends you to pull this off. Blocking the return traffic alone is not sufficient if you are going to originate requests to the blocked ip because of that cstate related rule. You also need to block the outbound traffic too so the related rule will never match.
Your iptables printout shows the output chain:
Chain OUTPUT (policy ACCEPT 4586 packets, 435K bytes)
pkts bytes target prot opt in out source destination
981 234K ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
4586 435K OUTPUT_direct all -- * * 0.0.0.0/0 0.0.0.0/0
refers to the OUTPUT_direct:
Chain OUTPUT_direct (1 references)
pkts bytes target prot opt in out source destination
which is empty.
So you need to find the firewalld setting that allows you to add 78.129.196.116 as a blocked destination address (edit): in addition to the source firewalld rule you already added.
Well, seems so That was the original issue. Essentially jellyfin is trying to access the theaudiodb.com API and while doing so runs into an issue (apparently SSL handshake related) that crashes the process. And currently the only “solution” is blocking access to theaudiodb (since apparently disabling it in the settings doesn’t actually disable it).
I was only wget’ing to show it in a terminal output.
That is what I thought, however I could not find a way to do it. I was wondering from the start why I was supposed to block incoming traffic when I don’t want to reach it in the first place.
You can try another method of “blocking” domain access. Add theaudiodb.com in HOST to point to 0.0.0.0
The domain traffic itself is not blocked, but the system will always have the address 0.0.0.0 indicated for that domain. And hence, he will not gain access to it. If you can’t block domains on a firewall, this will work better without having to block per IP.
And when it comes to firewalls. Rather, always apply the principle of blocking outbound traffic rather than based on traffic that returns at the request of an already initiated session. Rather, it will not matter where the traffic comes to the host if the state table already has output initiated to a specific IP address. Especially that we are talking about an https session here?
A normal rule should block outgoing traffic for a given IP.
-A OUTPUT -d 78.129.196.116/32 -j DROP
Yeah that’s what we did now above.
I’m just wondering how the right way to do it with Firewalld would look like.
Hmm?
firewall-cmd --direct --add-rule ipv4 filter OUTPUT 0 -d 78.129.196.116/32 -j REJECT
Well… that was easy 
Why did I need 6h for that again? 
So… just checked the bundled GUI application for the firewall, and I can’t find that simple rule anywhere, so apparently something so simple isn’t possible in it?
/edit
Actually… it is, but the view is disabled by default. So for posterity:
So everything works as it should?
Yes.
Thanks all for the help 
I’m late to the party, but first thing I noticed is you put the IP block in the zone=home, by default, firewalld uses zone=public which where the IP block would of taken effect.
EDIT: Ahh I missed the part where you have zone=home as your active one, nevermind.
