Custom Firewall Rules Lost on Reboot

[W4JEW]

I tried following the instructions as outlined here:

http://wiki.pistar.uk/Adding_custom_fir ... to_Pi-Star

The following is the rule that I need to add:

iptables -A OUTPUT -p udp --dport 62036 -j ACCEPT

I looked under /root and the file 'ipv4.fw' does not exist. I looked at the 'pistar-firewall' script and it looks like it's supposed to check for the presence of that file and incorporate any rules, so I manually created the file and added that rule. Then I rebooted Pi-Star.

I ran 'sudo iptables -S | grep 62036' and I do not see any rules there.

I also tried running 'sudo pistar-firewall' after creating the ipv4.fw file, then ran 'sudo iptables -S | grep 62036' and I do see the rule is there, but if I reboot Pi-Star, the rule is gone.

What am I missing here?

[W4JEW]

I hope Andy Taylor can weigh in here. Hopefully, this isn't a matter of needing any major changes.

It's odd that there's an article on the Pi-Star Wiki that infers the ipv4.fw file should be present on the filesystem when in fact it's not present.

It seems as though, based on the following section, pistar-firewall should import any rules specified in /root/ipv4.fw:

Code: Select all

# If there are custom rules, pull them in here
if [ -f "/root/ipv4.fw" ]
then
  echo "Custom IPv4 Firewall rules loaded..."
  source /root/ipv4.fw
fi

That's about as straightforward as it gets.

Interestingly enough, if I add the rule that I want to /root/ipv4.fw, then run 'pistar-firewall' while the filesystem is in the read-only (rpi-ro) state, the script prints that the custom rules were loaded but the script couldn't make changes due to the file-system being read-only:

Code: Select all

root@zumspot(ro):etc# pistar-firewall
Setting IPv4 Rules...
Custom IPv4 Firewall rules loaded...
/usr/local/sbin/pistar-firewall: line 190: /etc/iptables.rules: Read-only file system

If I issue sudo iptables -S | grep 62036 after running pistar-firewall and the filesystem is in a read-only state, I see that the rule was added:

Code: Select all

pi-star@zumspot(ro):~$ sudo iptables -S | grep 62036
-A OUTPUT -p udp -m udp --dport 62036 -j ACCEPT

However, if I issue 'rpi-rw', then run 'pistar-firewall', not only can I see the rule was added to the active firewall policy, I can also see the rule was added to /etc/iptables.rules.

Code: Select all

root@zumspot(rw):etc# more /etc/iptables.rules | grep 62036
-A OUTPUT -p udp -m udp --dport 62036 -j ACCEPT

After I rebooted my hotspot, I can confirm that the rule is active. This tells me that Pi-Star invokes iptables with the rules as specified in /etc/iptables.rules.

Obviously, the script isn't able to modify /etc/iptables.rules while the filesystem is read-only. It seems as though the script should be modified to check to see if the filesystem is read-only, then force it to read-write before it tries to save the rules. It's possible that pistar-firewall relies on being called from pistar-update and that's the reason why you've seen the behavior you stated in your response. The script should be able to compensate for cases when it's executed independently as opposed to relying on another script.

[W4JEW]

Thanks for the follow-up.

You dug through all the script and posted sections of it, but didn't bother to investigate what it was reporting.

Actually, the line you referenced in the 'pistar-firewall' script is exactly how I discovered that the script was trying to write changes to /etc/iptables.rules. It wasn't until I opened 'pistar-firewall' that I realized this was what it was trying to do. So I did "bother" to check, I didn't comment about every little step I took in working through the issue I was having.

The article on the Pi-Star wiki is a little misleading and not very thorough.

http://wiki.pistar.uk/Adding_custom_fir ... to_Pi-Star

Step 3 - Edit the custom firewall script

This step implies there's already a script there

Step 4 - Add your custom rule

Steps 3 and 4 don't say anything to the effect that the file doesn't already exist
The sample that's provided implies there's already some content in the ipv4.fw file
Based upon your explanation, the step should be updated to say something like this: "the ipv4.fw file does not exist by default - you will need to create it yourself - follow the examples in the code snip below"

Code: Select all

 # Comments can be added using the hash at the start of a line
 # This line adds outgoing access to UDP/41401
 iptables -A OUTPUT -p udp --dport 41401 -j ACCEPT #			NXDN Outbound to extra host
 # This line adds DSCP marking to this traffic to give it voice priority on the network
 # you dont need this but its a good thing for voice packets
 iptables -t mangle -A POSTROUTING -p udp --dport 41401 -j DSCP --set-dscp 46

Thanks for following up with me. I appreciate the guidance!

-JeffH

Jeff Hochberg
W4JEW
Atlanta, GA

[W4JEW]

@KE7NFS

I'll tell you what - go take a look at my profile on LinkedIn to see what I do for a living - then tell me I don't have familiarity with Linux or Unix operating systems.

https://www.linkedin.com/in/jeffhochberg

I've been working with Linux/UNIX operating systems for the past 25+ years - including AIX/HPUX/Solaris and others. I cut my teeth on Linux with Slackware and RedHat 4.0.

I work for a company that makes the leading enterprise class firewall available on the market and have been working with firewalls for the past 22+ years.

I write a lot of documentation in my current role. I also read a lot of documentation written by developers that think is adequate. I usually have to rewrite it to make it something that will make sense to my customers.

Whenever I'm reading someone else's documentation, I always look at it from the perspective of those that aren't as knowledgeable. It's not that I don't have the knowledge - I do. I know full well about what nano does when a file doesn't already exist. I mostly use vi and don't even bother with nano.

I also ask questions in forums in such a way that others can learn from the exchange between the requester and the individual(s) that provide responses. The forum provides a searchable resource for people to use when they need to research issues. Ensuring whatever is archived is something that will help the masses is something I always try to do. Asking questions that might appear elementary is something I do intentionally.

Granted, the process of adding custom firewall rules is a relatively advanced topic, so making an assumption that a user has a certain level of knowledge is a somewhat reasonable expectation however it depends on the skill level of the majority of your customer/user base. When the vast majority of the users aren't savvy with Linux, it's incumbent on whoever is writing the documentation to frame it in a manner that is consumable by the masses.

The irony of this is, until you started taking my questions personally and writing your crass responses, there was nothing personal about it. Sassy comments along the lines of:

getting hung up on your own inferences probably due to being unfamiliar with Linux or Unix based operating systems

-OR-

Comments like this:

even in Windoze you can open and edit a file without it existing on the disk first

These do nothing more than deteriorate your credibility and show a level of disrespect to things that others may hold in high regard. I use all major operating systems on an almost daily basis and see the benefits of each. I never dig at someone for their use of any one particular operating system. Religious battles around things like this are nothing more than a sign of someone that has a lack of respect for others IMO. Personally, I let comments like "Windoze" roll off. But when someone assumes I don't have a certain level of knowledge without knowing that other person, I draw the line there.

Now - back to the heart of the matter:

In step 3, it states

edit the custom firewall script


Whether you see it that way or not, to some it _DOES_ imply that there's already a custom script present. This would be a far more effective way of communicating your point to the reader:

Code: Select all

To incorporate any custom firewall rules, Pi-Star will check for the presence of /root/ipv4.fw. This file does not exist by default. Create a new file and add the new rules, then save changes and run either 'pistar-firewall' or 'pistar-update' which will read the contents of /root/ipv4.fw and import the custom rules.