Wifi Ethernet Bridge / blue access doesn't work with MAC filtering

Networking
1

I’ve set-up a parprouted based Wifi Ethernet bridge according Will Haley’s recipe and used Option 1, same Subnet:

IpFire WLAN 192.168.2.1 <-> 192.168.2.104 WLAN Raspi 3B+ 192.168.2.104 eth0 <-> 192.168.2.4 enp1s0f1 Ubuntu 18.04 laptop

The Raspberry Pi3B+ is acting as a bridge wifi <=> ethernet lan cable

Later I want to connect an IOT device to the LAN connection. This IOT device does not have WiFi.

My problem is as follows:

If I disable MAC filtering for the blue network in IPFire core 171, the internet access from the laptop is working as expected flawlessly.

However, If I enable MAC filtering for the blue network, the internet accesses of the Laptop 192.168.2.4 are blocked, here shown for a DNS access

15:28:59 	DROP_Wirelessinput 	blue0 	UDP 	192.168.2.4  58824  192.168.2.1 53

I’ve enabled the blue access in IPFire for 192.168.2.4 and used the MAC address of the LAN port of the laptop. The bridge seems to translate the LAN access to a WLAN access.

I’m using ’ Force clients to use IPFire DNS Server’.

EDIT: Tracking the wifi interface of the Rasp by wireshark shows that e.g. a DNS request from the laptop is issued by the IP address of the laptop (192.168.2.4) but the MAC address of the Raspberry PI’s WLAN interface. The Wifi interface of the Raspi is already part of the blue MAC access table.
Unfortunately, I cannot enter in the blue MAC filter table two IP addresses with the same MAC address or one IP address with two different MAC addresses.

2nd EDIT: Could my issue be solved by a custom WIRELESSINPUT rule and custom WIRELESSFORWARD rule in firewall.local? What would be the necessary syntax?

How can I use the MAC filtering for a parprouted based Ethernet2WLAN bridge according Will Haley’s recipe?

Thanks for your help in advance.

2

just a suggestion… it may be easier to setup Scenario #1 on this wiki page:

3

Thanks @jon for your proposal. I will keep it in mind.

Your suggestion, however, would not allow me to run on the Raspi a database server with graphical analysis capability of the captured data from the IOT device. For that purpose, I need a Raspberry Pi OS running with a possibility to install a lot of additional packages which are not supported by pakfire.

Therefore, I will continue to investigate the firewall.local approach:

My current idea is to add in /etc/sysconfig/firewall.local the following rules:

#!/bin/sh
# Used for private firewall rules

# See how we were called.
case "$1" in
  start)
        ## add your 'start' rules here

        ## .. other rules here

        # additional rules for parprouted Raspi bridge

        /sbin/iptables -A CUSTOMFORWARD -s 192.168.2.4/32 -i blue0 -m mac --mac-source  <mac address of Raspi wlan0 interface>  -j RETURN
        /sbin/iptables -A CUSTOMFORWARD -s 192.168.2.18/32 -i blue0 -m mac --mac-source  <mac address of Raspi wlan0 interface>  -j RETURN
        /sbin/iptables -A CUSTOMINPUT -s 192.168.2.4/32 -i blue0 -m mac --mac-source  <mac address of Raspi wlan0 interface>  -j RETURN
        /sbin/iptables -A CUSTOMINPUT -s 192.168.2.18/32 -i blue0 -m mac --mac-source  <mac address of Raspi wlan0 interface>  -j RETURN
        ;;
  stop)
        ## add your 'stop' rules here

        ## .. other rules here

        # additional rules for parprouted Raspi bridge

        /sbin/iptables -D CUSTOMFORWARD -s 192.168.2.4/32 -i blue0 -m mac --mac-source  <mac address of Raspi wlan0 interface>  -j RETURN
        /sbin/iptables -D CUSTOMFORWARD -s 192.168.2.18/32 -i blue0 -m mac --mac-source  <mac address of Raspi wlan0 interface>  -j RETURN
        /sbin/iptables -D CUSTOMINPUT -s 192.168.2.4/32 -i blue0 -m mac --mac-source  <mac address of Raspi wlan0 interface> -j RETURN
        /sbin/iptables -D CUSTOMINPUT -s 192.168.2.18/32 -i blue0 -m mac --mac-source  <mac address of Raspi wlan0 interface>  -j RETURN
        ;;
  reload)
        $0 stop
        $0 start
        ## add your 'reload' rules here
        ;;
  *)
        echo "Usage: $0 {start|stop|reload}"
        ;;
esac

192.168.2.4 is the assigned IP address of my test laptop.
192.168.2.18 is the assigned IP address of my target IOT device.

Would this work and not affect the other IPFire iptable rules? I haven’t tried it yet.

Thanks for your feedback in advance.

4

Short update from my test:

  1. use ‘-j RETURN’ as shown above in firewall.local: No internet access from the test laptop

  2. use ‘-j ACCEPT’ instead of ‘-j RETURN’ in firewall.local: Internet access from test laptop is working :slight_smile:

However, this will not filter the packets from the IOT device / test laptop by the consecutive iptables chains, e.g. the LOCATIONBLOCK chain:

# Generated by iptables-save v1.8.8 on Tue Dec 27 21:04:08 2022
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:BADTCP - [0:0]
:BLOCKLISTIN - [0:0]
:BLOCKLISTOUT - [0:0]
:BLOCKLIST_DE_DROP - [0:0]
:CAPTIVE_PORTAL - [0:0]
:CAPTIVE_PORTAL_CLIENTS - [0:0]
:CIARMY_DROP - [0:0]
:CONNTRACK - [0:0]
:CTINVALID - [0:0]
:CUSTOMFORWARD - [0:0]            <== CUSTOMFORWARD is one of the first chains
:CUSTOMINPUT - [0:0]              <== CUSTOMINPUT is one of the first chains
:CUSTOMOUTPUT - [0:0]
:DHCPBLUEINPUT - [0:0]
:DHCPBLUEOUTPUT - [0:0]
:DHCPGREENINPUT - [0:0]
:DHCPGREENOUTPUT - [0:0]
:DHCPINPUT - [0:0]
:DHCPOUTPUT - [0:0]
:EMERGING_COMPROMISED_DROP - [0:0]
:FEODO_AGGRESSIVE_DROP - [0:0]
:FEODO_IP_DROP - [0:0]
:FEODO_RECOMMENDED_DROP - [0:0]
:FORWARDFW - [0:0]
:GUARDIAN - [0:0]
:GUIINPUT - [0:0]
:HOSTILE - [0:0]
:HOSTILE_DROP - [0:0]
:ICMPINPUT - [0:0]
:INPUTFW - [0:0]
:IPSBYPASS - [0:0]
:IPSECBLOCK - [0:0]
:IPSECFORWARD - [0:0]
:IPSECINPUT - [0:0]
:IPSECOUTPUT - [0:0]
:IPS_FORWARD - [0:0]
:IPS_INPUT - [0:0]
:IPS_OUTPUT - [0:0]
:IPTVFORWARD - [0:0]
:IPTVINPUT - [0:0]
:LOCATIONBLOCK - [0:0]
:LOG_DROP - [0:0]
:LOG_REJECT - [0:0]
:LOOPBACK - [0:0]
:NEWNOTSYN - [0:0]
:OUTGOINGFW - [0:0]
:OVPNBLOCK - [0:0]
:OVPNINPUT - [0:0]
:POLICYFWD - [0:0]
:POLICYIN - [0:0]
:POLICYOUT - [0:0]
:PSCAN - [0:0]
:REDFORWARD - [0:0]
:REDINPUT - [0:0]
:SHODAN_DROP - [0:0]
:SPOOFED_MARTIAN - [0:0]
:TOR_ALL_DROP - [0:0]
:TOR_EXIT_DROP - [0:0]
:TOR_INPUT - [0:0]
:TOR_OUTPUT - [0:0]
:WIRELESSFORWARD - [0:0]
:WIRELESSINPUT - [0:0]

Can this be managed? How?

5

IPFire is great :slight_smile: I could solve my problem on my own as follows:

I am adding the required additional filter rules at the top of the chains WIRELESSINPUT and WIRELESSFORWARD by editing /etc/sysconfig/firewall.local :

#!/bin/sh
# Used for private firewall rules

# See how we were called.
case "$1" in
  start)
        ## add your 'start' rules here
 
        ## .. other rules here


        # additional rules for parprouted Raspi bridge

        /sbin/iptables -I WIRELESSFORWARD 1 -s 192.168.2.4/32 -i blue0 -m mac --mac-source  <mac address of Raspi wlan0 interface> -j RETURN
        /sbin/iptables -I WIRELESSFORWARD 1 -s 192.168.2.18/32 -i blue0 -m mac --mac-source  <mac address of Raspi wlan0 interface> -j RETURN
        /sbin/iptables -I WIRELESSINPUT 1 -s 192.168.2.4/32 -i blue0 -m mac --mac-source  <mac address of Raspi wlan0 interface> -j RETURN
        /sbin/iptables -I WIRELESSINPUT 1 -s 192.168.2.18/32 -i blue0 -m mac --mac-source  <mac address of Raspi wlan0 interface> -j RETURN
        ;;
  stop)
        ## add your 'stop' rules here

        ## .. other rules here
        
        # additional rules for parprouted Raspi bridge

        /sbin/iptables -D WIRELESSFORWARD -s 192.168.2.4/32 -i blue0 -m mac --mac-source  <mac address of Raspi wlan0 interface> -j RETURN
        /sbin/iptables -D WIRELESSFORWARD -s 192.168.2.18/32 -i blue0 -m mac --mac-source  <mac address of Raspi wlan0 interface> -j RETURN
        /sbin/iptables -D WIRELESSINPUT -s 192.168.2.4/32 -i blue0 -m mac --mac-source  <mac address of Raspi wlan0 interface> -j RETURN
        /sbin/iptables -D WIRELESSINPUT -s 192.168.2.18/32 -i blue0 -m mac --mac-source  <mac address of Raspi wlan0 interface> -j RETURN
        ;;
  reload)
        $0 stop
        $0 start
        ## add your 'reload' rules here
        ;;
  *)
        echo "Usage: $0 {start|stop|reload}"
        ;;
esac

Works like a charm and all iptables chains are executed as ‘normal’. Solved.

Always check the resulting iptables rules by ‘iptables-save’.

1 Like