Warning - pfSense MAC Spoofing Might Permanently Change MAC Address
-
Thanks to mods for deleting my previous post, perhaps I can get helpful comments on my observation on this one?
I used MAC spoofing to set a different MAC address for one of the NICs in the device (recognised as Realtek 8168/8111 which I know is known to be unreliable, but in this case its used in a lab). Upon removing the setting ('leave blank' states the info tip) the setting did not revert to HW default and remained, even after the device was rebooted and pfSense reinstalled from scratch the MAC address had been changed and in the BIOS screen the device showed the change in MAC - my point being in the BIOS there are no drivers or software at play, the BIOS is displaying the MAC address as reported by the network device.
After creating a thread to suggest this was not typical or expected behaviour - that pfSense had permanently changed the MAC of the HW without warning - I received a number of comments suggesting this was exactly that; both expected and typical (and obvious and that I was simply ignorant).
I have now tried the same after adding the following network adapters, and found that in each case, removing the setting immediately reverts the MAC address back to the HW default without requiring a reboot:
HP NC365T
Intel x540-T1
Intel x520-T2
Intel I219-LMPossibly coincidentally, upon replacing the network adapter that the MAC had been permanently changed, the pfSense box immediately began to work as expected before I started investigating these issues and posting on this forum (for a number of days now), so without any way to prove it, it may be that the ethernet adapter was always faulty, or that using pfSense MAC spoofing had other undesired consequences and rendered that adapter permanently problematic.
So for the benefit of others I have written this thread as a warning and for information.
It will no doubt attract smite and numerous comments below continuing to suggest "yeah i knew that of course, i just decided not to tell you before as I would rather spend my time trolling"
-
Thanks to mods for deleting my previous post, perhaps I can get helpful comments on my observation on this one?
You renamed your previous post to "pfsense" and replaced first post with a dot. See attached. There was not much left to do after that.
It will no doubt attract smite and numerous comments below continuing to suggest "yeah i knew that of course, i just decided not to tell you before as I would rather spend my time trolling"
I suggest you take a break from from our forum because you seem to have an attitude problem. Once you cool down, understand that help on this forum is on a voluntary basis and that mutual respect is required.
-
The behaviour you're seeing with the Intel NICs is what I would expect to happen. I've never seen the MAC spoofing applied permanently and it's hard to see how it could but clearly it did in your case.
My previous advice in the other thread now seems obsolete. I had assumed those were on board NICs as they appeared in the BIOS but you say you removed them so that's not the case.
If it was a dual port port card though the MACs will still have been consecutive so you can guess what the other one was and try spoofing it back.
Realtek NICs enjoy a pretty poor reputation in FreeBSD/pfSense but this is the firts time I've seen one fail in this way.
Steve
-
Thanks Steve
The HP NIC uses a Broadcom chip so its the behaviour for the majority, not just Intel it seems.
To clarify the NIC i experienced issues with were on board, the testing of the other NICs behaviour with the spoofing option was in a different device (with PCIe slots).
The problem device with onboard NICs is a Partaker B5 which has been reported in this forum and in a blog post as being not just reliable but recommended, hence my researched decision to use it for this project: https://forum.pfsense.org/index.php?topic=114945.msg639418#msg639418
As for spoofing the MAC back, I have tried that by guessing the original address, but I vaguely recall they were not consecutive (it stood out as I would have expected the same). Irrespective, the behaviour is the same and no traffic is being passed between the two adapters leaving me suspecting one is faulty; either it was DOA or the MAC change broke it.
-
What does your dmesg show for the mac of the device when you boot?
Its not out of the realm of possibility that nic might not function correctly with a mac that outside of its vendor assigned space.
Without your specific hardware to play with its not possible to test your specifics.. But a DOA nic is also quite possible.
I recall an issue years and years ago where a dd-wrt firmware would set the mac to a specific value.. And not an issue unless someone else on your isp network was also using dd-wrt and got an ip first ;) So you had to make sure you corrected the mac setting. Or you were trying to use multiple devices in the same network, etc.
Unless a device on the same layer 2 is trying to use the same mac, or you have say set your mac as say a multicast mac - had a device from current cost back in the day that their devices had this.. PITA caused issues with getting an IP in specific scenarios.. And they had not way to fix it without sending the device in, etc. You shouldn't really have any issues… You would think the original mac should be reported in the dmesg? Been so long that had to play with any sort of issues with macs gotten a bit rusty ;)
-
What does your dmesg show for the mac of the device when you boot?
Its not out of the realm of possibility that nic might not function correctly with a mac that outside of its vendor assigned space.
Without your specific hardware to play with its not possible to test your specifics.. But a DOA nic is also quite possible.
I recall an issue years and years ago where a dd-wrt firmware would set the mac to a specific value.. And not an issue unless someone else on your isp network was also using dd-wrt and got an ip first ;) So you had to make sure you corrected the mac setting. Or you were trying to use multiple devices in the same network, etc.
Unless a device on the same layer 2 is trying to use the same mac, or you have say set your mac as say a multicast mac - had a device from current cost back in the day that their devices had this.. PITA caused issues with getting an IP in specific scenarios.. And they had not way to fix it without sending the device in, etc. You shouldn't really have any issues… You would think the original mac should be reported in the dmesg? Been so long that had to play with any sort of issues with macs gotten a bit rusty ;)
I dont recall seeing the MAC in the on screen messages but the oem/model is shown, the recognised model shows as "Realtek 8168/8111 B/C/CP/D/DP/E/F/G" - the chip used is an 8168E (is that the full output of dmesg? never heard of dmesg before).
The original MAC that was spoofed was from my laptop, but as it was on the WAN side there were no issues connecting from my laptop to the LAN for the web config. I then changed the MAC to the subsequent value of the other network port (its got 2) so it was in the RealTek vendor range, but it made no difference, still no traffic between the two ports in pfSense.
I added a USB ethernet adapter and that worked fine.
I suppose the next tests are to swap the two ports so the 'problem' port is LAN and the untouched port is WAN and see if i can get it working. And also clone the MAC again but this time use the preceding value - although as i said in a previous post I vaguely recall that they were not consecutive when I received the device so i am not hopeful this will have any positive effect.
-
dmesg from console/ssh of pfsense..
So example here is igb0 from a sg4860
igb0: <intel(r) 1000="" pro="" network="" connection,="" version="" -="" 2.5.3-k="">port 0x1000-0x101f mem 0xdfc00000-0xdfc1ffff,0xdfc20000-0xdfc23fff irq 18 at device 0.0 on pci3
igb0: Using MSIX interrupts with 3 vectors
igb0: Ethernet address: 00:08:a2:0c:e6:24
igb0: Bound queue 0 to cpu 0
igb0: Bound queue 1 to cpu 1
igb0: netmap queues/slots: TX 2/1024, RX 2/1024</intel(r)> -
Yes the re(4) driver should show that too. Though if the BIOS reads it as the spoofed address I would expect the boot log to reflect that also:
[2.4.3-RELEASE][admin@apu.stevew.lan]/root: dmesg | grep re0 re0: <realtek 8111="" 8168="" b="" c="" cp="" d="" dp="" e="" f="" g="" pcie="" gigabit="" ethernet="">port 0x1000-0x10ff mem 0xf7a00000-0xf7a00fff,0xf7900000-0xf7903fff irq 16 at device 0.0 on pci1 re0: Using 1 MSI-X message re0: ASPM disabled re0: Chip rev. 0x2c000000 re0: MAC rev. 0x00200000 miibus0: <mii bus="">on re0 re0: Using defaults for TSO: 65518/35/2048 re0: Ethernet address: 00:0d:b9:37:30:10 re0: netmap queues/slots: TX 1/256, RX 1/256</mii></realtek>
The rtl8111 chip is vey common (presumably because it's cheap!). There must be something special about your card, or broken.
It would be interesting to see the pciconf output showing the actual chip used there.
[2.4.3-RELEASE][admin@apu.stevew.lan]/root: pciconf -lv | grep re0 re0@pci0:1:0:0: class=0x020000 card=0x012310ec chip=0x816810ec rev=0x06 hdr=0x00
However I'm not sure there's a huge amount we can do here.
Steve