News: This forum is now permanently frozen.
Pages: [1] 2
Topic: DHCP across bridge interfaces  (Read 30085 times)
« on: October 09, 2009, 17:06:53 »
jlr83 *
Posts: 4

I have OPT1 bridged to LAN
I have a DHCP server connected to LAN
Computers on OPT1 are not seeing the DHCP server
I have tried rules of * * * * * on both LAN and OPT1 interfaces
Can DHCP be bridged?  What ought I do/try?

Thank you
« Reply #1 on: October 13, 2009, 14:23:10 »
hakemon *
Posts: 21

I think this is linked my problem (the thread before yours).

I hope someone has an answer, because my wifi has been broke since.
« Reply #2 on: November 21, 2009, 03:39:35 »
onhel *
Posts: 5

I'm affected by this too using an Alix 2C2, back on b16 for now.

OnHeL
« Reply #3 on: December 04, 2009, 06:21:38 »
onhel *
Posts: 5

1.3 release and I'm still having this issue   Cry

OnHeL
« Reply #4 on: December 04, 2009, 15:08:16 »
knightmb ****
Posts: 341

I don't see why it can't, as the broadcast packets should make it across the bridge. Can you enable DHCP on the LAN (not the separate DHCP server) to see if works that way first. Just to verify if even internally m0n0wall can bridge the DHCP packets/request?
« Last Edit: December 04, 2009, 15:41:35 by knightmb »

Radius Service for m0n0wall Captive Portal - http://amaranthinetech.com
« Reply #5 on: December 29, 2009, 07:24:04 »
xDream *
Posts: 1

I have the same problem.
It seems that monowall's firewall always blocking DHCP traffic even with ***** rule:
http://s50.radikal.ru/i127/0912/14/e2eee7f925c4.jpg
« Reply #6 on: January 04, 2010, 19:00:30 »
brushedmoss ****
Posts: 446

That seems pretty explicit.

I will try setup a bridge if and find the offending line of code.
« Reply #7 on: January 06, 2010, 17:40:08 »
brushedmoss ****
Posts: 446

Yes, this is broken (?) DHCP is blocked through the bridge by the internal ruleset unless you are using m0n0walls builtin DHCP server, in which case it pokes a specific hole through the firewall.

This rule is not opened if the builtin dhcp server is not enabled on the LAN.

A possible work around is to enable the builtin dhcp server, but select

 'Only respond to reserved clients listed below.'

so that it doesn't actually respond to requests, but does open the firewall ruleset to allow dhcp through the bridge
« Last Edit: January 06, 2010, 17:43:18 by brushedmoss »
« Reply #8 on: January 11, 2010, 01:02:00 »
itheemonk *
Posts: 1

It also seems that you cant block M0n0walls built in dhcp using the firewall.
« Reply #9 on: January 11, 2010, 01:18:26 »
brushedmoss ****
Posts: 446

That's correct, there is a built in rule to allow it, but you could disabled it instead of blocking it :-)
« Reply #10 on: January 27, 2010, 04:19:16 »
mwillett *
Posts: 1

Yes, this is broken (?) DHCP is blocked through the bridge by the internal ruleset unless you are using m0n0walls builtin DHCP server, in which case it pokes a specific hole through the firewall.

This rule is not opened if the builtin dhcp server is not enabled on the LAN.

A possible work around is to enable the builtin dhcp server, but select

 'Only respond to reserved clients listed below.'

so that it doesn't actually respond to requests, but does open the firewall ruleset to allow dhcp through the bridge

So this is a known bug? When did this break?  I am glad there is a workaround but this is not ideal given that I am way to uptight.  Also - Brushedmoss im not sure what you mean when you say "That's correct, there is a built in rule to allow it, but you could disabled it instead of blocking it :-)"
« Reply #11 on: January 27, 2010, 10:13:33 »
brushedmoss ****
Posts: 446

That's correct, there is a built in rule to allow it, but you could disabled it instead of blocking it :-)

if dhcp server is enabled, m0n0wall opens the necessary ports to allow this to work. If it's not enabled, the ports won't be opened and dhcp requests through the interface will fail as the next rule it hits blocks all traffic not from the interface subnet (dhcp broadcasts etc), this is described in status.php as anti-spoofing rule.  All this happens before user specified rules are applied. This is what is happening to you now. 

When m0n0wall went to bridge_if (1.3b17 (08/12/2009))  all bridging became filtered and this problem arose as there was no option for 'transparent' mode which bypassed this internal ruleset.

So, right now, in 1.3 if you want dhcp traffic through, you should enable the dhcp server.
If you don't want the built in server to respond, select 'only respond to reserved clients listed below'
If you don't want dhcp traffic through the interface, disable the built in dhcp server.

I am considering what the best 'fix' might be, probably a tick box on the bridged Interface or in advanced settings, to disabled the 'anti-spoofing' rule, which would prevent m0n0wall blocking dhcp (and multicast and other ranges of valid traffic) in bridged mode,.

« Reply #12 on: May 09, 2010, 06:00:51 »
momothefox *
Posts: 49

why enabling dhcp on lan interface. as long as it was converted to if_bridge .. after bridging opt1 to lan, go to assign interfaces page, you should find + sign, click to add the new bridge interface that acts as DHCP server.. etc.
mohammed

Mohammed Ismail
« Reply #13 on: October 14, 2011, 22:40:56 »
CBarown *
Posts: 3

I am currently running 1.33 on a soekris 4801.  My old install was 1.3b16 on an old pc.  I can't seem to get DHCP to work for OPT1 when OPT1 is bridged to WAN.  I have tried turning on the DHCP server and having it only respond to registered requests.  I have also checked the box 'Disable spoof checking on bridge'.  None of these seem to make DHCP work across the bridge.

Can someone please tell me what I am doing wrong?

Thanks,
Chris
« Reply #14 on: October 17, 2011, 22:57:17 »
CBarown *
Posts: 3

As an alternative solution to my problem does anyone have the embedded image for 1.3b16?  That will allow me to run the same version on my Soekris as I am running on the old pc.

Thanks,
Chris
 
Pages: [1] 2
 
 
Powered by SMF 1.1.20 | SMF © 2013, Simple Machines