Briding Firewall bridge iptables arp

Setting up a briding firewall between our little office and the lab. We don't want messy traffic where we are. However for different reasons we need to use a network-segment we are assigned before we can have NAT routers etc. So we decided having a bridging firewall setup in between.

Router: WRT1900ACS/OpenWRT 19.07.4

GW: on WAN side
Router may be setup with At the moment it is, but it may have a different setup later with a maintenance port/network setup. For now it is include om the network.

Our NAT router is at on LAN side.
I have tried different approaches and they have sooner or later ended with a brick.

Is loading ("installing") kmod-br-netfilter mandatory or depricated?
(net.bridge.bridge-nf-call-arptables=1 and net.bridge.bridge-nf-call-iptables=1)
Installing arptables?

I've setup a management port on VLAN3 (eth0.3) (
I've removed the default bridge br-lan with eth0/radios.

Using Luci:
LAN connects to eth0.1
WAN connects to eth1.2
Creating an interface fwbr and attaching to eth0.1 and eth1.2.
This creates a bridge interface (br-fwbr).

brctl show
br-fwbr eth0.1 and eth1.2

arptables -L shows only empty chains with policy ACCEPT for all.

ssh (management port) works from "LAN" side (from inside a LAN behind NAT)
ssh works from WAN zone. (strange since interface for .147 is on LAN side)
ssh from LAN zone do NOT work. (strange because .47 is on LAN side)
ssh from OpenWRT seems to wait.
ssh from OpenWRT returns exited. Connect failed: Host is unreachable

Firewall settings:
LAN => WAN input=output=forward=accept (No masq)
WAN => LAN input=output=forward=accept (No masq)
MNGTM => reject input=output=accept forward=reject (No masq)
The rest is pretty much standard and as I can see there are no blocking rules.

The ICMP packets sent from .145 has come through BRFW to .146 and keeps getting slower and slower and finally nothing comes through. If I wait long enough they start coming after some 30-120seconds. And stops again.

I'm out of thoughts - what's in the way??

While this won't really help your cause directly, I would strongly recommend to switch to a supported release (e.g. 22.03.x) now, before spending too much time on the EOLed 19.07.x branch. Given the swconfig --> dsa migration for mvebu, none of what you might learn now, applies to modern dsa based releases anymore - so better fix it once and for all.

1 Like

Well, it occured to me as well as a good thing, I started to upgrade and realized how much else I would have to work on. I'm stuck with a whole bunch of them for some time. But you are absolutely right about upgrading to the coming system design is a good thing for many reasons.

Thank you for your concern!