new firewall concept

[ohrensessel]

the current firewall concept has problems with asymetric routing, e.g.

• in case of the v6 uplink, traffic might leave a certain gateway but come back via another. connection tracking therefore can not relate incoming packages to a connection, leading to state INVALID (?, possibly as the packages are not part of the connection establishment.).
• in case of the icvpn, the same as above also holds.
• we had problems with traffic that came in via br-ffhh and also left via br-ffhh. explicitly allowing this type of traffic without any connection tracking helped.

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.
• currently there are the zones mesh and wan. an additional uplink zone should be added targeting vpn, v4 and v6 uplink. for the latter it should be possible to disable connection tracking.
• bcp38 filtering for ingress and egress traffic on uplink and icvpn interfaces.

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

[sargon]

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?

[ohrensessel]

• that is the thing I'm trying to understand. do the 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)
• accepting forwarding traffic before connection tracking is working but at the moment requires some ugly workarounds to enter the appropriate rules in front of the connection tracking. so there is currently no real support for that.

[sargon]

• According to the documentation that disables all netfilter stuff on that bridge. I am not familiar what will happen if you have iptables rules on the slave interfaces. Sounds like we need a test setup and test that.
• Okay, than we should introduce stages, which we connect to some numbers in the firewall order?

[ohrensessel]

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.

[sargon]

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.