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

    No WAN IP since 2.4

    DHCP and DNS
    9
    20
    3.4k
    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.
    • M
      mcfly9
      last edited by

      No, I am starting devices in the correct order to work it around. This makes it quite impossible to connect to the network remotely once it went into a bad state.

      1 Reply Last reply Reply Quote 0
      • X
        xrnd88
        last edited by

        yeah it's a pain. My temporary solution is a script that reboots the pfsense box if the network has been down for 20 minutes.

        1 Reply Last reply Reply Quote 0
        • M
          mcfly9
          last edited by

          Any changes in 2.4.1 / 2.4.2?

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

            you can try and set a static ip on your pf-wan-port.
            according to your log your modem has the internal ip 192.168.100.1. set your pf-wan-port to static with 192.168.100.2 and gateway 192.168.100.1.

            does that work?

            1 Reply Last reply Reply Quote 0
            • M
              mcfly9
              last edited by

              @Birke:

              you can try and set a static ip on your pf-wan-port.
              according to your log your modem has the internal ip 192.168.100.1. set your pf-wan-port to static with 192.168.100.2 and gateway 192.168.100.1.

              does that work?

              It won't work. The modem only temporarily assigns the IP 192.168.100.x while it boots. After it has booted it brings down the WAN port for 5 secs and brings it online again.
              With pfSense 2.3.x I have been able to obtain a public IP address after this. With 2.4.x I don't get any IP after the modem has booted (and cycled the wan port).

              1 Reply Last reply Reply Quote 0
              • M
                mcfly9
                last edited by

                Created an issue: https://redmine.pfsense.org/issues/8152

                1 Reply Last reply Reply Quote 0
                • U
                  Ulf-Ulf-Ulf
                  last edited by

                  Hi there,

                  I have the same problem. As you can see in the logs my WAN connection suddenly just went down.

                  As long as I keep my pfSense box unconnected it looks like this.

                  When I connect it to the modem it looks like this.

                  This is happening on two locations where I'm using pfSense firewall. For both locations the modem is in Bridgemode with a static IPv4 address. If I connect my notebook to the modem it works fine. I get a public IP assigned and I'm good to go. Connecting the pfSense firewall results in the shown behavior above.

                  Let me know how I may help resolving this issue. I will do my best.

                  Thanks in advance. Cheers. Ulf

                  1 Reply Last reply Reply Quote 0
                  • M
                    mcfly9
                    last edited by

                    @mcfly9:

                    Created an issue: https://redmine.pfsense.org/issues/8152

                    Issue has been closed. Looks like we need to collect more evidence that there is something wrong…

                    1 Reply Last reply Reply Quote 0
                    • U
                      Ulf-Ulf-Ulf
                      last edited by

                      I'm at work right now. Here are the informations I gathered until now. I grabbed one of my Qotom boxes (although they are called Kettop on german amazon. However they look identical).

                      I installed a fresh 2.3.5 version on it. Configured WAN to use DHCP and thats about it. Since the issue seemingly startet with 2.4 I thought this would help. Surprisingly I didn't.

                      Fresh install. No Cable connected to the modem.

                      Cable connected. Issue looks the same as in 2.4.x

                      However I do get an IP via DHCP if I connect my notebook to the modem.

                      Since I get a valid DHCP lease from the ISP on my notebook I thought I work arround the issue by setting a static config in pfsense. Sadly this did not work either

                      Given the fact that 2.3.5 and earlier versions worked without any hassle for months. And this issue occurred (at least for me) out of nothing (no update, no reboot, nothing), for now I'm not very confident this is a pfsense bug. Or at least not exclusive to pfsense. It would be very interesting to know if my cable ISP pushed some updates to the modem recently. I don't know though where to find such info. These things are blackboxes :(

                      Sorry no easy solution. But this might help others somehow.

                      Ulf

                      //edit: Fri 8-Dec-2017 02:53 P.M.

                      I did a bit more testing. I plugged in a Windows 7 machine.

                      At first windows was unable to get a dhcp lease from the modem.

                      But after a modem restart my Windows 7 machine got an IP lease.

                      The modem itself is running a status page on 192.168.100.1. From there it seems the latest firmware is from 2015.

                      While browsing this forum I came across multiple posts saying it could help to block leases from 192.168.100.1 on the WAN port. So I did that. Problem still there. :(

                      1 Reply Last reply Reply Quote 0
                      • U
                        Ulf-Ulf-Ulf
                        last edited by

                        For now I disabled bridge mode. It don't know why but it seems the problems do not appear when there is NAT enabled. (at home as well at my workplace)  ???
                        I try to contact my ISP. We'll see how that goes…

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

                          @Ulf-Ulf-Ulf:

                          While browsing this forum I came across multiple posts saying it could help to block leases from 192.168.100.1 on the WAN port. So I did that. Problem still there. :(

                          hmm, since the modem has the 192.168.100.1 at boot time, maybe you could try: disable the "Block private networks and loopback addresses" option on the interface and dont block the leases from 192.168.100.1.

                          you could also try disabling "Gateway Monitoring" in the routing options (or set a specific ip as monitor ip, for example 8.8.8.8).

                          1 Reply Last reply Reply Quote 0
                          • U
                            Ulf-Ulf-Ulf
                            last edited by

                            @Birke:

                            @Ulf-Ulf-Ulf:

                            While browsing this forum I came across multiple posts saying it could help to block leases from 192.168.100.1 on the WAN port. So I did that. Problem still there. :(

                            hmm, since the modem has the 192.168.100.1 at boot time, maybe you could try: disable the "Block private networks and loopback addresses" option on the interface and dont block the leases from 192.168.100.1.

                            you could also try disabling "Gateway Monitoring" in the routing options (or set a specific ip as monitor ip, for example 8.8.8.8).

                            I tried that. No success. In the meantime my ISP decided to send me a new modem. I don't know how that would help, but hey. I would rather try than do nothing.

                            1 Reply Last reply Reply Quote 0
                            • DerelictD
                              Derelict LAYER 8 Netgate
                              last edited by

                              Someone should probably packet capture instead of looking at logs.

                              It is almost always beneficial to reject leases from 192.168.100.1 when you have cable modem service.

                              Chattanooga, Tennessee, USA
                              A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                              DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                              Do Not Chat For Help! NO_WAN_EGRESS(TM)

                              1 Reply Last reply Reply Quote 0
                              • P
                                panteraboy
                                last edited by

                                Same problem.

                                1 Reply Last reply Reply Quote 0
                                • DerelictD
                                  Derelict LAYER 8 Netgate
                                  last edited by

                                  Same problem.

                                  And no new information given.

                                  Chattanooga, Tennessee, USA
                                  A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                                  DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                                  Do Not Chat For Help! NO_WAN_EGRESS(TM)

                                  1 Reply Last reply Reply Quote 0
                                  • M
                                    mconnley
                                    last edited by mconnley

                                    Posting this on this old thread as I searched repeatedly for a definitive answer but didn't find one:

                                    I experienced the same issue, but stumbled into a solution. Netgear CM1000 cable modem which sits at 192.168.100.1. Packet captures revealed nothing immediately suspicious/seemingly incorrect.

                                    I set DHCP to reject offers from 192.168.100.1, but that had no effect.

                                    Then I set the interface's Speed and Duplex to 1000baseT full-duplex (it had previously been autoselect) and the problem appears to be resolved. Prior to this change, the first lease acquisition after a pfSense reboot would succeed, but any subsequent loss of connection/lease would result in dhclient exiting after successfully binding. See lightly redacted excerpt from dhcpd.log below:

                                    Sep 29 20:57:13 pfhost dhclient[30738]: DHCPDISCOVER on em5 to 255.255.255.255 port 67 interval 1
Sep 29 20:57:13 pfhost dhclient[30738]: DHCPOFFER from 10.48.8.1
Sep 29 20:57:13 pfhost dhclient: ARPSEND
Sep 29 20:57:15 pfhost dhclient: ARPCHECK
Sep 29 20:57:15 pfhost dhclient[30738]: DHCPREQUEST on em5 to 255.255.255.255 port 67
Sep 29 20:57:15 pfhost dhclient[30738]: DHCPACK from 10.48.8.1
Sep 29 20:57:15 pfhost dhclient: BOUND
Sep 29 20:57:15 pfhost dhclient: Starting add_new_address()
Sep 29 20:57:15 pfhost dhclient: ifconfig em5 inet 216.80.xxx.yyy netmask 255.255.254.0 broadcast 255.255.255.255
Sep 29 20:57:15 pfhost dhclient: New IP Address (em5): 216.80.xxx.yyy
Sep 29 20:57:15 pfhost dhclient: New Subnet Mask (em5): 255.255.254.0
Sep 29 20:57:15 pfhost dhclient: New Broadcast Address (em5): 255.255.255.255
Sep 29 20:57:15 pfhost dhclient: New Routers (em5): 216.80.110.1
Sep 29 20:57:15 pfhost dhclient: Adding new routes to interface: em5
Sep 29 20:57:15 pfhost dhclient: /sbin/route add default 216.80.xxx.1
Sep 29 20:57:15 pfhost dhclient: Creating resolv.conf
Sep 29 20:57:15 pfhost dhclient[30738]: bound to 216.80.xxx.yyy -- renewal in 302400 seconds.
Sep 29 20:57:15 pfhost dhclient[70423]: em5 link state up -> down
Sep 29 20:57:16 pfhost dhclient[1161]: connection closed
Sep 29 20:57:16 pfhost dhclient[1161]: exiting.

                                    It's not immediately clear to me how speed/duplex is related, but it may be worth investigating further -- I'm happy to provide more details if anyone would like. In the meantime, if you are experiencing this issue, try manually setting the interface's Speed and Duplex to a proper, explicit value and see if that works for you.

                                    1 Reply Last reply Reply Quote 0
                                    • Q
                                      quadrinary
                                      last edited by quadrinary

                                      I managed to solve this in my context by disabling any layer1.5+ protocol between my modem and pfSense VM. This meant disabling spanning tree in any form on the port connected to the modem, LLDP and CDP on the switch, and, likely most importantly, CDP on the vSwitch in my ESXi 6.5 host. From time to time I would see a rogue MAC address from VMWare show up in my WAN VLAN via the switch and figured the modem might be catching that.

                                      After hunting all that down, I’m reliably able to grab an IP address via DHCP after firewall and modem reboots.

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

                                        @quadrinary I had the same issue... DHCPDISCOVER was going over the line just fine, but I was getting no DCHPOFFER from the modem. This is also on a pfsense VM on vSphere 6.7. Plugging my laptop directly into the cable modem was working just fine, getting an IP from the modem within a second. Disabling CDP on the vSwitch and rebooting modem and pfsense VM solved the problem. Thanks to this post, because I would have NEVER found the solution to the problem otherwise. So thanks! :)

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