Cable modem fake DHCP server fooling pfSense when cable goes down
-
My modem does the same thing, and I use the reject leases option to fix it. It works fine here, when the modem loses sync it ignores the offer. Make sure the entry in that option doesn't have anything extra before/after (spaces, etc)
-
Another way you should be able minimize the problem of router reboot and temp issue of getting the 192.168.100 lease is to put a switch between pfsense and modem.. So that pfsense will not try and get a lease when it sees the interface come up before the modem has gotten sync and wan connection and shuts off its internal dhcp.
The only time you would get a 192.168.100 address this way is pfsense can not renew its lease and it expires and at that time the modem does not have a wan connection so its internal dhcp is running. This should really be a rare thing unless your isp is handing out really really short leases?
I would have to do some testing, but pretty sure that lease the modem hands out is really short.. So pfsense should correct itself as soon as the lease on the 192.168.100 address expires..
-
My modem does the same thing, and I use the reject leases option to fix it. It works fine here, when the modem loses sync it ignores the offer. Make sure the entry in that option doesn't have anything extra before/after (spaces, etc)
It just happened again, today.
My spouse came home from work, and found everything offline, and the root cause was that the pfSense box had picked up the IP address 192.168.100.2 again, from the cable modem's bogus DHCP server.
It remained that way until we reset DHCP manually by doing Release then Renew (from pfSense Status/Interfaces webpage).
The "Reject Leases From" field is exactly this: 192.168.100.1
No leading or trailing spaces.
The underlying file /var/etc/dhclient_wan.conf seems correct:
interface "em0" {
timeout 60;
retry 15;
select-timeout 0;
initial-interval 1;script "/sbin/dhclient-script";
reject 192.168.100.1;
}Any other suggestions?
Josh
-
Another way you should be able minimize the problem of router reboot and temp issue of getting the 192.168.100 lease is to put a switch between pfsense and modem.. So that pfsense will not try and get a lease when it sees the interface come up before the modem has gotten sync and wan connection and shuts off its internal dhcp.
The only time you would get a 192.168.100 address this way is pfsense can not renew its lease and it expires and at that time the modem does not have a wan connection so its internal dhcp is running. This should really be a rare thing unless your isp is handing out really really short leases?
I would have to do some testing, but pretty sure that lease the modem hands out is really short.. So pfsense should correct itself as soon as the lease on the 192.168.100 address expires..
The fake modem DHCP lease is long enough to essentially be permanent.
Every time it has happened, it has required manual intervention, in order to clear this fake lease from pfSense, and try again, to get a real genuine DHCP lease from Comcast that actually works.
I wonder if a firewall approach would work? That is what I will try next. Can I block DHCP replies from the entire 192.168.100.0/24 range? Or, does pfSense not allow this, because it treats WAN DHCP as special, giving it an exemption from the normal firewall rules? I'm not quite sure now how WAN DHCP works: it seems there's no firewall rule allowing it, and yet, it works. Is pfSense treating DHCP special here?
Josh
-
If you have to DHCP from your cable modem you have to DHCP from your cable modem.
If they have whacked out lease times I don't know what you expect to solve by asking something adhering to spec to do otherwise.
-
Interesting. When my modem hands out 192.168.100.x addresses, it only uses a 30 second lease time.
You might check the DHCP logs and look at what the whole dhclient transaction looks like.
-
As to the reject not working, you sure that is the IP your cable modem is using for its dhcp server? What make and model and isp is this? Handing out that ip address with a lease longer than a couple of minutes at most seems pretty stupid..
What does the dhcp log look like? Why don't you just block 192.168.0.0/16
-
Good idea. I thought of that myself.
It worked!
I was able to create a firewall rule that successfully blocked the unwanted DHCP replies from the cable modem.
Block, WAN, IPv4, UDP, Source Network 192.168.100.0/24, Destination Any, Destination Port 68.
Power cycled cable modem, to test.
The firewall log showed 5 DHCP replies blocked, so it worked!
The pfSense box happily acquired the genuine DHCP lease from the upstream Comcast server.
Thanks for the suggestion to try a firewall rule. Looks like the DHCP client of pfSense has some trouble properly performing exclusions on its own. That's understandable, because blocking unwanted traffic is the job of the firewall itself.
Josh
-
pretty sure there is suppose to be a rule that allows dhcp that is hidden when you set to dhcp, so not sure why the firewall rule you put in place would of blocked anything. Did you put them on floating tab?
cat /tmp/rules.debug
allow our DHCP client out to the WAN
pass in on $WAN proto udp from any port = 67 to any port = 68 tracker 1000113381 label "allow dhcp client out WAN"
pass out on $WAN proto udp from any port = 68 to any port = 67 tracker 1000113382 label "allow dhcp client out WAN" -
I'm seeing something similar with the WAN being assigned 192.168.100.10. However, I think my root cause is different.
I'm new to pfsense and setting up the Netgate RCC-VE 2440 that Santa delivered for Christmas. My home modem is Motorola Surfboard, SB6121. The new router is replacing a dlink 655.
The wired network, WAN and LAN, on igb0 and igb1 came up with fairly easily after a few rounds of novice mistakes and reloads (thankful for restore factory defaults!). Home LAN is 192.168.2.1/24.
The problem started when I enabled and setup the dlink655 on igb2 (opt 1) and called it WIFI on 192.168.0.1/24. The dlink was set to use dhcp (to request an address for itself), but not to be a dhcp server. Initially, no WIFI devices received IP addresses. I added a rule to the firewall to allow all WIFI (igb2, opt1) out initially to WAN and then set to 'any'. At this point the WAN was assigned 192.168.100.10. Disconnecting the dlink655 from the setup, disabling the new WIFI firewall rule, adding the firewall rule defined above in this thread, rebooting the modem several times, status/interfaces/renew several times, and rebooting Netgate 2440 several times all failed and the WAN remained assigned to 192.168.100.10. With the modem off and the dlink655 disconnected I edited /var/db/dhclient.lease.igb0 and removed the 192.168.100.10 entries. Now, I am back online at least for the wired equipment. :-) Home WIFI is still not working.
My contribution to the original problem on this thread is: any possibility that some piece of equipment on your home LAN may have been asking for Comcast modem for a local address as I suspect my dlink655 was? Possibly your old modem ignored the request for a local address? Just a thought!
I'm new to pfsense, so I hope the setup and descriptions make sense! Tips on re-adding dlink655 also appreciated (probably, new thread).
-
Totally OT, derelict teaches (and works fine)
Take WLAN router, give it a fixed IP OUTSIDE your local network (e.g. 10.10.10.99 when you have a 192.168.2.0/24), disable DHCP and connect via a LAN port (NOT the WAN port) to the pfSense network. The wireless clients get IPs from your pfSense… ;-)
-
Mine is doing the same thing, I have a motorola 6580 that now has an arris firmware, I too have put reject lease from 192.168.100.1, but it doesn't fix anything.
Hey, try forcing your speed/duplex to 100Mbps/Full duplex and see if it still does it. Or Put a 10/100 switch between modem and pfsense to do the same thing.
I had mine running through a battery backup that had 10/100 ports and had no problems for years, then ISP gave us a free speed bump and I was force to go gigabit links and that's when the problems started.I would like to see how yours behaves.
Right now I'm testing this theory and placed an old netgear 8 port layer 1 switch between my modem and dlink switch which then passes it over the vlan to my server then to a kvm instance of pfsense.
Here's my thread on it but no replies.
https://forum.pfsense.org/index.php?topic=105106.0I suspect this is a bug/broken handler in BSD or pfsense handling of motorola/Arris products.
-
pretty sure there is suppose to be a rule that allows dhcp that is hidden when you set to dhcp, so not sure why the firewall rule you put in place would of blocked anything. Did you put them on floating tab?
cat /tmp/rules.debug
allow our DHCP client out to the WAN
pass in on $WAN proto udp from any port = 67 to any port = 68 tracker 1000113381 label "allow dhcp client out WAN"
pass out on $WAN proto udp from any port = 68 to any port = 67 tracker 1000113382 label "allow dhcp client out WAN"Thanks!
It happened just again today.
Woke up to no Internet this morning. Upon inspection, cable modem fine, but pfSense badly fooled by that unwanted built-in cable modem DHCP again! pfSense Status/Interfaces WAN at 192.168.100.2 again and clients unable to reach Internet. Did Release and Renew manually from Interfaces tab, instant fix.
My firewall rule did not block the unwanted DHCP, unfortunately.
How can I work around these hidden rules that you mentioned?
Would the Floating tab be a better place than the WAN tab?
The "Reject Leases From" is set to 192.168.100.1 already but that feature does not work, unfortunately, as discussed before.
I am running out of ideas here, and it gets frustrating. Has anybody else had this problem?
How can I enable more DHCP logging, so that I can see the entire transaction?
Thank you for any help you can provide. pfSense is supposed to be autonomous and it is really frustrating having to nurse it back online every time the cable has a glitch.
Josh
-
Ive had this problem in the past but have not since I changed out my modem. Running a Zoom 5341J now. Ive been very happy with this modem. But makes me wonder if Arris doesn't have a bug and that their DHCP lease time just isn't way too long.
By the way- Zoom now has the license to badge their modems with the Motorola name. http://www.motorolacable.com/
-
I have the same issue. It happens with SB6141 and SB6183 modems. Also the helptext says: place the IP address or subnet of the DHCP server to be ignored here… but it does not accept a subnet such as 192.168.100.0/24. I posted before about it before and it was suggested that the modem's DHCP server is not 192.168.100.1 but I was unable to find anything to the contrary. I did place some other values in the advanced section that helped to stabilize the connection after an outage (before that the modem or pfSense would have to be rebooted) but in multi-WAN installations the down WAN is never detected!
-
Still nothing on this? I have this issue with my Zoom 5341H cable modem. I haven't double checked to see how long the lease is being set to, but it's certainly longer than a few minutes or even a few hours.
Walking my wife through a release and renew of WAN DHCP over the phone each time it goes out is stressing both of us. While, maybe, putting a switch in between might reduce the frequency, it'll still happen on power outages.
And it's worse than just the wife and kids suffering without internet, I remote in to home from remote all the time and I lose that capability as well. So, if they're not home when it happens, I'm stuck 'till someone gets home.
Also, and I don't mean this as a dig, but m0n0wall didn't seem to do this.
-
This thread is a year old. There have been some adjustments to the code so it now allows multiple addresses (separate with commas). But it's still the same underlying issue. It's not a firewall problem, it's a modem problem. Fix it in the modem or reject the leases. If you have an issue with a current version of pfSense, start a new thread.
