hpr-knowledge-base/hpr_transcripts/hpr4303.txt

Episode: 4303
Title: HPR4303: TIL two things to do with firewalld
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr4303/hpr4303.mp3
Transcribed: 2025-10-25 22:40:01

---

This is Hacker Public Radio Episode 4303 for Wednesday the 29th of January 2025.
Today's show is entitled, TIL 2 Things to Do with Fireworld.
It is hosted by D. N, T end is about 9 minutes long.
It carries a clean flag.
The summary is, you can't use 10.0.0.0 and if you restart Fireworld, you should restart
your podmin containers.
You are listening to a show from the Reserve Q. We are airing it now because we had free
slots that were not filled.
This is a community project that needs listeners to contribute shows in order to survive.
Please consider recording a show for Hacker Public Radio.
Hello and welcome to another exciting episode of Hacker Public Radio.
This is your host, D. N. T. So, this will be a short one about some things that I ran
into with Fireworld D. Fireworld D is the Fireworld application from, I think it's made
from made by Red Hat and it's pretty good, I use it and I like it.
But I ran into some things that caused me to waste a bunch of time recently.
Well two things really, so first of all I discovered that apparently when you are assigning
IP addresses to computers, you can't use the first or the last address in a slash 24
internet, what that means is the one where all the three bytes in each, the first three
bytes are the same, so we are talking about all the IPs where the first three bytes are
the same, only the last byte changes, right?
So in this case I'm talking about those wire guard IPs that we set that are like 10.0.0.1,
for example, that's I think a common way to set them up.
So yeah what I discovered is that if you give one of your computers the IP 10.0.0.0 that
will cause problems and you will waste some time like I did.
So yeah, for whatever reason I decided to give one of my computers the 10.0.0.0 and actually
my, all my Linux computers were, they were fine with that, they could communicate with
that IP, they could ping it and access resources on those systems, but my Android phone would
not have it, right?
And I lost a bunch of time trying to think what am I missing, what am I forgetting here
because you know you always forget stuff when you're using things like firewall D and
setting up some networked things in your home.
And so finally I discovered it was 10.0.0.0 that would just not work.
And the way I discovered this is I finally had decided to install Termux on my phone which
I hadn't had it installed yet because it's a new phone that I just got a pixel 5 and
I installed Graphino S on it.
So I just hadn't had Termux and I kind of didn't want to do it yet.
Anyway, so I installed it and then I tried to ping 10.0.0.0 and then it said, oh, if you
want a broadcast you should use hyphen B. Then I said, oh, it's wanting to, it's, it
thinks I'm referring to the whole subnet, right, to 10.0.0.0 slash 24, right?
There was a recent episode explaining how CIDR notation works.
It was very good.
I'll put it in the show notes if you're curious about what you're talking about.
So, so anyway, that was something that cost me at least a couple of hours, I think.
And the other thing which is just kind of funny is that, oh, yeah, one, one thing to
add is that then I looked it up after having seen the, the result from the, from using
ping on Termux.
I looked something up and then I found somebody talking about how you can't use the first
or the last address in the, in the slash 24 subnet.
No idea why the last one would be forbidden as well, but the first one apparently is because
to avoid confusion between referring to a specific address and referring to a subnet, right?
Which is kind of silly because when you're referring to a subnet, you need, you need
to put slash 24 at the end in this case.
So there would be no ambiguity there in fact, but whatever.
So also a mystery to me why my Linux computers which are running Debian had no problem with
this, but the Android phone did.
So then the other thing, so yeah, the movie on the other thing that was just kind of funny,
not really a problem or anything, is that I kept noticing that Firewall D would add an
address, a source IP to one of my zones to the trusted zone.
The trusted zone in Firewall D is whatever you put in the trusted zone, which can be interfaces
or, or source IP addresses, whatever you put in the trusted zone, all connections will
be accepted by the computer that is running Firewall D, right?
So I kept seeing this rule come up when the Firewall D was running, which would say that
the IP 10.89.0.0 slash 24, that is that subnet of all IP addresses start beginning with 10.89.0,
it was adding that to the trusted zone, right?
And I couldn't understand why, and it was adding it only temporarily, not permanently,
which means that then when you restart the Firewall D service, that rule is no longer there.
So then yeah, after seeing this a few times and being a little bit puzzled, I discovered
that this is added by podman when you start a container.
And then what that also means is that another source of confusion is that then if you're
running a container in podman, and then you restart your Firewall D service, your container
will no longer work.
It will now time out when you try to access the services that are running in the container.
So what you had to do is you had to bring the container down and bring it up again after
you restart the Firewall D service.
So yeah, kind of weird, right, but it makes sense, I can definitely understand that.
And that didn't cause as much time wasted, but I did see the container going mysteriously
starting to time out.
And then when I tried to access something in it, and then I would restart the container
and then it was back up.
And I was thinking maybe there's something wrong with the container.
It's just dying after it starts, but no, it was Firewall D and the fact that the podman
will add that rule when you start the container, but it won't keep checking to make sure the
rule is there, right?
So yeah, those were some things that I learned, I guess.
And I wrote them down here to record for an episode of Hacker Public Radio for the reserve
queue.
So do like I just did and take some of this random stuff that you learned that probably
nobody in your life would ever want to sit and listen to you talk about them and pick
up a microphone and record an episode of Hacker Public Radio where some of these loons
will want to listen to you.
Now come back tomorrow for another exciting episode of Hacker Public Radio, bye.
You have been listening to Hacker Public Radio at Hacker Public Radio does work.
Today's show was contributed by a HBR listener like yourself.
If you ever thought of recording podcasts, click on our contribute link to find out how
easy it really is.
HBR has been kindly provided by an onsthost.com, the internet archive and our sings.net.
On the Sadois status, today's show is released under Creative Commons, Attribution 4.0 International
License.