2015. július 15., szerda

Living with IPFire (bye-bye pfSense)

In the first part of this article I discussed some interesting facts about pfsense. I, again, strongly recommend not to use pfSense 2.2.* in production environments because it is a totally unreliable and buggy system. Okay but what to use then ?
For instance, one can choose IPFire. Yep, I did. It's rock solid, lightning fast and easy to use system. Everything that can't be told about pfSense. I like it.
Except for one minor thing... And that thing is, sadly, not that minor.
For anyone who is familiar with standard iptables chains and logic (I mean input/output/forward/etc) it's very confusing the way pfsense and IPFire virtually handles the traffic.
IPFire consists lots of built-in chains that can be troublesome at the first glance. But you will never get to know about those ones if you use only the GUI based rules editor. I've spent 3 days, frankly, on creating some very basic allow and deny rule on the red0 interface, without any success. That totally screwed me up. You can just never be sure where (I mean, which chain) your web edited rules will be put in. E.g. below shown rules are all faulty, God knows why.
Playing with basic IPFire rules

So I ended up with editing the /etc/sysconfig/firewall.local file and tadaaam, that worked. If you are an expert on iptables, forget your firewall fancy GUI editor forever.

case "$1" in
  start)
        iptables -A CUSTOMINPUT -d 255.255.255.255 -p udp --dport 7437 -j DROP
        iptables -A CUSTOMINPUT -i red0 ! -s 192.168.1.1 -p udp -j DROP
        ;;
  stop)
        iptables -D CUSTOMINPUT -d 255.255.255.255 -p udp --dport 7437 -j DROP
        iptables -D CUSTOMINPUT -i red0 ! -s 192.168.1.1 -p udp -j DROP
        ;;


Just a small side note: reloading the rules with the GUI also reloads your .local defined rules.

Nincsenek megjegyzések:

Megjegyzés küldése