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
* 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
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 !220.127.116.11/30 to any
where 18.104.22.168/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 22.214.171.124/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 126.96.36.199/1.
@10 block in log quick on rl1 from !0.0.0.0/1 to any
Note that 188.8.131.52 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
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.