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

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

    DHCP and DNS
    4
    9
    5.9k
    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.
    • G
      geekshelter
      last edited by

      PROBLEM DESCRIPTION:

      I have the same problem on 1.2.3-RELEASE (built on Mon Dec 7 20:21:30 EST 2009)!

      DHCP in WAN interface works as expected. My provider assigns an IP address, everything works like a charm.

      DHCP on the LAN interface works also without any problems (ATM there is just one computer – my main workstation -- connected to this port), but the bridged interfaces OPT1 (LAN2) and OPT2 (WLAN) only receive an address via DHCP if a client on the LAN interface is "active". I could not figure out if the client needs to use DHCP itself or if it suffices to create any network traffic at all.

      Some time after there is no traffic on the LAN port, e.g. after I shut down the main workstation or set it in sleep state, I do not see any DHCPREQUEST / DHCPACK messages anymore (please see the DHCPD logs further below). But there are no entries in the firewall log either. It seems these packages 'vanish' somewhere. When I activate the workstation again, power it up or wake it up from sleep state, DHCP works fine on all bridged ports. I could not figure out how long it actually takes until the DHCP stops working on the bridged ports, but it seems in combination with the configured lease time.

      I think I will file a bug report in the first week of January if no one knows a solution for this weird behaviour.

      INTERFACES:

      
      WAN*                     ->     vr0     ->      88.xxx.xxx.xxx(DHCP)
      LAN*                     ->     vr1     ->      192.168.10.1
      OPT1(LAN2)               ->     vr2     ->      NONE
      OPT2(WLAN)               ->     ath0    ->      NONE
      
      

      Interfaces OPT1 & OPT2 are bridged to LAN interface

      FIREWALL RULES:

      LAN:
      
      Proto   Source   Port   Destination   Port   Gateway   Schedule   Description   
      *       LAN net  *      *             *      *                    LAN -> Any  
      
      LAN2:
      
      Proto   Source        Port   Destination      Port   Gateway   Schedule   Description   
      UDP     0.0.0.0       68     255.255.255.255  67     *                    DHCP/BOOTP -> LAN2   
      UDP     192.168.10.1  67     255.255.255.255  68     *                    DHCPOFFER/DHCPACK -> LAN2   
      *       LAN2 net      *      *                *      *                    LAN2 -> Any  
      
      WLAN:
      
      Proto   Source        Port   Destination      Port   Gateway   Schedule   Description   
      UDP     0.0.0.0       68     255.255.255.255  67     *                    DHCP/BOOTP -> WLAN
      UDP     192.168.10.1  67     255.255.255.255  68     *                    DHCPOFFER/DHCPACK -> WLAN
      * 	   WLAN net      *      *                *      *                    WLAN -> Any  
      
      

      IFCONFIG OUTPUT:

      vr0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
      	options=2808 <vlan_mtu,wol_ucast,wol_magic>ether 00:0d:b9:1a:6b:a4
      	inet6 fe80::20d:b9ff:fe1a:6ba4%vr0 prefixlen 64 scopeid 0x1 
      	inet 88.xxx.xxx.xxx netmask 0xfffff800 broadcast 255.255.255.255
      	media: Ethernet autoselect (100baseTX <full-duplex>)
      	status: active
      vr1: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
      	options=2808 <vlan_mtu,wol_ucast,wol_magic>ether 00:0d:b9:1a:6b:a5
      	inet 192.168.10.1 netmask 0xffffff00 broadcast 192.168.10.255
      	inet6 fe80::20d:b9ff:fe1a:6ba5%vr1 prefixlen 64 scopeid 0x2 
      	media: Ethernet autoselect (100baseTX <full-duplex>)
      	status: active
      vr2: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
      	options=2808 <vlan_mtu,wol_ucast,wol_magic>ether 00:0d:b9:1a:6b:a6
      	inet6 fe80::20d:b9ff:fe1a:6ba6%vr2 prefixlen 64 scopeid 0x3 
      	media: Ethernet autoselect (none)
      	status: no carrier
      ath0: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
      	ether 00:1b:b1:00:ef:f6
      	inet6 fe80::21b:b1ff:fe00:eff6%ath0 prefixlen 64 scopeid 0x4 
      	media: IEEE 802.11 Wireless Ethernet autoselect mode 11g <hostap>status: associated
      	ssid midearth channel 3 (2422 Mhz 11g) bssid 00:1b:b1:00:ef:f6
      	authmode WPA1+WPA2/802.11i privacy MIXED deftxkey 2 TKIP 2:128-bit
      	TKIP 3:128-bit txpower 31.5 scanvalid 60 bgscan bgscanintvl 300
      	bgscanidle 250 roam:rssi11g 7 roam:rate11g 5 protmode OFF burst
      	-apbridge dtimperiod 1
      bridge0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
      	ether e2:b2:f3:fe:30:af
      	id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
      	maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
      	root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
      	member: ath0 flags=143 <learning,discover,autoedge,autoptp>ifmaxaddr 0 port 4 priority 128 path cost 370370
      	member: vr1 flags=143 <learning,discover,autoedge,autoptp>ifmaxaddr 0 port 2 priority 128 path cost 200000
      	member: vr2 flags=143 <learning,discover,autoedge,autoptp>ifmaxaddr 0 port 3 priority 128 path cost 55</learning,discover,autoedge,autoptp></learning,discover,autoedge,autoptp></learning,discover,autoedge,autoptp></up,broadcast,running,simplex,multicast></hostap></up,broadcast,running,promisc,simplex,multicast></vlan_mtu,wol_ucast,wol_magic></up,broadcast,running,promisc,simplex,multicast></full-duplex></vlan_mtu,wol_ucast,wol_magic></up,broadcast,running,promisc,simplex,multicast></full-duplex></vlan_mtu,wol_ucast,wol_magic></up,broadcast,running,simplex,multicast> 
      

      DHCP LOG:

      <–-- DHCP works on all bridged interfaces for a limited period of time ---->

      Dec 29 23:00:25 	dhcpd: DHCPACK on 192.168.10.107 to 00:23:12:ad:9d:60 (Shire) via vr1
      Dec 29 23:00:25 	dhcpd: DHCPREQUEST for 192.168.10.107 (192.168.10.1) from 00:23:12:ad:9d:60 (Shire) via vr1
      Dec 29 23:00:24 	dhcpd: DHCPOFFER on 192.168.10.107 to 00:23:12:ad:9d:60 (Shire) via vr1
      Dec 29 23:00:23 	dhcpd: DHCPDISCOVER from 00:23:12:ad:9d:60 (Shire) via vr1
      
      Dec 29 22:33:48 	dhcpd: DHCPACK on 192.168.10.125 to 00:17:f2:02:5f:b2 (Gondor) via vr1
      Dec 29 22:33:48 	dhcpd: DHCPREQUEST for 192.168.10.125 (192.168.10.1) from 00:17:f2:02:5f:b2 (Gondor) via vr1
      Dec 29 22:33:47 	dhcpd: DHCPOFFER on 192.168.10.125 to 00:17:f2:02:5f:b2 (Gondor) via vr1
      Dec 29 22:33:46 	dhcpd: DHCPDISCOVER from 00:17:f2:02:5f:b2 via vr1
      

      <–-- Activated main workstation which is connected via cable to LAN/vr1 ---->

      Dec 29 22:33:34 	dhcpd: DHCPOFFER on 192.168.10.107 to 00:23:12:ad:9d:60 (Shire) via vr1
      Dec 29 22:33:34 	dhcpd: DHCPDISCOVER from 00:23:12:ad:9d:60 (Shire) via vr1
      Dec 29 22:33:34 	dhcpd: DHCPOFFER on 192.168.10.107 to 00:23:12:ad:9d:60 (Shire) via vr1
      Dec 29 22:33:34 	dhcpd: DHCPDISCOVER from 00:23:12:ad:9d:60 (Shire) via vr1
      Dec 29 22:33:34 	dhcpd: DHCPOFFER on 192.168.10.107 to 00:23:12:ad:9d:60 (Shire) via vr1
      Dec 29 22:33:34 	dhcpd: DHCPDISCOVER from 00:23:12:ad:9d:60 (Shire) via vr1
      

      <–-- Only wireless PC on ath0 or PC connected via cable to vr2 are online, no DHCPACK / DHCPREQUEST ---->

      SIMILAR PROBLEMS ON THE FORUM OR ON MAILINGLIST:

      http://forum.pfsense.org/index.php/topic,13351.15.html
      http://forum.pfsense.org/index.php/topic,13901.0.html
      http://www.mail-archive.com/discussion@pfsense.com/msg00889.html

      1 Reply Last reply Reply Quote 0
      • T
        tacfit
        last edited by

        There was a post about I read recently. It's a design feature, the bridge dies if the LAN interface is not UP. We've worked around this by bridging the opposite way (binding LAN to the OPT). Another workaround is to assign what your would have first had as the OPT interface, as the LAN instead.

        1 Reply Last reply Reply Quote 0
        • GruensFroeschliG
          GruensFroeschli
          last edited by

          Or you could just connect a switch or a hub to the LAN interface so it's always up.

          We do what we must, because we can.

          Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

          1 Reply Last reply Reply Quote 0
          • T
            tacfit
            last edited by

            @GruensFroeschli:

            Or you could just connect a switch or a hub to the LAN interface so it's always up.

            That's hardly ideal though. I understand the issue, but it's unfortunate that you can't just use an ALIX+pfsense setup instead of your basic Buffalo/Netgear/Dlink router… without ungainly hacks to make it work.
            @tacfit:

            There was a post about I read recently. It's a design feature, the bridge dies if the LAN interface is not UP. We've worked around this by bridging the opposite way (binding LAN to the OPT). Another workaround is to assign what your would have first had as the OPT interface, as the LAN instead.

            For the record, we've found in some cases even reverse bridging doesn't work. We're going to try a few more things.

            1 Reply Last reply Reply Quote 0
            • GruensFroeschliG
              GruensFroeschli
              last edited by

              @tacfit:

              @GruensFroeschli:

              Or you could just connect a switch or a hub to the LAN interface so it's always up.

              That's hardly ideal though. I understand the issue, but it's unfortunate that you can't just use an ALIX+pfsense setup instead of your basic Buffalo/Netgear/Dlink router… without ungainly hacks to make it work.

              If you open the case of a basic Buffalo/Netgear/Dlink router you will find that there is not only the router but also a switch.
              Of course you are free to take a new bigger case, put the pfsense and a switch into it, desolder the RJ45 connector from the NIC and one port of the switch and connect them direct internally.

              We do what we must, because we can.

              Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

              1 Reply Last reply Reply Quote 0
              • T
                tacfit
                last edited by

                lol. Fair enough.

                1 Reply Last reply Reply Quote 0
                • jahonixJ
                  jahonix
                  last edited by

                  @tacfit:

                  @GruensFroeschli:

                  Or you could just connect a switch or a hub to the LAN interface so it's always up.

                  That's hardly ideal though. I understand the issue, but it's unfortunate that you can't just use an ALIX+pfsense setup instead of your basic Buffalo/Netgear/Dlink router… without ungainly hacks to make it work.

                  Honestly, I don't think it's ugly to use a switch behind a pfSense instead of a bridged IF.
                  Creating a switch by bridging interfaces is more like it. IMHO.
                  Remember that your throughput between hosts is determined by the max speed your ALIX allows - which is something in the 85MB/s range without further CPU tasks.
                  Since I mostly use GBit switches this is factor 10 I would lose without a switch.

                  I see your point and I wish there were ready made boxes available including a (GBit-) switch. With the boxes you mentioned I know that at least the LinkSys stuff internally bridges the interfaces as well - limiting the throughput to a CPU/bus bootleneck (actually they use VLAN tags for the ports).

                  Another benefit of using an external, manageabale switch would be the option to add interfaces through VLANs. With ALIX boards, the trunk port speed is limited to 100MBit, though.

                  1 Reply Last reply Reply Quote 0
                  • T
                    tacfit
                    last edited by

                    Yeah, the reason I don't like it is that it's not as simple. When this is something we're deploying for a branch office, the simpler the better. One device is sometimes better than two, according to the rules of simplicity :) Anyway, I understand the point about the cheapo routers having a switch onboard as well, I hadn't put two and two together on that one.

                    1 Reply Last reply Reply Quote 0
                    • jahonixJ
                      jahonix
                      last edited by

                      It's been a while, sorry.

                      This could be interesting for you:  http://forum.pfsense.org/index.php/topic,22890.0/topicseen.html
                      especially the NIC with built in NWAY switch.
                      Until I remembered that you were talking about an ALIX install…

                      1 Reply Last reply Reply Quote 0
                      • First post
                        Last post
                      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.