Interfaces em ponte são diferentes das interfaces normais em alguns aspectos, portanto, há alguns recursos que são incompatíveis com a ponte e outros em que considerações adicionais devem ser feitas para acomodar a ponte. Esta seção aborda recursos que funcionam de maneira diferente com a ponte do que com interfaces sem ponte.
O portal cativo não é compatível com bridging transparente, pois requer um IP na interface sendo bridged, usado para servir o conteúdo do portal, e esse IP deve ser o gateway para os clientes. Isso significa que não é possível, por exemplo, interligar LAN e WAN e esperar capturar clientes com o portal.
Isso pode funcionar ao interligar várias interfaces locais a todas as rotas através do pfSense (por exemplo, LAN1, LAN2, LAN3, etc.). Ele funcionará se a interface de ponte for designada, a interface de ponte tiver um endereço IP e esse endereço IP for usado como o gateway pelos clientes na ponte. Consulte [Atribuições da Interface de Troca]()https://strn.com.br/pfsense/bridging/bridging-and-interfaces/#label-bridging-swap-assignment para um procedimento para colocar o endereço IP em uma interface de ponte designada.
A alta disponibilidade não é recomendada com o bridging no momento. Alguns obtiveram sucesso misturado ao combinar os dois no passado, mas deve-se tomar muito cuidado para lidar com loops de camada 2, que são inevitáveis em um cenário de ponte HA +. Quando dois segmentos de rede são interligados, eles são realmente mesclados em uma rede maior, como discutido anteriormente neste capítulo. Quando HA é adicionado ao mix, isso significa que haverá dois caminhos entre os switches para cada respectiva interface, criando um loop.
Os switches gerenciados podem lidar com isso com o STP (Spanning Tree Protocol), mas os switches não gerenciados não têm defesas contra o loop. Se não for controlada, um loop trará uma rede a seus joelhos e impossibilitará a transmissão de tráfego. O STP pode ser configurado em pontes para ajudar, embora ainda possa haver resultados inesperados.
A ponte transparente, por sua natureza, é incompatível com a multi-WAN em muitos de seus usos. Ao usar bridging entre uma interface WAN e LAN/OPT, geralmente algo diferente de pfSense será o gateway padrão para os hosts na interface em ponte, e esse roteador é o único dispositivo que pode direcionar o tráfego desses hosts. Isso não impede que a multi-WAN seja usada com outras interfaces no mesmo firewall que não são interligadas, só afeta os hosts em interfaces em ponte, onde eles usam algo diferente de pfSense como seu gateway padrão. Se várias interfaces internas forem unidas em ponte e o pfSense for o gateway padrão para os hosts nas interfaces em ponte, a multi-WAN poderá ser usada da mesma forma que as interfaces sem ponte.
Para que os limitadores funcionem com bridging, a ponte em si deve ser atribuída e a interface da ponte deve ter o endereço IP e não uma interface de membro.
Para encaminhamentos de porta em LAN, ou proxies transparentes que usam porta encaminhada em LAN para capturar tráfego, para funcionar em um cenário de ponte, a situação é a mesma que Captive Portal: Ele funcionará somente para pontes de rede local e não para pontes WAN / LAN, O endereço IP deve estar na interface da ponte designada e esse endereço IP deve ser usado como o gateway para os clientes locais.
Isso significa que um pacote como o Squid não pode funcionar em um cenário de firewall transparente em que a LAN é conectada a uma WAN.