Firewall/NAT

Hi,

so fir the first time I'm trying to use the brdiging feature of m0n0wall, but I'm having the problem that everything is blocked between the two interfaces. On LAN and OPT1, for testing I have the "allow * * * * *" rules in place (want to do some restrictions later).
OPT1 is bridging LAN.
Now the filter logs show that any traffic that reaches interface "bridge0" gets dropped. If I remove the * * * * * rules, traffic gets blocked at LAN or OP1, as you'd expect. So currently, as the DHCP server is running on LAN, not even DHCP is working on OPT1, as the client's DISCOVER packets get dropped at the bridge. Is there any other place in m0n0wall where I have to allow some traffic?

This is what the DHCP requests by a client on the OPT1 interface look like:

Code:

14:24:58.941933 bridge0 @0:26 b 0.0.0.0,68 -> 255.255.255.255,67 PR udp len 20 328 IN broadcast

0:26 is the default "block all" rule, as far as I can tell:

Code:

@1 pass out quick on lo0 all
@2 pass out quick on em0 proto udp from 192.168.0.1/32 port = bootps to any port = bootpc
@3 pass out quick on em1 proto udp from 192.168.0.1/32 port = bootps to any port = bootpc
@4 pass out quick on ng0 proto ipv6 from 89.244.170.38/32 to any
@5 pass out quick on ng0 proto udp from any port = bootpc to any port = bootps
@6 pass out quick on em0 all keep state
@7 pass out quick on ng0 all keep state
@8 pass out quick on em1 all keep state
@9 pass out quick on vr0 all keep state
@10 block out log quick all
@1 pass in quick on lo0 all
@2 block in log quick from any to any with short
@3 block in log quick from any to any with ipopts
@4 pass in quick on em0 proto udp from any port = bootpc to 255.255.255.255/32 port = bootps
@5 pass in quick on em0 proto udp from any port = bootpc to 192.168.0.1/32 port = bootps
@6 pass in quick on em1 proto udp from any port = bootpc to 255.255.255.255/32 port = bootps
@7 pass in quick on em1 proto udp from any port = bootpc to 192.168.0.1/32 port = bootps
@8 pass in quick on ng0 proto ipv6 from any to 89.244.170.38/32
@9 block in log quick on ng0 from 192.168.0.0/24 to any
@10 block in log quick on ng0 from 192.168.1.0/24 to any
@11 block in log quick on ng0 proto udp from any port = bootps to 192.168.0.0/24 port = bootpc
@12 pass in quick on ng0 proto udp from any port = bootps to any port = bootpc
@13 block in log quick on em0 from !192.168.0.0/24 to any
@14 block in log quick on em1 from !192.168.0.0/24 to any
@15 block in log quick on vr0 from !192.168.1.0/24 to any
@16 block in log quick on ng0 from 10.0.0.0/8 to any
@17 block in log quick on ng0 from 127.0.0.0/8 to any
@18 block in log quick on ng0 from 172.16.0.0/12 to any
@19 block in log quick on ng0 from 192.168.0.0/16 to any
@20 skip 1 in proto tcp from any to any flags S/FSRA
@21 block in log quick proto tcp from any to any
@22 block in log quick on em0 all head 100
@23 block in log quick on ng0 all head 200
@24 block in log quick on em1 all head 300
@25 block in log quick on vr0 all head 400
@26 block in log quick all
# Group 100
...

Which is kinda obvious, as there is no rule at all in the whole ruleset that mentiones bridge0. So is this a bug here that m0n0wall forgets to add rules for bridge0 to the ruleset, or did I forget to activate a checkbox somewhere?

EDIT: These are the bridge-related sysctl values, just in case...

Code:

net.link.bridge.ipfw: 0
net.link.bridge.log_stp: 0
net.link.bridge.pfil_local_phys: 0
net.link.bridge.pfil_member: 1
net.link.bridge.pfil_bridge: 0
net.link.bridge.ipfw_arp: 0
net.link.bridge.pfil_onlyip: 1

ipfilter should not see the packets on bridge0 (only on the member interfaces), since net.link.bridge.pfil_bridge=0... Which version of m0n0wall are you using?

1.33 built on Wed Mar 16 12:01:51 CET 2011 (generic-pc)

I tried adding rules for bridge0 manually (pass in quick on bridge0 all + pass out quick on bridge0 all), but then the packets just seemed to vanish, nothing gets logged anywhere about the DHCP requests, so I reverted that, since I also read about what net.link.bridge.pfil_bridge=0 should do. Is there any log/file/command I could use to debug further?

LAN and OPT1 are both sitting on a dual port nic, but that shouldn't really matter I guess.

I already tried rebooting too of course, but no luck either.

I also tried removing the hacked-in OPT2 interface that is running on the same interface as WAN.
(About that I have to say that although people say it causes problems in general, it doesn't seem to be the case when using PPPoE, as it is completely independent from the IP layer, unlike configuration by DHCP and/or using PPTP. PPPoE just doesn't care about the IP configuration of the interface it's running on. I still removed it during testing, as it would mean I'm running m0n0wall "out of specs" and should not get support. )

What I just noticed is that OPT1 still gets the IPv6 address assigned that it had before I bridged, so I checked via wireshark if maybe radvd is also still sending advertisements for the ipv6 subnet on OP1, but that is not the case. I think I have to unbridge them again to remove the IPv6 stuff from OPT1, as the settings are all disabled while it's bridged....

Setup is:
vr0 - WAN, PPPoE
em0 - LAN, 192.168.0.1/24
em1 - OPT1, formerly 192.168.3.1/24

I have to say that I changed a running, working m0n0wall setup, where LAN and OPT1 were simply running on different subnets. I could try a fresh start if all else fails, the problem is just that it would be a bit complicated to get physical access to the box currently to do the initial interface assignments, so if there's any hints how to debug the current setup any further I'd prefer to do that.