Cable modem fake DHCP server fooling pfSense when cable goes down
-
Hi! I'm running pfSense 2.2.5 on a Soekris 6501 box.
So far so good, until I upgraded my cable modem, to a new Arris SB6183 cable modem. I'm on Comcast.
Unfortunately, this modem has a new "feature" which is badly fooling pfSense and knocking me offline.
Whenever the cable goes down temporarily, or whenever the modem first boots up, the modem has a built-in fake DHCP server. The modem is at 192.168.100.1 (I think) and it assigns the pfSense box an IP address in that range, usually around 192.168.100.2.
I asked on IRC and was told to try "Reject leases from" option, in Interfaces/WAN/DHCP Client. I put in 192.168.100.1 here.
Unfortunately, it didn't work. My cable modem rebooted, and pfSense locked onto 192.168.100.1 again, and remained offline, because this fake DHCP server can't go anywhere. It's essentially a captive portal. It remained this way, until I manually intervened and Release/Renew the DHCP lease, under Status/Interfaces/WAN. Then, it found the genuine cable DHCP server instantly, and I was back online.
Sigh. It's reproducible at will, whenever I reboot the cable modem.
I tried changing "Reject leases from" to 192.168.100.0/24 to reject the entire IP range, but it didn't like this format. It said I also needed an "Alias IP address". Why would this be necessary? I explicitly do not want it to use an artificial IP address if unable to contact the upstream DHCP server. I want it to wait until it can get online with the genuine Comcast DHCP server, and use that.
Is there a workaround that works?
I looked at /var/db/dhclient.leases.em0 file, to see if I could take a look at the bogus DHCP lease, but it wasn't listed there at all. What would cause pfSense to claim the 192.168.100.2 address, then? It's properly set to DHCP (and DHCP6), and there are no aliases.
I looked at /var/etc/dhclient_wan.conf file, and it correctly has the "reject 192.168.100.1" line listed.
Very strange that it doesn't seem to work, though.
Does anybody else have this problem?
Josh
-
so I have seen it get the address in 192.168.100 range that cable modems will provide when they don't have connection to isp.. But the lease on this is really short and as soon as the wan is up on the modem and pfsense goes to renew it should get the new ip from your isp.
when pfsense gets an this 100.x lease what is the time on it, look in the lease file when it gets this.
-
That's just it: I couldn't see it in the /var/db/dhclient.leases.em0 file.
That file only contained my genuine Comcast lease.
Nevertheless, pfSense was still locked onto the 192.168.100.1 network at this time!
Strange!
Which file was it supposed to be listed in? Maybe I found the wrong name?
Josh
-
if pfsense got an IP via dhcp, then there has to be a lease file showing that.. yes it should be the lease file for the interface that has the IP.
-
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.