# Initial wiki page for ebtables

**URL:** <https://community.ipfire.org/t/initial-wiki-page-for-ebtables/10067>\
**Category:** Add-Ons\
**Created:** [18 July 2023 12:31 UTC](https://community.ipfire.org/t/initial-wiki-page-for-ebtables/10067 "2023-07-18T12:31:36Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![cfusco](https://community.ipfire.org/user_avatar/community.ipfire.org/cfusco/32/9213_2.png) [@cfusco](https://community.ipfire.org/u/cfusco)\
**Post date:** [18 July 2023 12:31 UTC](https://community.ipfire.org/t/initial-wiki-page-for-ebtables/10067/1 "2023-07-18T12:31:36Z")

</div>

> [@Configure DHCP Snooping](https://community.ipfire.org/t/configure-dhcp-snooping/10063/8):
>
> It would be great if it was described in the wiki or implemented in a ipfire…

I asked GPT4 to [write an initial page for the package](https://chat.openai.com/share/9fa1c7bd-6baa-4f21-b9e1-70025954d1dd). This is a preliminary version.

Please if/when you learn how to use the tool, come back to this thread and suggest or implement modifications to the text so we can incorporate it in the wiki. Actually, can someone with the ability to do so (@jon maybe) move this message to a properly titled, separate thread?

# ebtables - IPFire Plugin

ebtables is a useful tool for network administrators, serving as an Ethernet bridge frame table administration tool. This IPFire plugin provides a straightforward method of managing and controlling the network traffic at the link layer (Layer 2) of the OSI model.

## Functionality

ebtables operates by inspecting Ethernet frames as they pass through your Linux bridge, enabling you to define what type of traffic is permitted or forbidden based on MAC addresses and Ethernet frame fields.

This tool allows for the application of filter rules, offering functionality similar to iptables, but operating at a lower level in the network stack. While iptables operates at the Network Layer (Layer 3), ebtables operates at the Data Link Layer (Layer 2), enabling a more granular level of traffic control.

## Use Cases

There are various applications where ebtables proves to be useful:

- **MAC Address Filtering:** By using ebtables, it is possible to filter traffic based on the MAC address of the sender or receiver. This can be particularly helpful for ensuring specific devices have (or do not have) network access.

- **Virtual LAN (VLAN) Tagging:** ebtables can be used to allow or block specific VLANs, providing control over which frames are allowed to pass through certain ports.

- **Bridge Loop Prevention:** In some instances, network bridges can cause loops, which create broadcast storms that slow the network. ebtables can be used to prevent this issue by blocking specific MAC addresses from communicating.

- **Traffic Control Between Virtual Machines:** When using virtual machines, ebtables can be used to filter traffic between different VMs based on their MAC addresses.

## Example Configuration

Below is a basic example of how to utilize ebtables:

```bash
# Drop all traffic from MAC address 00:00:00:00:00:01
ebtables -A FORWARD -s 00:00:00:00:00:01 -j DROP
```

---

<div class="post-metadata">

**Author:** ![huisco](https://community.ipfire.org/user_avatar/community.ipfire.org/huisco/32/8488_2.png) [@huisco](https://community.ipfire.org/u/huisco)\
**Post date:** [18 July 2023 12:43 UTC](https://community.ipfire.org/t/initial-wiki-page-for-ebtables/10067/2 "2023-07-18T12:43:24Z")

</div>

> [@cfusco](#):
>
> Actually, can someone with the ability to do so (@jon maybe) move this message to a properly titled, separate thread?

Thank you, I do not know how better)… can put this message in a separate thread, if someone else is interested in it, except me)))

---

<div class="post-metadata">

**Author:** ![cfusco](https://community.ipfire.org/user_avatar/community.ipfire.org/cfusco/32/9213_2.png) [@cfusco](https://community.ipfire.org/u/cfusco)\
**Post date:** [18 July 2023 14:22 UTC](https://community.ipfire.org/t/initial-wiki-page-for-ebtables/10067/3 "2023-07-18T14:22:12Z")

</div>

And this is Claude version of the page, using the same prompt.

# ebtables

‘‘ebtables’’ is a Linux kernel module that provides Ethernet bridging frame filtering capabilities. It operates at layer 2 of the [OSI model - Wikipedia](https://en.wikipedia.org/wiki/OSI_model) allowing filtering rules to be applied to Ethernet frames passing through a Linux bridging firewall.

## Usage

ebtables allows defining filtering rules that get applied to frames passing through a bridge interface. Common uses include:

- Blocking or allowing frames based on layer 2 header fields like source/destination MAC address, VLAN ID, etc.
- Filtering based on layer 3 protocol information.
- Limiting ARP broadcasts.

Rules get defined in an ebtables chain, which is then referenced from a bridging hook point.

## Example rules

```auto
# Block all frames with a source MAC of 00:11:22:33:44:55 on the input interface (replace with your actual interface)
ebtables -A INPUT -i green0 -s 00:11:22:33:44:55 -j DROP

# Allow only VLAN 100 on the bridge interface (replace with your actual bridge interface)
ebtables -A FORWARD -i br0 --vlan-id 100 -j ACCEPT
ebtables -A FORWARD -i br0 -j DROP

## Limit ARP broadcasts on the internal (GREEN) interface, only allowing ARP requests and replies, 
## and dropping all other types of ARP packets.
ebtables -A FORWARD -i green0 -p ARP --arp-opcode Request -j ACCEPT 
ebtables -A FORWARD -i green0 -p ARP --arp-opcode Reply -j ACCEPT
ebtables -A FORWARD -i green0 -p ARP -j DROP

```

## References

- [https://ebtables.netfilter.org/](https://ebtables.netfilter.org/)
- [https://linux.die.net/man/8/ebtables](https://linux.die.net/man/8/ebtables)

---

<div class="post-metadata">

**Author:** ![jon](https://community.ipfire.org/user_avatar/community.ipfire.org/jon/32/15363_2.png) [@jon](https://community.ipfire.org/u/jon)\
**Post date:** [18 July 2023 14:23 UTC](https://community.ipfire.org/t/initial-wiki-page-for-ebtables/10067/4 "2023-07-18T14:23:21Z")

</div>

I created a blank page…

> **[ebtables - The IPFire Wiki](https://wiki.ipfire.org/addons/ebtables)**

---

<div class="post-metadata">

**Author:** ![cfusco](https://community.ipfire.org/user_avatar/community.ipfire.org/cfusco/32/9213_2.png) [@cfusco](https://community.ipfire.org/u/cfusco)\
**Post date:** [18 July 2023 17:39 UTC](https://community.ipfire.org/t/initial-wiki-page-for-ebtables/10067/5 "2023-07-18T17:39:46Z")

</div>

This is the content I propose to add to the wiki stub prepared by @jon . I read the documentation and merged few sentences inspired by the official website with the text produced by both the AI models.

@jon @bonnietwin @bbitsch What do you think? Should I remove the deeper explanation of the layer two vs layer 3 (brouting) part of the text?

+++ text starts here +++

## Package description

ebtables is a transparent network-traffic filtering tool for Linux-based systems functioning as bridges of two or more networks.

Primarily, ebtables operates at the Data Link Layer (Layer 2 bridging) of the OSI model, which is a standardized framework that describes how network protocols communicate and interact. At this level, ebtables primarily inspects and takes actions based on MAC addresses, which are unique identifiers assigned to each network device. While the primary function of ebtables is to filter based on the layer 2 information, it can also inspect the IP packet within the Ethernet frame payload, enabling it to perform certain Layer 3 operations.

Let’s consider an Ethernet frame as an example:

```auto
|-----------------------------------------------------------------------------------|
| Ethernet Frame |
|-----------------------------------------------------------------------------------|
| Preamble | SFD | Destination MAC | Source MAC | Type | Payload | Frame Check |
| 7 bytes | 1 byte | 6 bytes | 6 bytes | 2 bytes | 46-1500 bytes | 4 bytes |
|-----------------------------------------------------------------------------------|

```

The ‘Payload’ of the Ethernet frame carries an IP packet:

```auto
|---------------------------------------------------------------------------|
| IP Packet (Ethernet Frame Payload) |
|---------------------------------------------------------------------------|
| Version | IHL | TOS | Total Length | ID | Flags | Frag Offset | TTL |
| 4 bits | 4 bits | 8 bits | 16 bits | 16 bits | 3 bits | 13 bits | 8 bits |
|---------------------------------------------------------------------------|
| Protocol | Header Checksum | Source IP Address | Destination IP Address |
| 8 bits | 16 bits | 32 bits | 32 bits |
|---------------------------------------------------------------------------|
| Options (if IHL > 5) | Padding | Data |
| Variable | Variable | Up to 65535 bytes (usually less) |
|---------------------------------------------------------------------------|

```

The IP packet includes both the ‘Source IP Address’ and ‘Destination IP Address’ among other information which can all be used by ebtales.

Beyond filtering, ebtables offers advanced logging to monitor network activity, the ability to modify MAC addresses in data traffic (a process known as MAC DNAT/SNAT), and ‘brouter’ capabilities, enabling the system to operate both as a bridge and a router.

One of the key advantages of ebtables is its ability to integrate with other Linux filtering tools including iptables, ip6tables, and arptables. This allows the realization of a comprehensive firewall that filters network traffic at multiple OSI model layers.

The ebtables and arptables tools are maintained by the same developers who contribute to the netfilter project, the same framework that facilitates network traffic filtering used by IPFire. They continue to ensure these tools are updated and effective. The original website remains primarily for documentation reference purposes (see references).

## Usage

ebtables allows defining filtering rules that get applied to frames passing through a bridge interface.

As for iptables, in the Linux kernel ebtables uses tables (in this case they are three) that contain built-in chains for organizing its rules. These tables allow us to separate the functionality into different groups of rules.

1. A ‘chain’ is just a set of rules arranged in a specific order. Each rule in the chain checks if it matches a particular Ethernet frame (a unit of data sent over a network).
2. If a rule matches the frame, it then uses a ‘target’, or an instruction, to determine what to do with that frame (i.e. ACCEPT, DROP, CONTINUE, RETURN).
3. If a rule does not match the frame, the system moves on to the next rule in the chain, and so on, until a match is found or all rules have been checked.

For better performance and organization, users can create their own custom chains.

## Example rules

```auto
# Block all frames with a source MAC of 00:11:22:33:44:55 on the input interface (replace with your actual interface)
ebtables -A INPUT -i green0 -s 00:11:22:33:44:55 -j DROP

# Allow only VLAN 100 on the bridge interface (replace with your actual bridge interface)
ebtables -A FORWARD -i br0 --vlan-id 100 -j ACCEPT
ebtables -A FORWARD -i br0 -j DROP

## Limit ARP broadcasts on the internal (GREEN) interface, only allowing ARP requests and replies, 
## and dropping all other types of ARP packets.
ebtables -A FORWARD -i green0 -p ARP --arp-opcode Request -j ACCEPT 
ebtables -A FORWARD -i green0 -p ARP --arp-opcode Reply -j ACCEPT
ebtables -A FORWARD -i green0 -p ARP -j DROP

```

## References

- [https://ebtables.netfilter.org/](https://ebtables.netfilter.org/)
- [https://linux.die.net/man/8/ebtables](https://linux.die.net/man/8/ebtables)

## Acknowledgments

This page was created with the assistance of OpenAI’s ChatGPT-4, a language model developed by OpenAI, and Claude, a language model developed by Anthropic.

---

<div class="post-metadata">

**Author:** ![huisco](https://community.ipfire.org/user_avatar/community.ipfire.org/huisco/32/8488_2.png) [@huisco](https://community.ipfire.org/u/huisco)\
**Post date:** [18 July 2023 18:44 UTC](https://community.ipfire.org/t/initial-wiki-page-for-ebtables/10067/6 "2023-07-18T18:44:13Z")

</div>

As far as I understand, the full implementation of DHCP snooping is made in the **ebtables version v2.0.10-5**.

The latest version as I understand it **ebtables 2.0.11 - 2019-12-02 16:31**. Ipfire contains a very old version of the package **ebtables v2.0.10-4 (December 2011)**

[https://www.netfilter.org/pub/ebtables/](https://netfilter.org)

Maybe still delete this package and use **arptables + iptables**?

for example something like that:

1. Create an iptables rule to block unwanted DHCP traffic:

```auto
arptables -A INPUT --opcode Request --in-interface eth0 -j DROP

```

1. Create an iptables rule to allow only trusted DHCP traffic:

```auto
iptables -A INPUT -p udp --dport 67:68 --in-interface eth0 -j ACCEPT

```

1. Disable all other DHCP packets using iptables rules:

```auto
iptables -A INPUT -p udp --dport 67:68 -j DROP

```

1. Save the iptables and iptables rules so that they load when the system restarts:

```auto
arptables-save > /etc/arptables.conf
iptables-save > /etc/iptables/rules.v4

```

1. Make sure that the iptables and iptables rules are loaded at system startup. To do this, add the following lines to the /etc/rc.local file (if a SysV initialized system is used):

```auto
/sbin/arptables-restore < /etc/arptables.conf
/sbin/iptables-restore < /etc/iptables/rules.v4

```

If you are using a system with systemd, create a new unit file, for example /etc/systemd/system/iptables.service, with the following contents:

```auto
[Unit]
Description=Arptables Firewall Rules
After=network.target

[Service]
Type=oneshot
ExecStart=/sbin/arptables-restore < /etc/arptables.conf
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

```

and

```auto
systemctl enable arptables.service
systemctl start arptables.service

```

---

<div class="post-metadata">

**Author:** ![bonnietwin](https://community.ipfire.org/user_avatar/community.ipfire.org/bonnietwin/32/12350_2.png) [@bonnietwin](https://community.ipfire.org/u/bonnietwin)\
**Post date:** [18 July 2023 19:13 UTC](https://community.ipfire.org/t/initial-wiki-page-for-ebtables/10067/7 "2023-07-18T19:13:47Z")

</div>

ebtables-2.0.11 has just finished building on my system and will be submitted into the ipfire dev mailing list and patchwork later this evening.

It should end up in Core Update 177.

---

<div class="post-metadata">

**Author:** ![jon](https://community.ipfire.org/user_avatar/community.ipfire.org/jon/32/15363_2.png) [@jon](https://community.ipfire.org/u/jon)\
**Post date:** [18 July 2023 19:44 UTC](https://community.ipfire.org/t/initial-wiki-page-for-ebtables/10067/8 "2023-07-18T19:44:44Z")

</div>

> [@cfusco](#):
>
> Should I remove the deeper explanation

I suggest “yes”. It should be enough info to give people an idea of what ebtables is. And then let them dig for the deeper explanation on **Link** ed pages.

I’d mention briefly ebtables does this Layer and iptables does that Layer. and then link to the in-depth.

---

<div class="post-metadata">

**Author:** ![icke](https://community.ipfire.org/user_avatar/community.ipfire.org/icke/32/8248_2.png) [@icke](https://community.ipfire.org/u/icke)\
**Post date:** [22 August 2023 16:13 UTC](https://community.ipfire.org/t/initial-wiki-page-for-ebtables/10067/9 "2023-08-22T16:13:26Z")

</div>

Hi,

i use Core Update 178 and still ebtables v2.0.10-4 (December 2011) addon is available.  
When does v2.0.11 come?

And where is the default ebtables.conf location on IpFire? Currently i use /etc/ebtables.conf. Saving does work but restore not.

The Fire throws the message:

1. Multiple ebtables programs were executing simultaneously. The ebtables  
userspace tool doesn’t by default support multiple ebtables programs running  
concurrently. The ebtables option --concurrent or a tool like flock can be  
used to support concurrent scripts that update the ebtables kernel tables.
2. The kernel doesn’t support a certain ebtables extension, consider  
recompiling your kernel or insmod the extension.

even with --concurrent toggle no way to load the tables.

Best Regards  
Daniel

---

<div class="post-metadata">

**Author:** ![jon](https://community.ipfire.org/user_avatar/community.ipfire.org/jon/32/15363_2.png) [@jon](https://community.ipfire.org/u/jon)\
**Post date:** [22 August 2023 16:20 UTC](https://community.ipfire.org/t/initial-wiki-page-for-ebtables/10067/10 "2023-08-22T16:20:13Z")

</div>

> [@icke](#):
>
> When does v2.0.11 come?

I see it in CU 179 (testing):

 ![Screen Shot 2023-08-22 at 11.19.26 AM](https://community.ipfire.org/uploads/default/original/2X/7/79568154f795eb4d880b8d6cca71fa6227374916.png)

---

<div class="post-metadata">

**Author:** ![icke](https://community.ipfire.org/user_avatar/community.ipfire.org/icke/32/8248_2.png) [@icke](https://community.ipfire.org/u/icke)\
**Post date:** [22 August 2023 16:22 UTC](https://community.ipfire.org/t/initial-wiki-page-for-ebtables/10067/11 "2023-08-22T16:22:20Z")

</div>

Ah thx. Is is it a problem to load it from testing an switch pack to stable?

---

<div class="post-metadata">

**Author:** ![jon](https://community.ipfire.org/user_avatar/community.ipfire.org/jon/32/15363_2.png) [@jon](https://community.ipfire.org/u/jon)\
**Post date:** [22 August 2023 16:25 UTC](https://community.ipfire.org/t/initial-wiki-page-for-ebtables/10067/12 "2023-08-22T16:25:45Z")

</div>

To me it is not difficult. Please remember you are loading up a testing branch and things may or may not work. I usually test on a separated IPFire box and not on my Production ipfire box.

> **[How to change Branches (stable, testing, unstable) - The IPFire Wiki](https://wiki.ipfire.org/configuration/ipfire/pakfire/testing)**

---

<div class="post-metadata">

**Author:** ![icke](https://community.ipfire.org/user_avatar/community.ipfire.org/icke/32/8248_2.png) [@icke](https://community.ipfire.org/u/icke)\
**Post date:** [22 August 2023 16:28 UTC](https://community.ipfire.org/t/initial-wiki-page-for-ebtables/10067/13 "2023-08-22T16:28:24Z")

</div>

yeah, i see, was a silly question from me. Forgot the Branches. I will set up a Test VM and use the testing Branch there.

Thank you Jon.

---

<div class="post-metadata">

**Author:** ![bonnietwin](https://community.ipfire.org/user_avatar/community.ipfire.org/bonnietwin/32/12350_2.png) [@bonnietwin](https://community.ipfire.org/u/bonnietwin)\
**Post date:** [22 August 2023 21:09 UTC](https://community.ipfire.org/t/initial-wiki-page-for-ebtables/10067/14 "2023-08-22T21:09:28Z")

</div>

> [@icke](#):
>
> And where is the default ebtables.conf location on IpFire? Currently i use /etc/ebtables.conf.

As far as I can see there is no ebtables.conf. It is not mentioned at all in the ebtables man page nor in the ebtables documentation.

There was no ebtables.conf in version 2.0.10 and that is the same for version 2.0.11

> [@icke](#):
>
> Saving does work but restore not.

The execute, save and restore commands for version 2.0.10 were

```auto
usr/sbin/ebtables
usr/sbin/ebtables-restore
usr/sbin/ebtables-save

```

In version 2.0.11 these are changed to

```auto
usr/sbin/ebtables-legacy
usr/sbin/ebtables-legacy-restore
usr/sbin/ebtables-legacy-save

```

This is because this addon package is now the legacy version. The main version is integrated into iptables as ebtables-nft but that is probably not installed because the configure is done with `--disable-nftables` as IPFire2.x works with iptables and not with nftables.

[http://git.netfilter.org/ebtables/commit/?h=ebtables-2.0.11&id=826faffa38de8ce55bb32cd1549fb732229fd80f](http://git.netfilter.org/ebtables/commit/?h=ebtables-2.0.11&id=826faffa38de8ce55bb32cd1549fb732229fd80f)

I have found the following man pages for ebtables-save-legacy and ebtables-restore-legacy  
[https://manpages.ubuntu.com/manpages/lunar/en/man8/ebtables-legacy-save.8.html](https://manpages.ubuntu.com/manpages/lunar/en/man8/ebtables-legacy-save.8.html)  
[https://manpages.ubuntu.com/manpages/lunar/en/man8/ebtables-legacy-restore.8.html](https://manpages.ubuntu.com/manpages/lunar/en/man8/ebtables-legacy-restore.8.html)