Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

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

    Scheduled Pinned Locked Moved
    DHCP and DNS
    3
    15
    5.5k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • B
      bobgus
      last edited by

      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.

      1 Reply Last reply Reply Quote 0
      • B
        bobgus
        last edited by

        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.

        1 Reply Last reply Reply Quote 0
        • B
          bobgus
          last edited by

          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.

          1 Reply Last reply Reply Quote 0
          • W
            wallabybob
            last edited by

            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

            1. Bridge WLAN to LAN

            2. 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)

            1 Reply Last reply Reply Quote 0
            • B
              bobgus
              last edited by

              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?

              1 Reply Last reply Reply Quote 0
              • W
                wallabybob
                last edited by

                @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.

                1 Reply Last reply Reply Quote 0
                • B
                  bobgus
                  last edited by

                  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.

                  1 Reply Last reply Reply Quote 0
                  • D
                    danswartz
                    last edited by

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

                    1 Reply Last reply Reply Quote 0
                    • B
                      bobgus
                      last edited by

                      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.

                      1 Reply Last reply Reply Quote 0
                      • D
                        danswartz
                        last edited by

                        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.

                        1 Reply Last reply Reply Quote 0
                        • W
                          wallabybob
                          last edited by

                          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?

                          1 Reply Last reply Reply Quote 0
                          • B
                            bobgus
                            last edited by

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

                            1 Reply Last reply Reply Quote 0
                            • D
                              danswartz
                              last edited by

                              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.

                              1 Reply Last reply Reply Quote 0
                              • B
                                bobgus
                                last edited by

                                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.

                                1 Reply Last reply Reply Quote 0
                                • B
                                  bobgus
                                  last edited by

                                  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

                                  1 Reply Last reply Reply Quote 0
                                  • First post
                                    Last post