DHCP across bridged interfaces in 2.0RC1 flaky, or misconfigured?
-
Hi,
2.0RC1 i386 built on Mon Feb 28 18:12:00 EST 2011 on a machine with VIA C7 board and Intel dual NIC server PCI card.
I have set up the following:
em0 = WAN
EM1 = LAN
VR0 = LAN2 (called WIFILAN)BRIDGE0 = LAN+LAN2
Firewall rules allowing any any on LAN and also on LAN2. (see screenshots).
DHCP in LAN is fine, static leases work like a charm, however DHCP on VR0 is weird. I tested with an iPad for example, I get no DHCP lease. I then punch "renew dhcp lease" and get a lease briefly (the iPad shows the lease for about 1-2 seconds), then the lease is gone. If I apply a static IP, everything is fine.
Somehow there seems to be a DHCP broadcast problem… I don't think I need to specifically allow dhcp udp broadcasts from lan <->lan2 since I have an any any rule, or do I?
I am sure this works, I am just missing something... what could it be? Help plz!
-
DHCP clients typically send their initial DHCP request with a source IP address of 0.0.0.0 (since they don't yet have an IP address). Such an address won't pass your "any" rule on WiFiLAN.
You will probably see the blocked DHCP request in your firewall log.
Also, since LAN and WiFiLAN are bridged DHCP will assign IP addresses to LAN and WiFiLAN clients from the same address pool which may not be a part of WiFiLAN net (whatever that is - the WiFiLAN interface should not have an IP address when it is bridged.)
-
hi,
LAN has 192.168.111.1, WIFILAN has 192.168.111.3 as a fixed IP, the ip address pool for dhcp is set to 192.168.111.51 to .90. How do I get the dhcp request to go through the firewall then?
-
You will be better off in the long run if you rearrange your interfaces like so:
WAN: em0
LAN: bridge0
WIREDLAN: em1
WIFILAN: vr0And then run DHCP, etc, on the LAN.
-
Also, in that scenario, WIREDLAN and WIFILAN should be on IP type of 'none' - they should not have an IP assigned, the only IP should be on the LAN/bridge0 interface.
And at the top of WIREDLAN/WIFILAN you need a rule that looks like:
Pass UDP from 0.0.0.0:68 to 255.255.255.255:67 Allow DHCP
Pass * from <lan subnet="">to *That second rule could be more strict of course but that would replicate the default allow rule.</lan>
-
thank you so much - setting it up as you suggested makes absolute sense and works like charm.
-
I'm also trying to get DHCP to work across a two bridged interfaces. I can see the DHCP request and the DHCP reply being passed in the logs, but the firewall just ain't letting the DHCP reply through.
I'm using "2.0-RC1 (amd64) built on Sat Feb 26 18:07:23 EST 2011". I'm using a really simple setup with one LAN interface and two bridged interfaces for WAN DHCP passthrough to one machine behind pfsense.
Should this work?
-
Ok…so I got my act together, reinstalled pfsense and wrote a detailed description of what i've done :-)
- Installed "2.0-RC1 (amd64) built on Sat Feb 26 18:07:23 EST 2011".
- Set LAN, WAN (WANIN) and OPT1 (WANOUT) interfaces during install.
- Set LAN IP.
- Set WAN (WANIN) interface to type "None". Before i do this i can se that the WANIN interface a got an IP from my ISP via DHCP.
- Enable WANOUT interface (type None).
- Bridge WANIN and WANOUT interfaces.
- I create "allow all" rules on the WANIN and WANOUT interfaces.
- I renew the IP address on the server connected to WANOUT.
- The server will not get an IP. The only thing that shows in the logs are:
Pass Jun 5 20:01:48 WANOUT 0.0.0.0:68 255.255.255.255:67 UDP - I add a rule to allow the above specificaly and place the rule on top of the WANOUT interface.
- I renew the IP addres in the server but i still can't get an IP.
I'm at a loss here. No traffic is passing the through the bridge.
This seems like a bug?
-
Does the DHCP server on WANIN see the DHCP request? Does it report sending a response?
-
Thank you for your answer Wallybob but I just solved this. I found my solution here:
http://forum.pfsense.org/index.php?topic=30653.0
I am running a vmware ESXi virtualized firewall and I was soooo sure this wasn't causing any problems :-)
Well…my solution was to "enable promiscuous mode on the virtual switch port group".