DHCP on bridged lan/wlan



  • DHCP on bridged lan/wlan in pfSense 0.89.2

    I can't make it work, I'm not sure if it is supposed to work but only lan clients get an IP from DHCP, WLAN clients doesn't?
    If I don't bridge the two and setup dhcp to give lan 192.168.1.* and wlan 192.168.2.* then everything works fine.

    I't not a big problem as it works just as well for me with two IP ranges, I just wondered if it wasn't supposed to work.



  • need some more info.

    DHCP server is on pfsense, correct?

    For WLAN, that's a wireless card in your pfsense box?

    I would expect the bridge to forward the DHCP, as long as appropriate firewall rules were in place to pass it.  Can't say I've tried it though.



  • 0.89.2 is not the most recent version. Please upgrade to 0.90a (which is the newest version while writing this) and retest. If you still encounter the same problem please feel free to open a ticket at cvs-trac.
    And like CMB already said, the bridge in pfsense is a filtering-bridge by default (other than with m0n0) so you need rules at both interfaces involved in the bridge to pass traffic.

    Holger



  • There is a rule called # allow our DHCP client out to the WAN on the firewall which says "block in log quick on xl0 proto udp from any port = 67 to 192.168.1.0/24 port = 68 label "allow dhcp client out wan". This one doesn't allow lan clients to get their ip from a DHCP server which is NOT pf but on the WAN side of pf. It would be a nice ideea that this rule would apply only when dhcp server on pf in enabled.



  • @sato:

    There is a rule called # allow our DHCP client out to the WAN on the firewall which says "block in log quick on xl0 proto udp from any port = 67 to 192.168.1.0/24 port = 68 label "allow dhcp client out wan". This one doesn't allow lan clients to get their ip from a DHCP server which is NOT pf but on the WAN side of pf. It would be a nice ideea that this rule would apply only when dhcp server on pf in enabled.

    that's on xl0, which should be your WAN, to destination your LAN subnet.  You can't have DHCP coming in on WAN going to your LAN, so that's an automatically added safe guard.  that doesn't affect anything between your internal networks.



  • If I understand your setup correctly you are trying to run pfsense as accesspoint only and you want to run your wan interface as wired interface to your real lan and the wireless interface for your wireless clients getting dhcp from a server in real lan which means pfsenses wan?



  • @cmb:

    that's on xl0, which should be your WAN, to destination your LAN subnet.  You can't have DHCP coming in on WAN going to your LAN, so that's an automatically added safe guard.  that doesn't affect anything between your internal networks.

    Not even in bridged mode? Is there a way to overpass that safe guard? I really need that…



  • My setup is that I have a WAN, LAN and WLAN (wireless) and if I bridge LAN and WLAN then WLAN works great except it doesn't get an IP from the DHCP. Only LAN clients get an IP, on the WLAN clients I have to setup a static IP.

    I'm downloading 0.92 right now and to see if it works on that. Otherwise I just wont bridge the two and setup two IP ranges on the DHCP because that works just as well for me  :)



  • I haven't tried it yet but you should be able to have it work with a single ip range. Assign a dhcp pool of like 50 to 150 for the wired and 151 to 254 to the wireless and point  then just set an allow rule for anything from the wireless to goto anything on the lan and anything from the lan to anything on the wireless and you should be set.



  • When you bridge LAN and WLAN(opt2) then the DHCP tab for WLAN isn't there any more i.e. I can only setup DHCP for the LAN.
    I havent had time to test on 0.92 yet.



  • Hi,
    Have you managed to solve this problem?
    I'm now faceing the same problem  (PFS 1.0-BETA1), and looking for a solution.





  • @sullrich:

    http://cvstrac.pfsense.com/tktview?tn=693

    Thank you for your answer. Probably I am misunderstanding something, but it doesn't work for me.
    What I did: LAN 10.0.0.0/27(fxp1) I gave OPT1 10.0.0.6/27(ath0 WEP enabled).
    Enabled DHCP server on OPT1 and assigned static reserves for clients. It doesn't work.
    If LAN is 10.0.0.0/27 , OPT1 10.0.0.40/27 it works fine. But in this case a can't apply traffic shapeing for OPT1 :(
    That's why I am trying to bridge the two.



  • Then you will most likely need to depend on an upstream dhcp server.



  • I think, maybe I am wrong, that the rule 303 blocks the dhcp requests, what is that? Can I switch it off somehow?

    ======================================== my logs ========================
    Dec 29 22:52:20 pf: 000084 rule 303/0(match): block in on ath0: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
    Dec 29 22:52:20 pf: 000188 rule 303/0(match): block in on bridge0: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
    Dec 29 22:52:20 pf: 3. 093180 rule 303/0(match): block in on ath0: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
    Dec 29 22:52:16 pf: 000081 rule 303/0(match): block in on ath0: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
    Dec 29 22:52:16 pf: 000134 rule 303/0(match): block in on bridge0: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
    Dec 29 22:52:16 pf: 115612 rule 303/0(match): block in on ath0: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
    Dec 29 22:52:16 pf: 000144 rule 303/0(match): block in on bridge0: fe80:19::204:23ff:fe94:78 > ff02:19::2: ICMP6, router solicitation, length 16
    Dec 29 22:52:16 pf: 1. 812786 rule 303/0(match): block in on ath0: fe80::204:23ff:fe94:78 > ff02::2: ICMP6, router solicitation, length 16
    Dec 29 22:52:14 pf: 000081 rule 303/0(match): block in on ath0: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
    Dec 29 22:52:14 pf: 000140 rule 303/0(match): block in on bridge0: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
    Dec 29 22:52:14 pf: 2. 185924 rule 303/0(match): block in on ath0: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
    Dec 29 22:52:12 pf: 000162 rule 303/0(match): block in on bridge0: fe80:19::204:23ff:fe94:78 > ff02:19::2: ICMP6, router solicitation, length 16
    Dec 29 22:52:12 pf: 3. 998962 rule 303/0(match): block in on ath0: fe80::204:23ff:fe94:78 > ff02::2: ICMP6, router solicitation, length 16
    Dec 29 22:52:08 pf: 000144 rule 303/0(match): block in on bridge0: fe80:19::204:23ff:fe94:78 > ff02:19::2: ICMP6, router solicitation, length 16
    Dec 29 22:52:08 pf: 885276 rule 303/0(match): block in on ath0: fe80::204:23ff:fe94:78 > ff02::2: ICMP6, router solicitation, length 16
    Dec 29 22:52:07 pf: 000080 rule 303/0(match): block in on ath0: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
    Dec 29 22:52:07 pf: 000137 rule 303/0(match): block in on bridge0: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
    Dec 29 22:52:07 pf: 114143 rule 303/0(match): block in on ath0: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
    Dec 29 22:52:07 pf: 000134 rule 303/0(match): block in on bridge0: :: > ff02:19::1:ff94:78: ICMP6, neighbor solicitation[|icmp6]
    Dec 29 22:52:07 pf: 040165 rule 303/0(match): block in on ath0: :: > ff02::1:ff94:78: ICMP6, neighbor solicitation[|icmp6]
    Dec 29 22:52:07 pf: 000183 rule 303/0(match): block in on bridge0: :: > ff02:19::16: HBH [|icmp6]
    Dec 29 22:52:07 pf: 3. 842633 rule 303/0(match): block in on ath0: :: > ff02::16: HBH [|icmp6]
    Dec 29 22:52:03 pf: 000081 rule 303/0(match): block in on ath0: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
    Dec 29 22:52:03 pf: 000162 rule 303/0(match): block in on bridge0: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
    Dec 29 22:52:03 pf: 15. 801391 rule 303/0(match): block in on ath0: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]



  • Turn off block private networks and the bogon option under WAN.



  • Thanks for your reply but this didn't help :(
    Not to say that I wouldn't like to open the WAN for these kind of private networks.
    The other question is that how comes WAN in the picture, when I bridge LAN and OPT1?
    Anyhow I did for experience and now I receive the following blocks:

    Dec 29 23:27:42 pf: 000078 rule 296/0(match): block in on ath0: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
    Dec 29 23:27:42 pf: 000140 rule 296/0(match): block in on bridge0: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]



  • Yes, the block on WAN is useless in this case, I misread before.

    Let me test this out.  I'll get back to you.



  • Thanks Scott, let me know if I can help with testing something.



  • Oddly enough this was not working for me but after I rebooted the client, it does work.

    Not sure why you're having trouble, it works here.



  • @sullrich:

    Oddly enough this was not working for me but after I rebooted the client, it does work.

    Not sure why you're having trouble, it works here.

    O.K.  with what  settings?



  • OPT1(ATH0) bridged to WAN(SIS1)



  • @sullrich:

    OPT1(ATH0) bridged to WAN(SIS1)

    … but what I want is to bridge OPT1(ATH0) to LAN(fxp1)...



  • That works as well.  I have both configurations here that I can restore.

    Just restored a similar config and its fine.



  • That's good, in this case I've got hope to set it up finally  :)
    But now I've got two lines repeated on the diag_logs_filter page:

    Dec 30 21:54:50 pf: 000056 rule 141/0(match): block in on ath0: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
    Dec 30 21:54:50 pf: 000121 rule 141/0(match): block in on bridge0: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]

    I have rules allow everything from OPT1 to LAN and vice versa.



  • Okay, in this case I bridged LAN to WAN.

    Issue the following command from a shell:

    update_file.sh /etc/inc/filter.inc && shutdown -r now

    And let me know if its fixed after reboot.



  • I've got the following result, what do I wrong?

    ##############
    $ update_file.sh /etc/inc/filter.inc && shutdown -r now
    Status: 404
    Content-type: text/html
    X-Powered-By: PHP/4.4.0

    No input file specified.
    trying to fetch latest /etc/inc/filter.inc
    Status: 404
    Content-type: text/html
    X-Powered-By: PHP/4.4.0

    No input file specified.
    ##############





  • BINGO! Thanks Scott!
    This has done magic :)
    Will this modification in filter.inc be included in next release?



  • Yep.

    Thanks for testing!



  • Life is not so easy.  :(

    Next morning as I switch on my notebook, I didn't receive ip address again.

    In the logs I found the followings:
    #################
    Dec 31 07:46:31 pf: 000126 rule 316/0(match): block in on bridge0: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
    Dec 31 07:46:31 pf: 287219 rule 316/0(match): block in on bridge0: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
    Dec 31 07:46:30 pf: 000134 rule 316/0(match): block in on bridge0: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
    Dec 31 07:46:30 pf: 7. 386391 rule 316/0(match): block in on bridge0: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]

    #################

    Previous evening it was working fine.



  • Run pfctl -vvsa | grep 316

    What's the output of that?



  • Hi Scott,

    As per your request I run it with the following result.
    ##############
    $ pfctl -vvsa | grep 316
    @316 pass in quick on ng0 inet proto ah from 194.143.xxx.yyy to 87.97.aaa.bbb keep state label "IPSEC: OfficeDMZ - inbound ah proto"

    ##############
    …BUT ... probably it is not the same  rule #316 anymore. (It seem to me changes time to time, maybe when  I reboot.)

    Meanwhile I solved it, so that I created an
    " UDP  *  68  *  67  *" rule on my OPT1 (ath0) interface.

    I don't know what security hole creates it, if any?
    I don't know that after applying your new filter.inc yesterday night, why worked without this rule?
    Is ARP filtering is on when interface is bridged?
    This static arp enabling is on the dhcp server tab originally, but since now it is bridged, that's no more available.
    (Of course it is enabled on LAN as well)


Locked