<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[pfSense its strange &#x27;layered bridges&#x27; (and their behavoir)]]></title><description><![CDATA[<p dir="auto">For some VLAN's which do not need high performance I use pfsense its internal bridge option.</p>
<p dir="auto">The bridges are used to make the vlan's available in two physical different networks.</p>
<p dir="auto">For info I have two more or less separated networks for two reasons:</p>
<ul>
<li>for redundancy, if one network fails, I can still use the other one</li>
<li>one is a 10G network the other one a 2.5G / 1G network</li>
</ul>
<p dir="auto">For that reason, for instance the management vlan is connected to both networks where each network is connected with pfSense via a trunk.</p>
<p dir="auto">The intention is of course that the whole thing behaves as one logical vlan.</p>
<p dir="auto">However pfSense its bridge implementation is to say at least(!) weird.</p>
<p dir="auto">Where you would expect that the 'members' to assign to a certain bridge are earlier defined vlan's, in the actual situations  it are 'pfSense interfaces'.</p>
<p dir="auto">This has three very strange complications:</p>
<ul>
<li>you have to define a 'dumy vlan related interface' for each network to tie up to a bridge</li>
<li>than you have to define a 'second layer interface' based on the created bridge</li>
<li>you need to allow the 'network related dummy interfaces to communicate with each other</li>
</ul>
<p dir="auto">Starting with the last point, I did run into that one yesterday,  * without that allow rule:</p>
<ul>
<li>you can reach both networks from some another vlan (if allowed)</li>
<li>and each 'bridge dummy vlan' can reach the internet (if allowed)</li>
<li>however 'dummy vlan1' can not reach 'dummy vlan2'</li>
</ul>
<p dir="auto">Here some pictures to make the situation 'visible'</p>
<p dir="auto"><img src="/assets/uploads/files/1768291987324-08f1dfd4-aebe-411f-b1f9-9f4b89674f42-image.png" alt="08f1dfd4-aebe-411f-b1f9-9f4b89674f42-image.png" class=" img-fluid img-markdown" /></p>
<p dir="auto"><img src="/assets/uploads/files/1768292025936-ac4ff4f1-625b-4e04-8e85-1b6c16cac31f-image.png" alt="ac4ff4f1-625b-4e04-8e85-1b6c16cac31f-image.png" class=" img-fluid img-markdown" /></p>
<p dir="auto"><img src="/assets/uploads/files/1768292175861-9f6360a3-a44b-41b3-926c-f5f9219b9e0e-image.png" alt="9f6360a3-a44b-41b3-926c-f5f9219b9e0e-image.png" class=" img-fluid img-markdown" /></p>
<p dir="auto"><img src="/assets/uploads/files/1768292091220-a24ddb6e-a359-4299-bf57-8a33de9d659a-image.png" alt="a24ddb6e-a359-4299-bf57-8a33de9d659a-image.png" class=" img-fluid img-markdown" /></p>
<p dir="auto">Of course this is not an elegant solution IMHO. The Bridge should tie vlan's together <strong>not</strong> 'pfsense-interfaces'</p>
]]></description><link>https://forum.netgate.com/topic/199811/pfsense-its-strange-layered-bridges-and-their-behavoir</link><generator>RSS for Node</generator><lastBuildDate>Fri, 12 Jun 2026 13:51:39 GMT</lastBuildDate><atom:link href="https://forum.netgate.com/topic/199811.rss" rel="self" type="application/rss+xml"/><pubDate>Tue, 13 Jan 2026 08:17:38 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to pfSense its strange &#x27;layered bridges&#x27; (and their behavoir) on Tue, 13 Jan 2026 11:10:27 GMT]]></title><description><![CDATA[<p dir="auto"><a class="plugin-mentions-user plugin-mentions-a" href="/user/louis2">@<bdi>louis2</bdi></a> Why?</p>
<p dir="auto">Bridges bridge Interfaces.</p>
<p dir="auto">Vlans in pfsense are not interfaces.</p>
<p dir="auto">So yes, it takes a few more steps, but it works.</p>
<p dir="auto">And as a matter of fact is also performant.</p>
<p dir="auto">You can also try vxlan if you wish which is a new feature in pf plus.</p>
]]></description><link>https://forum.netgate.com/post/1235401</link><guid isPermaLink="true">https://forum.netgate.com/post/1235401</guid><dc:creator><![CDATA[netblues]]></dc:creator><pubDate>Tue, 13 Jan 2026 11:10:27 GMT</pubDate></item></channel></rss>