@johnpoz : Linksys EA7300 - You said it would work, but it doesn't!!! 😆 🤣

Not listed as supported on the DD-WRT web site. 😞

But it is supported on OpenWRT with vLan! Yay!

So, cool beans! I can (probably) take it from here.
Thanks for your, and everyone's, help!!!

@oktech Vielleicht musst du PPPoE auf dem VLAN machen?

(bump) Someone?

Auch der Reboot löst das Problem mit der fehlenden IPv6 auf LAN nicht immer. Da bleibt wirklich nur auf 2.5 zu hoffen. I am ready! 🤞

Bridging VLANs like that is generally not recommended.

How many internal interfaces do you need configured like that?

If it's just one you could try breaking the ix2-3 lagg and reconfiguring the switch to connect Eth8 to ix2 directly and bridge that. Removing the VLAN will probably prevent the loss there.
Make sure you have some access to the firewall other than via the switched ports if you try that as it's very easy to get locked out!

Do you need to filter traffic across the bridge? If not you would be better off using an external switch to set that up.

@stephenw10
Thank Steve for your reply.
Switch 2 was connected to igb2 and was not communicating.
DHCP works correctly for both vlan1 and vlan67 on Switch 1, which connects to igb1.

I had added rules to both LAN (bridge0) and WiredLAN2 (igb2) to log any rejected events but there were nothing when Switch 2 was plugged in/out igb2.

Worst still, I started to observe about 0.5% errors out in LAN interface even with igb2 open. Snort was not reporting anything on LAN under the bridge config. These 2 factors are enough for me to pull back from this bridged config.

Thanks again for your advice anyway.

@kiokoman thanks for the tip, I have configured a bridge with linux tools (brctl) and I'm using virt-io and I thought that would be enough but it is in fact very reasonable that it would actually introduce limitations and weird behaviors like what I'm seeing, I will dig further the issue

I take it these .2 are vips you have setup.

What is the source of this traffic? Is it rfc1918 in your network - or public being forwarded to pfsense rfc1918 wan IP? Why do you think you want to do this? What do think it will accomplish exactly?

But sure you could outbound nat into your lan from your lan vip.

Dick? Really? Calling you out on calling yourself a ccie when clearly everyone knows that is not even close to true is not being a dick... That is just calling someone out on their BS!

So what was the problem, only tcp for the rule? Wrong source?
Maybe you had policy route on the rule? But that wouldn't of stopped ping to pfsense IP? Only ping to other lan.. That is another common mistake.

@JeGr gerne. Dafür habe ich das Posting ja gemacht das man aktuelle Informationen findet.

I figured it out, I forgot some settings elsewhere

A bridge is nothing more than a switch... If you need more ports on a L2, use a switch..

How about some details of what your trying to do exactly. What is this device/thing/whatever your trying to connect to a network? And what are the details of the network you want to connect to.

Is wireless involved? I can tell you most of the time - bridging would not be the right solution ;) Unless you are talking about bridging a wireless to wired??

Nobody can help you make a decision or even explain why you would want to do XYZ vs ABC without some details!

Create a LAGG on pfsense and on the switch stack. Use the LAGG as the vlan parent.

@xandercdn I have this working in my lab.

"net.link.bridge.pfil_member=1" and "net.link.bridge.pfil_bridge=0" under system tunables. Outgoing NAT is disabled WAN has an IP address for management WAN and LAN are joined in BRIDGE0 I do not have the bridge assigned under "Interface Assignments" I configured 10 Mbit/s in and out limiters using this example. I did not create the first two floating rules for ICMP since NAT is not involved in this config. If you want the limiter to only apply to a certain IP(s) you can change the source and destinations accordingly.
0_1543886890032_firewall_rules.jpg

I've attached the configuration I'm using:
0_1543886724746_config-dev-244p1.localdomain-20181203172356.xml

Appologies on the delay getting back to you on this, been a bit busy with things.

So I've done a lot more digging and it seems that traffic is going out, back into the pfsense box but doesn't seem to get back to my VM and I'm honestly out of my depth trying to work out why.

So relevant info is below, 10.0.10.254 is the external gateway and does DHCP, so my VM 10.0.10.121 gets it's IP from our office router ok but pings and normal internet traffic fails. It would appear that the WAN interface is getting the ping reply but it's not going across to the statics or the bridge interface and I cant work out why

pfTop: Up State 1-17/17, View: default, Order: bytes PR DIR SRC DEST STATE AGE EXP PKTS BYTES icmp Out 10.0.10.121:32235 10.0.10.254:32235 0:0 00:07:06 00:00:09 1643 46004 icmp Out 10.0.10.121:55748 10.0.10.254:55748 0:0 00:07:03 00:00:09 1640 45920

Packet Capture WAN:
11:40:12.494284 IP 10.0.10.121 > 10.0.10.254: ICMP echo request, id 32235, seq 1242, length 8
11:40:12.494450 IP 10.0.10.121 > 10.0.10.254: ICMP echo request, id 55748, seq 1238, length 8
11:40:12.509484 IP 10.0.10.254 > 10.0.10.121: ICMP echo reply, id 32235, seq 1242, length 8
11:40:12.510505 IP 10.0.10.254 > 10.0.10.121: ICMP echo reply, id 55748, seq 1238, length 8
11:40:13.651769 ARP, Request who-has 10.0.10.254 tell 10.0.10.124, length 46

Packet Capture Bridge:
11:48:49.284145 ARP, Request who-has 10.0.10.254 tell 10.0.10.124, length 46
11:48:50.307864 ARP, Request who-has 10.0.10.254 tell 10.0.10.124, length 46
11:48:51.331496 ARP, Request who-has 10.0.10.254 tell 10.0.10.124, length 46

Packet Capture Statics:
11:50:30.660879 ARP, Request who-has 10.0.10.254 tell 10.0.10.124, length 46
11:50:31.688384 ARP, Request who-has 10.0.10.254 tell 10.0.10.124, length 46
11:50:32.709554 ARP, Request who-has 10.0.10.254 tell 10.0.10.124, length 46
11:50:33.733321 ARP, Request who-has 10.0.10.254 tell 10.0.10.124, length 46
11:50:34.757094 ARP, Request who-has 10.0.10.254 tell 10.0.10.124, length 46

VM tcp dump for icmp:
0_1538651044673_tcpdump icmp.png

I am i right in thinking that incoming flow from WAN to the Statics is what's failing? Are there other diagnostic steps I can take to work this out?

I'll keep trying this afternoon to see if i can get anywhere.

Thanks

@jknott said in Hardware switch or NIC brridge?:

There used to be some cut through switches, that would start switching as soon as it learned the destination MAC, but those have disappeared

And there still are, the cisco nexus 5000 line did/does it... The 9000 series nexus I believe default to cut through but can be put in store and forward, etc.

So disappeared is not true... But cut through was never in the soho or budget lines of any switch maker..