freifunk-berlin / firmware

DEPRECATED: Build system for Berlin firmware. Please user the pinned falter-repos instead

https://berlin.freifunk.net

GNU General Public License v3.0

73 stars 34 forks source link

Necessity of firewall #283

Closed basros closed 5 years ago

basros commented 8 years ago

Question: Do we actually need the whole firewall/iptables stack on routers or is there maybe a smarter way to achieve the same functionality?

Proposal: As far as i know, our firewall rules are mostly used to prohibit vpn03-in-vpn03 connections. We can also just do that on the vpn03 servers itself...

Are there any other usecases that might be solved by e.g. using policy-rules instead of iptables-rules?

Removing iptables improves performance and saves up disk-space for 4MB devices...

sarumpaet commented 8 years ago

+1! I don't really know what iptables is necessary for otherwise... I remember some related changes here: https://github.com/freifunk-berlin/firmware-packages/commit/9c0561329f98ec0ba814dc534fc46ea859c90682 (just for reference).

lynxis commented 8 years ago

vpn in vpn can be blocked. but not vpn over freifunk using a "normal" internet node.

booo commented 8 years ago

Maybe we can remove the block at the router and server side if we work on: https://github.com/freifunk-berlin/firmware/issues/272

sarumpaet commented 8 years ago

openvpn-hotplug gets rid of the VPN03 related firewall rules.

However, iptables still gets pulled into default images as it's a dependency of qos-scripts. We could get rid of it if we drop the traffic limit feature or omit qos-scripts (at least in the 4MB images) and call tc ourselves - tc seems to be independent from iptables in principle as far as I can see. We could check in the OpenVPN ifup script if qos-scripts is present and call tc directly if that's not the case. Concerning the firewall package, this seems to be an artificial dependency of luci-mod-freifunk/freifunk-firewall. Let's see what happens if we remove that.

booo commented 8 years ago

And again we spent a lot of work for shitty hardware...

If the qos-script has unnecessary dependencies on iptables and in reality dependes on tc we should maybe fix this upstream?

sarumpaet commented 8 years ago

qos-scripts seems to use a combination of iptables and tc. Look at the output of "/usr/lib/qos/generate.sh all" to see what's done. Pure traffic limiting (without QoS) can be done with tc only though.

pmelange commented 5 years ago

I believe that with the realse of Hedy, this issue is not longer relevant. The firewall is needed to NAT everything going over ffuplink.

If there is a way to remove the firewall with Hedy, then please reopen this issue.

sarumpaet commented 5 years ago

@pmelange This wasn't quite the entire point of this issue. See initial comment: One question was whether we could possibly get rid of the iptables binary as well, which is more than 100k (but we cannot, as it's used by qos-scripts). But with tunneldigger etc. upcoming, it's probably moot, even with 4MB routers.

SvenRoederer commented 5 years ago

to get rid of the iptables command, it might help to look at https://github.com/freifunk-berlin/firmware/issues/548, as this will not depend on additional binaries and seems to be quite small.