just a thought (that might be way off), are there antispoofing rules on
bridged interfaces in pfsense? There was a bug in m0n0wall quite a
while back, but after pfsense forked, where antispoofing rules were
being applied to bridged interfaces. they shouldn't be applied at all
to any bridged interface, as it causes all kinds of issues in certain
circumstances.
Tim Roberts wrote:
I did. The first line in my post was from the system log. Heres
another snip:
<http://172.16.248.192/diag_logs_filter.php#>
Apr 28 18:46:30 BRIDGE0 172.16.248.106:67
255.255.255.255:68 UDP
<http://172.16.248.192/diag_logs_filter.php#>
Apr 28 18:46:30 BRIDGE0 172.16.248.106:67
255.255.255.255:68 UDP
<http://172.16.248.192/diag_logs_filter.php#>
Apr 28 18:46:29 BRIDGE0 172.16.248.3:67
255.255.255.255:68 UDP
<http://172.16.248.192/diag_logs_filter.php#>
Apr 28 18:46:29 BRIDGE0 172.16.248.3:67
255.255.255.255:68 UDP
<http://172.16.248.192/diag_logs_filter.php#>
Apr 28 18:46:29 BRIDGE0 172.16.248.106:67
255.255.255.255:68 UDP
<http://172.16.248.192/diag_logs_filter.php#>
Apr 28 18:46:29 BRIDGE0 172.16.248.106:67
255.255.255.255:68 UDP
<http://172.16.248.192/diag_logs_filter.php#>
Apr 28 18:44:32 BRIDGE0 172.16.248.106:67
255.255.255.255:68 UDP
<http://172.16.248.192/diag_logs_filter.php#>
Apr 28 18:44:32 BRIDGE0 172.16.248.106:67
255.255.255.255:68 UDP
<http://172.16.248.192/diag_logs_filter.php#>
Apr 28 18:44:31 BRIDGE0 172.16.248.3:67
255.255.255.255:68 UDP
<http://172.16.248.192/diag_logs_filter.php#>
Apr 28 18:44:31 BRIDGE0 172.16.248.3:67
255.255.255.255:68 UDP
<http://172.16.248.192/diag_logs_filter.php#>
Apr 28 18:44:31 BRIDGE0 172.16.248.106:67
255.255.255.255:68 UDP
<http://172.16.248.192/diag_logs_filter.php#>
Apr 28 18:44:31 BRIDGE0 172.16.248.106:67
255.255.255.255:68 UDP
<http://172.16.248.192/diag_logs_filter.php#>
Apr 28 18:40:31 BRIDGE0 172.24.15.1 216.26.248.13
ICMP
<http://172.16.248.192/diag_logs_filter.php#>
Apr 28 18:40:16 BRIDGE0 172.26.2.238 239.255.255.253
IGMP
<http://172.16.248.192/diag_logs_filter.php#>
Apr 28 18:40:00 BRIDGE0 172.26.2.238 239.255.255.253
IGMP
<http://172.16.248.192/diag_logs_filter.php#>
Apr 28 18:38:38 BRIDGE0 172.16.248.106:67
255.255.255.255:68 UDP
<http://172.16.248.192/diag_logs_filter.php#>
Apr 28 18:38:38 BRIDGE0 172.16.248.106:67
255.255.255.255:68 UDP
:38:37 BRIDGE0 172.16.248.3:67 255.255.255.255:68
UDP
172.16.248.106 and 172.16.248.3 are our DHCP servers. We have permited
UDP 67 & 68 from any host to any host and even from any host to
255.255.255.255 just for giggles. Doesnt seem to matter which rules I
plop in DHCP doesnt work. Is there something Im missing for DHCP other
then UDP 67 & 68? Its WinBlowz DNS. Should I have put a 3rd NIC and
bridged from LAN to OPT? Monowall used to make you do that. Just
seemed silly to have 3 nics for a bridge when you only need 2. Is
there a hitch bridging from LAN to WAN for this type of service?
Thanks
Tim
----- Original Message -----
*From:* Scott Ullrich <mailto:[EMAIL PROTECTED]>
*To:* [email protected] <mailto:[email protected]>
*Sent:* Friday, April 28, 2006 1:14 PM
*Subject:* Re: [pfSense Support] HELP! Beta 3 + Bridge Not
allowing DHCP thru
Look in the System logs for the items being blocked and allow
them. I have a wireless WAN to OPT1 bridge and I am getting DHCP
no problem on my powerbook.
On 4/28/06, *Tim Roberts* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
We came under a multicast flood tht is cripling us. I quickly
tossed together a PFSense Beta 3 box with 2 nics and set it up
as a bridge. We placed it in a half way point in our wireless
backbone. We put 2 rules on each interface (we couldnt tell
which interface was which under frustrating circumstances in
he dark at a tower). Both rules are to drop IGMP from any to
any. We also added a rule to drop any source to 224.0.0.0/4
<http://224.0.0.0/4> on both the lan and the wan.
our problem is that now our clients on the far side of the
backbone cannot obtain addresses via DHCP. static customers
get on and flow fine. So we inserted "allow any source to any
destination udp 67-68". The firewall logs show drops over and
over from our dhcp (172.16.248.3 <http://172.16.248.3>) server:
Apr 28 16:00:18 BRIDGE0 172.16.248.3:67
<http://172.16.248.3:67> 255.255.255.255:68
<http://255.255.255.255:68> UDP
here are the lan rules:
Proto Source Port Destination Port Gateway
Description
[click to toggle enabled/disabled status]
<http://172.16.248.192/firewall_rules.php?if=lan&act=toggle&id=7>
UDP 172.16.248.3 <http://172.16.248.3> 67
255.255.255.255
<http://255.255.255.255> 68 * Allow All Thru DHCP
[edit rule] <http://172.16.248.192/firewall_rules_edit.php?id=7>
[delete rule]
<http://172.16.248.192/firewall_rules.php?act=del&if=lan&id=7>
[add a new rule based on this one]
<http://172.16.248.192/firewall_rules_edit.php?dup=7>
[click to toggle enabled/disabled status]
<http://172.16.248.192/firewall_rules.php?if=lan&act=toggle&id=8>
* 172.24.128.128 <http://172.24.128.128> *
172.16.248.8
<http://172.16.248.8> * * Allow All Thru DHCP
[edit rule] <http://172.16.248.192/firewall_rules_edit.php?id=8>
[delete rule]
<http://172.16.248.192/firewall_rules.php?act=del&if=lan&id=8>
[add a new rule based on this one]
<http://172.16.248.192/firewall_rules_edit.php?dup=8>
[click to toggle enabled/disabled status]
<http://172.16.248.192/firewall_rules.php?if=lan&act=toggle&id=9>
UDP * * * 67 * Allow All Thru
DHCP
[edit rule] <http://172.16.248.192/firewall_rules_edit.php?id=9>
[delete rule]
<http://172.16.248.192/firewall_rules.php?act=del&if=lan&id=9>
[add a new rule based on this one]
<http://172.16.248.192/firewall_rules_edit.php?dup=9>
[click to toggle enabled/disabled status]
<http://172.16.248.192/firewall_rules.php?if=lan&act=toggle&id=10>
UDP * * * 68 * Allow All Thru
DHCP
[edit rule]
<http://172.16.248.192/firewall_rules_edit.php?id=10>
[delete rule]
<http://172.16.248.192/firewall_rules.php?act=del&if=lan&id=10>
[add a new rule based on this one]
<http://172.16.248.192/firewall_rules_edit.php?dup=10>
[click to toggle enabled/disabled status]
<http://172.16.248.192/firewall_rules.php?if=lan&act=toggle&id=11>
IGMP * * * * * Drop IGMP
[edit rule]
<http://172.16.248.192/firewall_rules_edit.php?id=11>
[delete rule]
<http://172.16.248.192/firewall_rules.php?act=del&if=lan&id=11>
[add a new rule based on this one]
<http://172.16.248.192/firewall_rules_edit.php?dup=11>
[click to toggle enabled/disabled status]
<http://172.16.248.192/firewall_rules.php?if=lan&act=toggle&id=12>
* * * 224.0.0.0/12 <http://224.0.0.0/12>
* * Drop IGMP
[edit rule]
<http://172.16.248.192/firewall_rules_edit.php?id=12>
[delete rule]
<http://172.16.248.192/firewall_rules.php?act=del&if=lan&id=12>
[add a new rule based on this one]
<http://172.16.248.192/firewall_rules_edit.php?dup=12>
[click to toggle enabled/disabled status]
<http://172.16.248.192/firewall_rules.php?if=lan&act=toggle&id=13>
* * * * * * Default LAN ->
any
[edit rule]
<http://172.16.248.192/firewall_rules_edit.php?id=13>
[delete rule]
<http://172.16.248.192/firewall_rules.php?act=del&if=lan&id=13>
[add a new rule based on this one]
<http://172.16.248.192/firewall_rules_edit.php?dup=13>
wan rules are same. As you can see we have tried some pretty
stupid stuff troublshooting. I realize the 1st rule is dumb
but the 3rd & forth outta get'r done shouldnt?
Thanks in advance!
Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
