Bridging firewall between two sites with same network

We have been assigned an IP-network for a test lab we can use for our equipment. To make sure our mistakes wont leave us nor anything from the outside will disturb us we want to setup a firewall without without NAT. We simply want a firewall so we can stop some errors from reaching in or out to the rest of the group.

Network 192.168.100.128/26 GW 192.168.100.129

I've set up a Linksys WRT1900 with OpenWRT and configured it as bridge between WAN and LAN.

The bridge is working but it either blocks all or nothing. It seems that the ARPs are not passing. What needs to be in place for the ARPs passing? Or is it something else that is missing?

brctl addbr br-lan
brctl addif eth0.1 eth1.2

brctl show
bridge name bridge id       STP enabled interfaces
br-lan      7fff.5aef...    no          eth0.1
                                        eth1.2

WAN = eth1.2
LAN = eth0.1

So far everything is working as long as the firewall is set to policy ACCEPT for WAN->LAN. Well, all traffic is passing. Policy for LAN->WAN is ACCEPT.

As soon as I put WAN->LAN policy to REJECT, even with rules to ACCEPT from any SRC to eg 192.168.100.132 and port 53 nothing happens any longer. (dig x.x.x.x @192.168.100.132 has no reply)

I notic that the ARP requests for "Who has IP 192.168.100.132" never passes the bridge when policy is set to REJECT. I have a vague idea that the ARPs are rejected and of course nothing can get through then, but I don't get what should take care of this.

I thought that the bridge interface took care of the ARP table to know where to send, but when set to reject it seems it doesn't let the request pass. In a way it makes sense, but how will it learn the mac when a rule says it is ok for IP/53 to pass?

I presume that something needs to be added to grant the ARP requests/replies to pass through. There is no secret which IPs are behind the bridge, it's just a way to control the traffic.

This is a study so far but I thought I could take a rule at the time to eventually set it up properly. And I sort of failed at start.

What needs to be in place for the ARPs passing? Or is it something else that is missing?

ifconfig:
br-lan    Link encap:Ethernet  HWaddr 5A:EF:68:0F:B1:53  
          inet addr:192.168.100.130  Bcast:192.168.100.191  Mask:255.255.255.192

eth0      Link encap:Ethernet  HWaddr 5A:EF:68:0F:B1:53
eth0.1    Link encap:Ethernet  HWaddr 5A:EF:68:0F:B1:53
eth1      Link encap:Ethernet  HWaddr 58:EF:68:0F:B1:53

route -n
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.100.129 0.0.0.0         UG    0      0        0 br-lan
192.168.100.128 0.0.0.0         255.255.255.192 U     0      0        0 br-lan

This is a study so far but I thought I could take a rule at the time to eventually set it up properly. And I sort of failed at start.

One requirement for the bridge to work was to install kmod-br-netfilter and configure kernel parameters

# Configure kernel parameters
cat << EOF >> /etc/sysctl.conf
net.bridge.bridge-nf-call-arptables=1
net.bridge.bridge-nf-call-iptables=1

which is done.

Update. Bricked the router. New approach. Setting up a management port via VLAN so I can listen to what's going on. And the VLAN seems to hold even with great experimentation... so far.

I'm keeping the above in case there are related info.

=======================

Router: WRT1900ACS/OpenWRT 19.07.4

Network: 192.168.124.144/29 GW: 192.168.124.145 on WAN side Router(FWbridge) is at 192.168.124.147. At the moment, 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 192.168.124.146 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) (192.168.190.17/24) 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 192.168.190.17 (management port) works from "LAN" side (from inside a LAN behind NAT) ssh 192.168.124.147 works from WAN zone. (strange since interface for .147 is on LAN side) ssh 192.168.124.147 from LAN zone do NOT work. (strange because .47 is on LAN side) ssh 192.168.124.146 from OpenWRT seems to wait. ssh 192.168.124.145 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?? .... After some digging around iptables, firewalling and briding I found this (even if there is no Shorewall firebridge, the same about iptables should apply to my question) :

Configuring Shorewall

As described above, Shorewall bridge support requires the physdev
match feature of Netfilter/iptables. Physdev match allows rules
to be triggered based on the bridge port that a packet arrived on
and/or the bridge port that a packet will be sent over. The
latter has proved to be problematic because it requires that the
evaluation of rules be deferred until the destination bridge port
is known. This deferral has the unfortunate side effect that it
makes IPsec Netfilter filtration incompatible with bridges. To
work around this problem, in kernel version 2.6.20 the Netfilter
developers decided to remove the deferred processing in two
cases:

When a packet being sent through a bridge entered the firewall on
another interface and was being forwarded to the bridge.

When a packet originating on the firewall itself is being sent
through a bridge.

Notice that physdev match was only weakened with respect to the
destination bridge port -- it remains fully functional with
respect to the source bridge port.

To deal with the asymmetric nature of the new physdev match,
Shorewall supports a new type of zone - a Bridge Port (BP) zone.
Bridge port zones have a number of restrictions:

BP zones may only be associated with bridge ports.

All ports associated with a given BP zone must be on the same
bridge.

Policies from a non-BP zone to a BP are disallowed.

Rules where the SOURCE is a non-BP zone and the DEST is a BP zone
are disallowed.

In /etc/shorewall/zones, BP zones are specified using the bport
(or bport4) keyword. If your version of shorewall.conf contains
the BRIDGING option, it must be set to No.

When reading this I really wonder if bridging between WAN and LAN as a bridge actually works. Why wouldn't more than one IP-network work? It is still a bridge. If the bridge does not have any IP-address and therefore no netmask, how could it distinguish?

I've setup a VLAN for a management interface for the router that is on a completely different IP-network. Maybe that is the reason then? I my world this should be fine, and I'm by this last text (from Shorewall) a bit confused about things.

From another page about briding firewalls everything looks as simple as my mind was from the beginning. This briding firewall even has a NAT for a separate network along with the bridge.

Debian manual briding firewall

This is exactly my aim.

For the moment I have at best some pings that gets through out on LAN side, but almost none at the WAN side. But not zero.

Update: Okay, this was a bit embarresing. Not for all, but still. reject and REJECT are not the same. Found a 'reject' found it's way in as an end-rule. And as such effectively blocking most traffic through. However, the 'reject'-criteria is met after 3x...

iptables -A FORWARD -i eth0.1 -j zone_lan_forward
iptables -A FORWARD -i eth1.2 -j zone_wan_forward
iptables -A FORWARD -i eth0.3 -j zone_mngtm_forward
iptables -A FORWARD -j reject

This must mean that the packages coming are detected as any of these interfaces. One possibility is that the packet is coming in as 'br-fwbr' but then it would not be possible to check for specific interface. I assumed from the beginning that the bridge-ports still can identify eth0.1 and eth1.2 as individual interfaces as from where the packet arrived. eth0.1 and eth1.2 are bridged as br-fwbr.

The intermitted stalling with some 30-60 seconds in between for some 5-15 seconds still happens randomly. I thought it could be cyclic at first but it is to random for that. No time events are set. The bridge/router is at a minimum, mostly completely open. Working on closing it up.