Re: HOWTO: DHCP with bridged connections (1.2.1-RC1 and later)

wallabybob

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=67

You 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)

bobgus

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?

wallabybob

@bobgus:

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.

bobgus

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.

danswartz

You can't - routing doesn't work that way. Why do they need to be in the same subnet?

bobgus

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.

danswartz

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.

wallabybob

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?

bobgus

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" !!

danswartz

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.

bobgus

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.

bobgus

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