No WAN IP since 2.4

Ulf-Ulf-Ulf · Dec 8, 2017, 2:22 PM

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. :(

Ulf-Ulf-Ulf · Dec 11, 2017, 7:35 AM

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…

Birke · Dec 11, 2017, 1:22 PM

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

Ulf-Ulf-Ulf · Dec 14, 2017, 10:55 AM

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

Derelict · Dec 14, 2017, 11:07 AM

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.

panteraboy · Apr 29, 2018, 9:36 AM

Same problem.

Derelict · Apr 29, 2018, 5:36 PM

Same problem.

And no new information given.

mconnley · Oct 11, 2018, 4:22 PM

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.

quadrinary · Nov 6, 2018, 12:39 PM

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.

sebster · Oct 23, 2019, 6:55 PM

@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! :)