Setting up a Bridge - Multiple NICs to act like a switch, like a SOHO router

[Ricardo]

Hmm, looks like the lan_bridge.rst file is not hooked up to a parent page so it's not showing up on https://docs.opnsense.org/


Cheers,
Franco

Indeed! This topic cant be located on the docs page.

[marjohn56]

Why, you followed it and it worked. 

[Ricardo]

Hmm, not the most customer-centric approach 

Let me explain:

- the 2 tunables are not described at all, what do these change in practicality? What happens in this network topology, if neither of them is changed from their defaults?
- what exact scenario this howto is supposed to solve, is quite unclear. Same as the transparent filtering bridge howto, that tries to accomplish a different type of network architecture, but also not described very precisely (at least a drawing showing the Layer2 / Layer3 would help understanding how that topology should work). It assumes the person reading the howto has the networking knowledge comparable to a CCNP. At least the following introduction should be added in this example:

----------------------------
By default, Opnsense interfaces are configured as Layer-3 interface. That means each physical interface segments the network into different broadcast domains, all using its unique L3 IP addressing scheme. However, if there is a specific need, it is possible to configure some physical interfaces into a Layer-2 mode, similar to L2 switchports, thanks to the virtual software-based interface type "bridge". Members of such bridge interface group behave like ports of a standard L2 switch in the same broadcast domain. This topology is recommended only in the following cases:
- if there is no standalone L2 switch in the network, while Opnsense box has plenty of available physical interfaces, and the number of connecting endpoints is minimal, or
- if the corresponding L2/L3 switch lacks any available ports.

Performance note: in contrast with a true L2 switch -where packet forwarding is done at hardware ASIC level without stressing the switch main CPU- a virtual software-based bridge sends all traffic of bridge member interfaces through the Opnsense CPU. This is true, regardless if the traffic is between two endpoints where the Opnsense box is normally not involved. As a result, even traffic that should normally not be processed or seen by Opnsense itself, still puts significant processing load on its CPU, and reduces the available resources to handle normal workloads.
---------------------

How does this sound?

[marjohn56]

99% of that is irrelevant to most users, they do not care about layer 2, layer 3 or the layers of a cake, they  just want it to work with simple straight forward instructions, that's a how-to... not a why's and wherefore and a discussion on networking principles.


However there is nothing preventing you from writing in depth explanations if you feel the need and presenting them for inclusion in the wiki; frankly I don't have time to spare at the moment.

[Ricardo]

99% of that is irrelevant to most users, they do not care about layer 2, layer 3 or the layers of a cake, they  just want it to work with simple straight forward instructions, that's a how-to... not a why's and wherefore and a discussion on networking principles.


However there is nothing preventing you from writing in depth explanations if you feel the need and presenting them for inclusion in the wiki; frankly I don't have time to spare at the moment.

As I have already typed the text here, would not be impossible to make it part of the wiki :-)

[marjohn56]

Stop giving me work... I have enough to do.

[Ricardo]

You misunderstand me, I wanted to add this myself, as soon as I get to know how exactly this works.

[marjohn56]

Create a Github account.


Fork the Opnsense repo, in this case 'docs'  to your own account.


If you are using windows it's very easy, you install github desktop and then in your repo you clone the repo selecting 'Open in Desktop', that brings a copy to your PC. You then create a branch for your changes, make the changes and commit, push the branch to your Github repo and then back in Github you go to your commit and issue a Pull Request.


Franco or Ad then look at it and ask you to make changes. 

[Ricardo]

Sounds reasonable/doable. My 1st github experience.

[Saembak1995]

Answering the OP's question:

To bridge 2 NICs you have to define an interface for each NIC, for example NIC2 and NIC3.
สมัครสมาชิก12BET

I found that you can have mixes of IP v4 configurations: NIC2 with a fixed address and NIC3 with "None", or both NICs with a fixed address.

As Franco warned, when you assign a fixed address to both, you can also tell DHCP to listen to both interfaces and it can issue leases on both interfaces.

However... here I was surprised... it only reports the leases on ONE of the interfaces.

[baz]

This is true, regardless if the traffic is between two endpoints where the Opnsense box is normally not involved.

Hello, I am relatively new to all this. What is a situation where traffic between two endpoints does not involve opnsense? Don't the firewall rules at minimum always have to be verified? Excuse me if this is a dumb question.

[marjohn56]

In this 'bridge' context, all clients are on the same LAN segment, this traffic between two clients   say 192.168.1.10 and 192.168.1.11 would go point to point.  For example if the clients were connected directly, one to each of the bridge ports, then although the traffic would pass through the opensense router NICs, no firewall rules would be in play as they are both on the same LAN, it's effectivelly the same as if they were connected by a simple switch, one port to each of the clients and one port to opensense.

[dogg94]

Success.  For anyone interested I found some directions and they worked perfectly.  This post is coming from a bridged 10G X2 plus 1G LAN network.

Credist go to https://forum.pfsense.org/index.php?topic=48947.0

This is the instructions and are designed for pfSense but work with a few differences in spots of where the tunables are etc.

1. Assign your additional interfaces and enable them with type 'none'. They will come up as OPT1, OPT2 etc.
2. Switch bridge filtering from the bridge members onto the bridge itself (assuming you don't need to apply firewall rules between devices on the bridge/switch). Go to System: Advanced: System Tunables: and edit the two values.
Change net.link.bridge.pfil_member to 0.
Change net.link.bridge.pfil_bridge to 1.
Apply these changes.
3. Now create a bridge in Interfaces: (assign): Bridges: and add to it the additional interfaces you just created, you can select multiple interfaces by holding Ctrl. I named the bridge 'Switch Configuration' to remind me how I have configured it.
4. Now go to Interfaces: (assign) and change the LAN assignment to bridge0. Save and reconnect your ethernet cable to one of the bridge interfaces. It should come back up, however you will want to make sure you have console access before you do this as if you've done something different you could end up locked out! 
5. Assign the interface that was originally assigned to LAN and enable it with type 'none'. Add it to bridge0 to include it in the 'switch'.

After step 3/4 are done REBOOT.  The bridge should be working.

I love you...I know this may be necrod but this solved my issue.  I've been pulling my hair out trying to figure out why wifi worked but ethernet didn't.  I have an ap connected to my homebrew 'bridge switch'.  Changing the two settings in tunables fixed this for me.

[Patrick M. Hausen]

This is exactly what is in the OPNsense documentstion, so really, what's the fuzz about?

https://docs.opnsense.org/manual/how-tos/lan_bridge.html