No WAN IP since 2.4
-
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). -
Created an issue: https://redmine.pfsense.org/issues/8152
-
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
-
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…
-
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. :(
-
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… -
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).
-
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.
-
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.
-
Same problem.
-
Same problem.
And no new information given.
-
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.
-
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.
-
@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! :)
