pfSense WAN interface wont get IP address
-
When in this sort of situation it is easy to miss something and think you're run a test that in fact did not happen.
It seems so like a MAC address issue that I would retest it to be sure. Power down the modem completely, connect pfSense, retest.
Steve
-
this problem has been around for a long time, for example with this type of Sagem F @ st 3890 V3 DOCSIS 3.1 (Telekom Hungary)
The solution: from Cisco E900 + DD-WRT router MAC address spoofing and it works for me
Only pfSense does not picks up the Dynamic IP, other devices doin well (PcEngine APU4 board WAN interface)
-
Hmm, well if that is an issue it's one I'm not aware of. Because the MAC is not spoofed?
There was a bug in the dhcpclient as I said but that is fixed in 2.4.5. It would not have prevented MAC spoofing functioning though.
Steve
-
@stephenw10
this status then it occurs, if the next device set is on the provider's side, Cisco CMTS and edgeQAM with Prerequisites for Cable DHCP Leasequery / DHCP MAC Address Exclusion List, configured in Cisco IOS for some reason this is not liked by pfSense -
If it's something you can replicate in 2.4.5 then open a bug report for it one is not open already: https://redmine.pfsense.org/
-
Cable systems (at least here in the US) lock to a certain number of MAC addresses. Usually one if you are a residential customer. My ISP gives out two. Commercial customers may get upwards of 25 depending on the ISP. After you exhaust your "allowance" you must reboot the modem if you want to change devices.
The cable modem is a bridge. It bridges an RF solution to an Ethernet solution in simple terms. (whether or not it has a built in router is both relevant and irrelevant for this point. Relevant only if the onboard router is active as it would be the "Mac" address registered with the head end.)
Rebooting the cable modem causes the cable systems head end to release the MAC addresses and allow new entries.
When you read a doc like this- https://support.usr.com/support/6000/6000-ug/two.html
Understand that the point when the article says-
"The cable modem broadcasts a DHCP request. The CMTS will forward this request to a DHCP server located on the cable operator's network. The DHCP server will, in the most basic of systems, register the cable modem by looking at its unique Ethernet MAC address (different from the MAC layer in the DOCSIS protocol model) and assign to it an IP address from a pool of IP addresses."
that this is not the IP address assigned to your WAN of your router. It is only the address that is assigned to the modem itself for communications from the ISP for diagnostic and control. Basically they give it an address so they can reach it. (Some modems allow the GUI to be seen on this address and by anybody on the same cable system. Older modems were really easy to reboot by other customers. But it was a mostly unknown fact so no wide spread abuse.)It is only after the modem has gone through all of its boot up that data can be passed from one end to the other. (Ethernet to the cable side.) This is when the router should actually be started.
-
I know CATV systems pretty well (especially over coax + DOCSIS), at least I have thought so far, specifically the DHCP process and endpoint protection in such systems
during a couple of few weeks we investigated the origin of the problem with Telekom sysadmin and the conclusion became that it could be an unknown compatibility issue
this is not necessarily just a pfSense problem as we have not come to a specific conclusion
there was no serious solution, I was just looking for an old Cisco E900 and cloned the wan interface MAC in pfSense
it seems to be certain that the issue with Cisco hardware (CMTS) and IOS setup is the thing on CATV DOCSIS network + pfSense end environment
this is evidenced by the fact that the MAC address is cloned from Cisco or Linksys hardware it immediately connected to CISCO CMTS + Cisco vendor MAC on endpoint
if we connect a non-pfSense OS based device to the modem (which is in bridge mode), we will still get an IP address with DHCP
since this installation is in one of our company's external site, so there are not much times possible to shut down the device to lose the MAC entry in CMTS
the faults that we experienced was a prolonged power failure, as there was an electrical maintenance (on the electricity network of the service provider) for 8 hours and we had to shut down the UPSs
this condition is very rare, but as I have the opportunity I will look into the issue on 2.4.5 as wellbr, Krisztian
-
So I setup a new pfSense machine that wasn't vitalized, and it works perfectly no problems. No MAC spoofing, didn't even need to reboot the modem. So the problem is either the port on the other machine (Dell R220) or more likely my Hyper-V setup. Any suggestions on what settings I may have messed up?
-
As Steve wrote, this is probably no longer a problem on 2.4.5.
It is necessary to test in several pfSense based systems with different NICs.
I can tell you, I have never had problem with the following config: Dell R210II + onboard Broadcom (BCM5716C) and / or I350-F4 / T4 add-on -
I would guess it's something in the Hyper-V setup.
As I suggested before, try connecting the WAN to some other local DHCP server. Does it pull a lease from that?
If not it's something at layer 2 preventing it. The NIC not passed through correctly for example. Though you might consider that layer 1 I guess.
Steve
-
Using Spectrum as ISP and was pulling my hair out on why the Netgate sg-2100 wasn't getting a WAN ip address. After unplugging the modem and the Netgate for a few minutes, then plugging in the cable modem then the Netgate did it get a WAN IP address on the device, thanks!
-
J jimp moved this topic from Problems Installing or Upgrading pfSense Software
