Re: HOWTO: DHCP with bridged connections (1.2.1-RC1 and later)
-
I have a Wireless SIP phone which connects to an Asterisk VoIP server somewhere on the LAN. The phone is configured as a DHCP client.
Setting up pfSense was extremely frustrating until I discovered a way to do it. I do have questions though.
First, set the WLAN type as Static (not as DHCP client), set Bridge with as none, and set up the rest of the configuration so your wireless client will connect.
Second, go into Services->DHCP server, click on the WLAN tab and set up a DHCP server which uses only a few addresses (not conflicting) from your LAN subnet address space.
Third, connect with the DHCP wireless client (my VoIP phone) and make sure it successfully gets an address from the DHCP server. You can check Status->DHCP leases and you should see an active DHCP lease for your client.
However, at this point, the WLAN is not connected to the LAN and no packets get to the Asterisk VoIP server because there is no connection between the WLAN and LAN, even though they are both in the same subnet.
Fourth, go into Interface->WLAN and set the Bridge with to LAN. Voile, the WiFi phone can now register with the Asterisk server on the LAN and two way conversations are easy because the SIP and RTP packets are whizzing around in a flat LAN address space with no NATs to climb.
–---- Comments/Questions
Because WLAN is now bridged to LAN, I cannot go back to Services->DHCP server because there is no tab for WLAN.
Also, Diagnostics->Packet Capture doesn't work on the WLAN interface because WLAN is no longer a selectable interface.
(Even at step 3 above, the captured packets on WLAN looked more like LAN packets than useful DHCP negotiation packets on WLAN, something wrong there)
As it is now, I don't know if the configured (invisible) DHCP server will go away? Will it survive through a power failure? Will it survive through a reload? What does the configuration file look like now. I could do all these tests, but it would be better if Services->DHCP server->WLAN were still available.
Do I have things straight in my mind? Is there a bug? Should I file a bug? (Where)
It would be good if I did not have to bridge the WLAN to the LAN. It would also be good if I could sprinkle in a few firewall rules to limit spooks coming into my LAN via the WLAN path.
-
The title of this note was taken from a submission by jochen. That submission was Retired and I couldn't figure out how to reply to it.
-
OK, got it. It wasn't that hard. I put the Interfaces->WLAN back to Bridge with 'none' and set the IP address to an address just below the DHCP server range for WLAN. Set the mask to 24 (so it matches the LAN address space)
Then took a harder look at the firewall table for WLAN. I added another rule, perhaps better. Instead of source * I put WLAN net and instead of LAN address, I put LAN net. Perhaps LAN address is actually the pfSense LAN interface IP address. Going there won't do it. LAN net seems better.
I can go back and delete the first rule in the WLAN set.
This seems OK. No ghost DHCP servers which go away on reboot.
-
You have made this a bit more complex than necessary.
If you bridge WLAN to LAN then effectively WLAN and LAN are the same LAN. However for DHCP to work across the bridge it is necessary to add firewall rules to the WLAN interface to allow DHCP traffic and then DHCP requests from WLAN will get processed by LAN DHCP server.
If the WLAN interface is bridged to LAN it is not necessary for the WLAN interface to have an IP address.
So configuration to enable WLAN and DHCP service on WLAN probably requires only
-
Bridge WLAN to LAN
-
Add firewall rules to WLAN interface (Firewall -> Rules) to allow DHCP traffic:
Proto=UDP, Source=, Port=68, Destination=255.255.255.255, Port=67
Proto=UDP, Source=, Port=68, Destination=LAN address, Port=67You will need to modify the second firewall rule if pfSense is not the DHCP server (the destination should be either the IP address of the DHCP server or LAN net)
-
-
Yes, that does work. I put the DHCP server on the LAN network (there is no WLAN tab once it is bridged).
However, I loose packet capture on WLAN and perhaps other features because of the bridging.
How can I get packets to flow back and forth between LAN and WLAN without bridging. Just opening up the firewall does not seem to do it. I am missing something fundamental here.
Is it possible to do what I want without bridging?
-
Is it possible to do what I want without bridging?
I'm not sure exactly what you want so I can't answer precisely.
If bridging does what you want EXCEPT that you can't packet capture on the WLAN (because you don't want the noise of the 'LAN-only' traffic) then you can always get a capture of the traffic in and out of you WLAN interface by ssh into the pfSense box and using tcpdump in the ssh session. For example, suppose your wireless interface is ral0 then the shell command
tcpdump -i ral0
will display all the traffic on your wireless interface. There are many tcpdump options to further filter the traffic that is logged.Its possible a packet capture on the LAN interface will show all traffic on both LAN and WLAN in which case using some of the filters might restrict the capture to the traffic of interest.
I would guess it would be reasonable to call the inability to do a packet capture on the WLAN interface a bug so you could lodge a bug report on that.
Use of bridged interfaces seems to introduce a number of inconsistencies which I consider inelegant (lack of packet capture on bridged interface, dhcpd incorrectly reports interface on which dhcp requests received, DHCP has to be enabled by firewall rules on bridged interface) so there could be advantages to not using bridging. But that probably depends on exactly what you want to do.
-
I just want to have packets go back and forth between the LAN interface and the WLAN interface - without bridging and having both interfaces in the same address space (subnet). My first note explains why.
-
You can't - routing doesn't work that way. Why do they need to be in the same subnet?
-
I can't? Why not, it is only software..
I need the wireless phones on the same subnet as my Asterisk VoIP server, so the SIP and RTP packets can move smoothly without needing any STUN software to climb the NAT hils.
-
Not to be snide, but you are evidently not a networking professional. You can't have two interfaces in the same subnet. No one supports this, and it can't be made to work reliably. As to why you thought you needed this, as my Dad taught me: "it ain't what you don't know, it's what you know that ain't so!" Your issue is that you erroneously think you need NAT between your two subnets, which is not the case.
-
Its one of the rules of IP networking that every interface on a box has to be in a unique subnet. (Unless its bridged.) You'll have to bridge if you want the interfaces in the same subnet.
But, why do you think you'll have to traverse NAT if the interfaces are in different subnets? There doesn't have to be NAT for traffic between LAN and OPT1 (for example).
And I don't think you have demonstrated a particularly compelling reason for not bridging, but maybe you haven't revealed all the relevant details. Its not clear to me from your first note why you are against bridging. Is it the packet capture issue? If so, what's wrong with using tcpdump?
-
I'm looking at my 5 port switch and the 4 port switch on the back of my WRT54GL and I yell as loud as I can "danswartz says you can't work" !!
-
Switches are layer 2. IP is layer 3. You have proven you are not only ignorant but stupid enough to argue with professionals. I give up. Welcome to my ignore list.
-
My status as newby is listed accurately. I am on this list to get help.
Thanks to your comments, I am now exploring separate subnets on LAN and WLAN. The DHCP server for the WLAN is easier, but the connection between LAN and WLAN is more difficult than with bridging.
An additional wrinkle is that I would like to direct WLAN VoIP connections to the LAN and NTP queries to the WAN (because that's where the servers are).
I will keep you posted as to my progress.
-
Got it!
The problem had nothing to do with the pfSense box. Packets are whizzing around inside just fine.
With the LAN on one subnet (with SIP server) and the WLAN on another subnet, the problem is that the SIP registration ACK doesn't know how to get back to the WLAN wifi phone. A static route has to be added to the routing table on the SIP server box so that it knows the WLAN subnet can be found by going into the pfSense box through the LAN interface address.
When the LAN and WLAN were bridged, no additional SIP server route was needed.
It also helps to diagnose the problem with a Wireshark on the server box and not on the (LAN switch connected) browser box.
Thanks for your encouragement.
Bob G