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

    DHCP on bridged lan/wlan

    Scheduled Pinned Locked Moved
    DHCP and DNS
    7
    33
    20.1k
    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.
    • S
      sullrich
      last edited by

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

      1 Reply Last reply Reply Quote 0
      • I
        iimre
        last edited by

        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]

        1 Reply Last reply Reply Quote 0
        • S
          sullrich
          last edited by

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

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

          1 Reply Last reply Reply Quote 0
          • I
            iimre
            last edited by

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

            1 Reply Last reply Reply Quote 0
            • S
              sullrich
              last edited by

              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.

              1 Reply Last reply Reply Quote 0
              • I
                iimre
                last edited by

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

                1 Reply Last reply Reply Quote 0
                • S
                  sullrich
                  last edited by

                  OPT1(ATH0) bridged to WAN(SIS1)

                  1 Reply Last reply Reply Quote 0
                  • I
                    iimre
                    last edited by

                    @sullrich:

                    OPT1(ATH0) bridged to WAN(SIS1)

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

                    1 Reply Last reply Reply Quote 0
                    • S
                      sullrich
                      last edited by

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

                      Just restored a similar config and its fine.

                      1 Reply Last reply Reply Quote 0
                      • I
                        iimre
                        last edited by

                        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.

                        1 Reply Last reply Reply Quote 0
                        • S
                          sullrich
                          last edited by

                          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.

                          1 Reply Last reply Reply Quote 0
                          • I
                            iimre
                            last edited by

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

                            1 Reply Last reply Reply Quote 0
                            • S
                              sullrich
                              last edited by

                              Try replacing /etc/inc/filter.inc with http://cvs.pfsense.com/cgi-bin/cvsweb.cgi/~checkout~/pfSense/etc/inc/filter.inc?rev=1.575.2.54;content-type=text%2Fplain;only_with_tag=RELENG_1

                              1 Reply Last reply Reply Quote 0
                              • I
                                iimre
                                last edited by

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

                                1 Reply Last reply Reply Quote 0
                                • S
                                  sullrich
                                  last edited by

                                  Yep.

                                  Thanks for testing!

                                  1 Reply Last reply Reply Quote 0
                                  • I
                                    iimre
                                    last edited by

                                    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.

                                    1 Reply Last reply Reply Quote 0
                                    • S
                                      sullrich
                                      last edited by

                                      Run pfctl -vvsa | grep 316

                                      What's the output of that?

                                      1 Reply Last reply Reply Quote 0
                                      • I
                                        iimre
                                        last edited by

                                        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)

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