HOWTO: DHCP with bridged connections (1.2.1-RC1 and later)
-
@cmb:
What he wrote is 100% correct. You have to add rules to allow the DHCP traffic.
Why was this changed from 1.2?
Because it was a bug, the system should never allow any traffic that isn't explicitly allowed by your firewall rules.
-
It doesn't work for my wireless.
My wireless bridged to LAN (My LAN is O.K. to connect to internet), and then followed your instruction to add and apply rule in the firewall, but my wireless still cannot connect to internet.
I use pfsense V1.2.2
Can someone advise more troubleshooting steps? ;D
-
It doesn't work for my wireless.
My wireless bridged to LAN (My LAN is O.K. to connect to internet), and then followed your instruction to add and apply rule in the firewall, but my wireless still cannot connect to internet.
I use pfsense V1.2.2
Can someone advise more troubleshooting steps? ;D
Check your firewall logs for blocked traffic, and if you're seeing any related to your DHCP requests, allow that traffic. If you aren't seeing blocks there, the problem resides somewhere else.
-
Can I simply put 3 "any" in the rule, and then save and apply it? Any risk?
-
I had an Any to Any rule on my OPT1 interface and it still didn't work for my bridged interface (OPT1 and LAN).
To get it to work I followed Hagabard's instructions of allowing UDP port 67-68 BUT it needs to be the first rule in the list on the OPT1 interface.
UDP * 67 - 68 * 67 - 68 * pass dhcp traffic
Hope this helps others.
Duncan
-
Seems to be working without any firewall additions in 1.2.3, can anyone confirm that?
-
It's working if your're OPT1 rule is like this
because your'e passing everything including DHCP traffic.
I don't know why Pfsense doesn't allow DCHP traffic on Bridge connection automically. It just DHCP traffic anyway. I understand the reason why by default OPT1 traffic are block but DHCP should be auto since it's bridge right, just like for LAN.
-
I don't know why Pfsense doesn't allow DCHP traffic on Bridge connection automically. It just DHCP traffic anyway. I understand the reason why by default OPT1 traffic are block but DHCP should be auto since it's bridge right, just like for LAN.
pfSense does just what you tell it to.
If you dont create a rule telling it to allow DHCP it wont allow it.
Why should it automatically allow something?In fact this would be very bad.
I bridge in one of my setups my LAN(s) with the WAN(s) but i still have a DHCPs on the LAN(s).
(192.168.0.0/22 subnet on WAN, 4x 192.168.0.x/24 as /22 subnets)
Since outbound traffic is allowed i see quite a number of DHCP requests on my WAN(s).
I wouldn't want my DHCPs in the other subnets to answer any of these requests…. -
I don't know why Pfsense doesn't allow DCHP traffic on Bridge connection automically. It just DHCP traffic anyway. I understand the reason why by default OPT1 traffic are block but DHCP should be auto since it's bridge right, just like for LAN.
pfSense does just what you tell it to.
I think there is an inconsistency in configuring DHCP services and this has confused a number of users:
Firewall rules seem to be required for DHCP service only on bridged interfaces.
DHCP services are enabled by a tab under Services -> DHCP Server EXCEPT if the interface is bridged in which case you need to add firewall rules.I haven't tried this, but I wonder how one would configure DHCP service on OPT1 if OPT1 were bridged to LAN and DHCP service was to be disabled on LAN. I guess one would have to bridge LAN to OPT1 and then DHCP on OPT1 could be enabled by a tab under Services -> DHCP Server.
I can see that its useful to be able to control DHCP on individual interfaces but enabling DHCP on interfaces involved in a bridge is quite non-intuitive. I think new users would appreciate it if there was a consistent GUI interface for enabling DHCP service: To enable DHCP service on a physical interface do so through the appropriate tab under Services -> DHCP Server regardless of whether or not the interface was bridged.
-
If you bridge an interface with another one, you can no longer run a DHCP on it.
At least the tab under services –> DHCP server disappears.
Otherwise you'd have two DHCP servers on the same broadcast domain.I dont think it's inconsistant or confusing, just something to take into account when dealing with bridges.
Maybe a small note somewhere when enabling the bridge could appear. -
yes, maybe a note somewhere would be helpful. I was tearing my hair out trying to solve the DCHP issue when I bridge OPT1 with LAN until I read this thread. Now I'm bald. You see that note could have save me some hair.
-
I have a similar setup and tried your suggestion, but I'm still having issues. Does anyone have the definitive answer for getting DHCP working across bridged interfaces? Everything was working fine until I upgraded to 1.2.1.
Hello,
Similar and no succes. I dont wnow what i should do to make this working.
Using a NEW ALIX 2D3 and new install of embedded 1.2.3RC1.
-
Not working on last nanobsd snapshot…
-
Not working on last nanobsd snapshot…
You haven't given forums readers much information to work with.
What interfaces are you using? What is bridged with what? Does DHCP work on the "main" bridged interface (the one with an IP address)? Have you added the firewall rule for DHCP from the "secondary" bridged interface (the one without an IP address)? Have you checked the firewall logs to see if DHCP is blocked by the firewall?
-
Hello,
I am using ALIX 2D3 board.
I have:
WAN (vr0) DHCP 192.168.0.128
LAN (vr1) fixed 192.168.1.1
LAN2 (vr2 bridged on vr1) no ip
ath0 not activated yet, i want to solve vr1/vr2 before.WAN is receiving DHCP from my other router and it work.
Integrated DHCP is working well with LAN.
I have added the "famous" firewall rule in vr2 and no problem in log. If i suppress the rule, the firewall block: ok.
I have added a rule for all traffic pass in vr2. Also tested without it.
Here is an exemple of my config :http://diliak.pastebin.com/m6af426e9
You can see that i had'nt anything connected to vr1 and vr2. This explain the "no carrier".
I think, but i can be wrong, that when i connect my laptop on vr2, DHCP server send DHCP response on vr1.
I have tested 1.2.3RC1 embedded, 1.2.2 embedded and now i am with snapshot august 25 of nanoBSD 1.2.3RC2.
No success.
With fixed IP, vr2(LAN2) work well.
Thank's
-
I think, but i can be wrong, that when i connect my laptop on vr2, DHCP server send DHCP response on vr1.
Why do you think that? Have you done any traces?
I can't see anything obviously wrong with your configuration.
Long shot: When you had the laptop connected to vr2 was the link status active? Its possible you MIGHT need a crossover cable to connect the laptop to vr2 (or vr1 or vr0)!
-
I think, but i can be wrong, that when i connect my laptop on vr2, DHCP server send DHCP response on vr1.
Why do you think that? Have you done any traces?
It's because when y tested with my wlan (atho) bridged to lan(vr1), my laptop didn't have any DHCP reply. BUT, and it's funny, when i connected the cable LAN (vr1) on my laptop, it obtained DHCP reply from LAN AND FOR WLAN at the same time.
I can't see anything obviously wrong with your configuration.
Long shot: When you had the laptop connected to vr2 was the link status active? Its possible you MIGHT need a crossover cable to connect the laptop to vr2 (or vr1 or vr0)!
Yes it come active. And for cable, i dont think so because when i put fixed IP on laptop, it work well.
-
It's because when y tested with my wlan (atho) bridged to lan(vr1), my laptop didn't have any DHCP reply. BUT, and it's funny, when i connected the cable LAN (vr1) on my laptop, it obtained DHCP reply from LAN AND FOR WLAN at the same time.
I am having this exact issue, as soon as I plug the ethernet cable in, both it and the wifi get an IP.
Was any way around this found?
(new install of pfSense 1.2.3) -
If a member of a bridge is down, the whole bridge is down.
The old workaround to assign the wireless interface as LAN and bridge the wired interface as an OPT to it is still valid.
-
Or plug LAN into a switch. An Ethernet loopback plug used to work but didn't the last time I tried it (but my plug may have been bad).
