Open ohrensessel opened 9 years ago
Wouldn't disabling ip/ip6/arp-tables on br-ffhh also expose the host itself to the network? This would disable any attacks from within the network, so bad idea.
Uplink zone should be no problem at all.
Why is accepting forwarding traffic on these devices, before the connection tracking steps in, not working?
net.bridge.bridge-nf-call-*
options only disable iptables and so on for bridged traffic or also for forwarded traffic and traffic for the local ip (which is on the bridge interface)another idea: use ipset to have some sets of ip adresses. e.g. a set containing all prefixes used by communities on that particular gateway, a set containing all prefixes which should be filtered according to bcp38.
I'm currently thinking about how to hinder packets with destination from within private ip ranges to go through the nat. at the moment my solution would be to block private destinations within mesh-forward right in front of the accept rules for the v4 uplink interfaces.
The all loved nat should only apply when the traffic run through the also planed uplink zone, nor? Hence we can first jump the packet from the mesh(-forward) chain to the uplink chain in 800 and then check in 850 if the package matches the bcp38 rules. Therefore we would not transmit packages from source addresses we don't want to receive from on the wan zone.
I like the ipset idea, didn't know of its existence, yet. Thanks for mentioning.
the current firewall concept has problems with asymetric routing, e.g.
some changes I would like to discuss:
net.bridge.bridge-nf-call-arptables = 0, net.bridge.bridge-nf-call-ip6tables = 0, net.bridge.bridge-nf-call-iptables = 0
as sysctl options, disabling iptables alltogether for traffic on br-ffhh. I personally don't know if this also disables iptables for traffic that is targeting IPs associated to the bridge itself or only forwarded traffic.I am open for any other things you might find helpful. this should be a discussion, my points given above are possibly not the best