According to my tests, (non-filtered) bridging in v1.2b3 between to 
Realtek RTL8139D NICs appears to work fine, even though the bridge man 
page of FreeBSD 4.10 does not list the rl driver as supported for briding.

My configuration, as recommended earlier by Bruce A. Mah:
* LAN (fxp0) configured with a private class-C address, used only for 
admin purposes;
* WAN (rl0) configured with a "dummy" address (see 1. below for details);
* OPT1 (rl1) bridged to WAN (rl0), without any IP address assigned.


After having verified that basic bridging (without filtering) works, I 
am now attempting to get "filtered bridging" working. So far I 
encountered two problems after checking the corresponding option in the 
advanced menu:

1. In the filter's log I found that OPT1 was blocking all incoming 
packets, despite having defined ingress rules of type "pass any:any to 
any:any" for both OPT1 and WAN interfaces. I observe that WAN accepts 
all incoming packets and the (stateful) firewall also let pass any 
replies from OPT1 back to the WAN interface. However, packets initiated 
by hosts on the OPT1 interface are blocked depite the rule that should 
let pass them.

Looking at the output of "ipfstat -nio" in status.php I found the rule
   @10 block in log quick on rl1 from !3.3.3.3/30 to any

where 3.3.3.3/30 corresponds to the IP address I assigned to the WAN 
(rl0) interface. This rule effectively blocks any ingress traffic on 
OPT1 (rl1) - unless it comes from the "dummy" subnet 3.3.3.3/30.

In an attempt to alleviate the impact of this restrictive rule, I 
increased the subnet to its maximum, e.g. set the subnet mask of the WAN 
(rl0) interface to 3.3.3.3/1.

   @10 block in log quick on rl1 from !0.0.0.0/1 to any

Note that 3.3.3.3 get rewritten as 0.0.0.0, which makes sense. Is there 
any workaround to end up rather with an auto generated rule 0.0.0.0/0 
which is really all inclusive?


2. I found that after toggling the "filtered bridging" option in the 
advanced menu a restart is required in order to make sure this change 
takes effect.

I am unsure yet if this is related to some aging of ARP and firewall 
state information, and could simply be achieved by using the "Reset 
state" function in the Diagnostics menu.

Thanks for any feedback and suggestions.

Regards,
Rolf