Updating MAC for a reserved IP problem
-
Can anyone please recommend me how I can replace network interface cards and keep the same IPs and not get those clients locked out?
-
@pfpv don't use static arp.. With a static arp, your telling pfsense IP 1.2.3.4 is mac abc..
Even if you had out 1.2.3.4 to mac xyz, its not going to work because pfsense arp cache for 1.2.3.4 is abc.. So he is not going to be able to talk to 1.2.3.4 at mac xyz.
If you want new nic at mac def to get IP 1.2.3.4, then set that up as a reservation.. There you go - done.. You can either do that by deleting the old reservation and creating a new one, or just by editing the reservation.
You prob want to flush the arp cache on pfsense, after you have deleted the static arp setting.. Atleast the arp chache entry for 1.2.3.4 on mac abc..
-
@johnpoz, thanks. I am using reservations, too. Static ARP is in addition to that.
Without static ARP how do I achieve what I described - connected unknown devices and those with spoofed MACs (or those with manually assigned IPs) don't get access to the network?
-
@pfpv here...
I have a reservation for my pc.. at this mac B0-4F-13-0B-FD-16
I changed the reservation to a different mac B0-4F-13-0B-EC-15
I changed my clients mac to B0-4F-13-0B-EC-15 and bobs your uncle new mac on the old IP..
I just did it this way to simulate what your doing your changing the mac that gets that IP via reservation by using a new nic... I don't have a nic handy to change to, so just changed the mac of my current one to simulate a different nic.
-
@johnpoz, thanks again. I see from your screenshot that you also use static ARP. Did you flush the ARP cache? How? There is an ARP Table in the Diagnostics tab. But I believe when I tried to delete the entry for the NIC I had already removed from the network it wasn't there. But the new NIC didn't get a new IP anyway.
-
@pfpv said in Updating MAC for a reserved IP problem:
also use static ARP.
Where are you seeing that - I have a reservation, that is different than a static arp..
A static arp is in the arp table of pfsense that say ip 1.2.3.4 is mac ABC.. that has nothing to do with dhcp specifically... You can have pfsense set a static arp entry from there, but its completely different things.. And last time I looked there were issues with it sticking anyway.. Here is some advice - if you do not understand completely what some option does that is not checked by default - do not check it ;)
-
@johnpoz, there are checkmarks under Static ARP in the first column in the tables you posted earlier. I have them too but once I uncheck the option "Create an ARP Table Static Entry for this MAC & IP Address pair" for a reservation the checkmark disappears. How come you have them when this option is not selected in your case?
Below is my example. For the first one the option is on, for the second is off.
-
@pfpv oh your correct, that was left over from another test about static arps not sticking.. Thanks for pointing that out.. I forgot to uncheck those when I was done testing..
Now when you update the reservation, and you are using static arps, it should update the static arp entry to your new mac.. But if that doesn't happen you could have a bad day.
edit:
Do you want static arp? Do you know what static arp is? Do you have a need/want for them.. Most likely not.. Which is why it default to not using them.. It would be special use case where you would want/need to set those.. If you do not fully understand what they are, I would uncheck doing them.. -
@johnpoz, It doesn't happen. So, something is wrong in pfSense then.
Can you tell me how to flush the static ARP cache? Maybe it will help.
-
@pfpv - look in your arp table.. for the IP..
What does it show?
Make sure you just uncheck static arp in the dhcp settings... And then look at your arp table, does it show an expire time?
You can flush the whole cache with -d -a
[23.09.1-RELEASE][root@sg4860.home.arpa]/root: arp -d -a 10.1.1.128 (10.1.1.128) deleted 10.1.1.129 (10.1.1.129) deleted 10.1.1.1 (10.1.1.1) deleted 192.168.110.110 (192.168.110.110) deleted 192.168.6.101 (192.168.6.101) deleted 192.168.4.76 (192.168.4.76) deleted 192.168.4.77 (192.168.4.77) deleted 192.168.4.78 (192.168.4.78) deleted 192.168.4.79 (192.168.4.79) deleted 192.168.4.72 (192.168.4.72) deleted 192.168.4.201 (192.168.4.201) deleted 192.168.4.73 (192.168.4.73) deleted 192.168.4.203 (192.168.4.203) deleted 192.168.4.71 (192.168.4.71) deleted 192.168.4.65 (192.168.4.65) deleted 192.168.4.61 (192.168.4.61) deleted 192.168.4.62 (192.168.4.62) deleted 192.168.4.63 (192.168.4.63) deleted 192.168.4.217 (192.168.4.217) deleted 192.168.4.57 (192.168.4.57) deleted 192.168.4.89 (192.168.4.89) deleted 192.168.4.58 (192.168.4.58) deleted 192.168.4.59 (192.168.4.59) deleted 192.168.4.53 (192.168.4.53) deleted 192.168.4.214 (192.168.4.214) deleted 192.168.4.55 (192.168.4.55) deleted 192.168.4.80 (192.168.4.80) deleted 192.168.4.209 (192.168.4.209) deleted 192.168.4.81 (192.168.4.81) deleted 192.168.4.49 (192.168.4.49) deleted 192.168.4.50 (192.168.4.50) deleted 192.168.7.10 (192.168.7.10) deleted 192.168.7.5 (192.168.7.5) deleted 192.168.7.99 (192.168.7.99) deleted 192.168.7.3 (192.168.7.3) deleted 192.168.7.98 (192.168.7.98) deleted 192.168.7.97 (192.168.7.97) deleted 192.168.7.96 (192.168.7.96) deleted 192.168.7.95 (192.168.7.95) deleted 192.168.7.94 (192.168.7.94) deleted 192.168.200.10 (192.168.200.10) deleted 192.168.3.10 (192.168.3.10) deleted 192.168.3.99 (192.168.3.99) deleted 192.168.3.32 (192.168.3.32) deleted 192.168.2.203 (192.168.2.203) deleted 192.168.2.200 (192.168.2.200) deleted 192.168.2.13 (192.168.2.13) deleted 192.168.2.2 (192.168.2.2) deleted 192.168.2.3 (192.168.2.3) deleted 192.168.2.198 (192.168.2.198) deleted 192.168.2.4 (192.168.2.4) deleted 192.168.2.221 (192.168.2.221) deleted 192.168.2.50 (192.168.2.50) deleted 209.122.48.1 (209.122.48.1) deleted 192.168.9.99 (192.168.9.99) deleted 192.168.9.98 (192.168.9.98) deleted 192.168.9.100 (192.168.9.100) deleted 192.168.9.10 (192.168.9.10) deleted [23.09.1-RELEASE][root@sg4860.home.arpa]/root:Or you can delete specific IP arp, etc. But I would make sure your not using static arp via dhcp first
-
@johnpoz said in Updating MAC for a reserved IP problem:
Do you want static arp? Do you know what static arp is? Do you have a need/want for them.. Most likely not.. Which is why it default to not using them.. It would be special use case where you would want/need to set those.. If you do not fully understand what they are, I would uncheck doing them..
I explained earlier why I wanted them. So, unknown devices, those with spoofed MACs and manually assigned IPs don't get access to my network.
But I suppose if I want to change NICs I need to disable static ARP. Would it be sufficient to uncheck "Create an ARP Table Static Entry for this MAC & IP Address pair" for the affected clients only and uncheck "Enable Static ARP entries" in the main DHCP server section? I think I tried that. I think I need to flash the ARP cache properly.
-
@pfpv said in Updating MAC for a reserved IP problem:
those with spoofed MACs and manually assigned IPs don't get access to my network.
taht is not how static arps work.. Did you setup dhcp to deny unknown macs? If not its just going to get an IP out of dhcp pool..
Sure that could prevent someone from using same IP as some other device - but that mostly would cause issues with duplicate IP addresses and break stuff for the other client, etc. and is normally noticed very quickly.. Who is going to be spoofing mac/IP address pairs on your network??
-
@johnpoz, I did setup dhcp to deny unknown macs. But not all my devices are up all the time. And static IPs can be assigned on devices that are not reserved in my pfSense.
As to who is going to spoof MACs. I read that some IP cameras start changing their MACs trying to call home. Hopefully I don't have such cameras. I plan to wire POE cameras outside and I don't want someone unplug my camera and plug in their device instead. And last, my kids may learn how to spoof MACs in order to go around the restrictions, unlikely though.
But it's not the point. This is a good security system. I worked for a few universities and they did just that. If you want to plug a new device, give its MAC to the sysadmins. Otherwise, no access to the network. The system works in my case and the geek in me wants to use it even if I don't probably really need it.
-
@johnpoz said in Updating MAC for a reserved IP problem:
Make sure you just uncheck static arp in the dhcp settings... And then look at your arp table, does it show an expire time?
It's strange. I haven't unchecked anything yet but many entries in the ARP table show "Expires in xxxx seconds" where xxxx is 1200 maximum and below. Some show "Permanent". I don't see any correlation why some would be expiring and some permanent. All should be permanent. Is there any explanation to this?
And thank you for explaining how to flush the ARP cache.
-
@pfpv said in Updating MAC for a reserved IP problem:
I read that some IP cameras start changing their MACs trying to call home.
Yeah I find that highly highly unlikely.. And would be pointless if you have your cameras on their own isolated vlan anyway, which would be best practice.. They could change their mac addresses all day long, or their ips.. not going to do them any good.
You know who does change their macs all the time - your freaking phone ;) You know protect your privacy ;)
-
@pfpv said in Updating MAC for a reserved IP problem:
I don't see any correlation why some would be expiring and some permanent.
there was a thread a while back - there is something not right with statics.. They change to dynamic or you see crazy long numbers for the expire time.. I do believe there is a redmine on it..
Thats why I had mine set as static, that was from when playing with it.. But look here 9.10 is still set to static but its currently showing as dynamic
then if I go into the reservation and hit save it goes to perm, but then expires, then perm.. And prob go to dynamic here after a while..
Let me see if I can dig up that redmine
There was a patch even at some point, but not sure if that fixed it, or then later there was a regression.. I would use static to be honest, and if you really need them, I would set them directly via arp command..
edit: here is the thread I was remembering
https://forum.netgate.com/topic/184155/static-arp-in-dhcp-overwrittenIn that thread there is a link to a redmine, etc.
-
@johnpoz said in Updating MAC for a reserved IP problem:
Yeah I find that highly highly unlikely.. And would be pointless if you have your cameras on their own isolated vlan anyway, which would be best practice.. They could change their mac addresses all day long, or their ips.. not going to do them any good.
https://ipcamtalk.com/threads/wifi-cameras-changing-mac-id.55347/
https://www.reddit.com/r/wyzecam/comments/gmvuc4/cameras_change_their_mac_addresses/
https://www.reddit.com/r/Ring/comments/z1uyq7/ring_stickup_elite_uses_random_mac_address/
And it doesn't seems to be intentional like in phones for "privacy". Some people think this was done in order to go around restrictions and phone home. Maybe one day I will move my cameras to a separate VLAN and block its access to the internet.You know who does change their macs all the time - your freaking phone ;) You know protect your privacy ;)
Yes, all phones are set to use device MAC.
-
@johnpoz said in Updating MAC for a reserved IP problem:
In that thread there is a link to a redmine, etc.
Thanks. I have a feeling that problem may have something to do with my struggle. The complaint is that static ARP entries become non-static but I think they continue to be static. If you reread my OP I tried everything when changing a NIC. I updated the MAC in the static mapping. I disabled static ARP, I deleted the ARP cache entry for the old NIC. I rebooted pfSense. The old MAC was nowhere in the system, yet the new card didn't get the old IP but the old one did.
The issue in that redmine never affected me. I didn't even know it was there. WOL always worked, devices were always getting the IPs they were mapped to.
I can only wait for 2.8.0 release. I moved from 23.09.1 to 2.7.2.
-
@pfpv said in Updating MAC for a reserved IP problem:
Some people think this was done in order to go around restrictions and phone home
And some people think the black helicopters hover outside their window at night as well ;) Don't mean they are ;) That 2nd thread looks like a specific issue with wyze.. And how they allocate the mac address to the device, etc.. It is not to get around "restrictions" ;)
Your 3rd link wouldn't load.
If your tinfoil hat is causing you to think that, then again put them on their own vlan and who cares what mac address they use, who cares if it changes every 2 hours, etc..
The whole concept of firerwall rules based on specific IP address and even mac filtering is on its way out.. With IPv6 and devices using temp addresses that they just pretty much just randomly create and change for outbound connections, even if you hand them a specific IP.. Makes specific firewall rules by IP pretty impossible to implement.. You also have all these devices that change macs, my phone does it (even though I have said to use devices mac) and my new apple watch has caused me grief sometimes when I notice some odd mac on my wifi network.. Trying to tack down a wifi device with an odd mac is hard, then I check my watch and its using private mac again, even though I told it not too... It think it reverts back on os update, etc.. I will check when the new watch os drops here pretty soon..
So with these sorts of shifts in tech, and how IPv6 is designed to work - your going to need to filter by network, vs allow this IP, but block that IP, etc.
Now segmenting your home network isn't just for fun any more ;)
-
@johnpoz, thanks for the advice. I wasn't looking into the future (which is already now) with IPv6 like you did. And I will look into segmenting my network. For me MACs are still something hardcoded like it was a few years ago before phones started changing them and others followed. By the way, our Android phones never changed MACs once set to device MAC even after major updates. Sounds like Apple is being Apple.
Anyway, features related to static ARP and IP should work properly or should be removed from pfSense. In a few days I will do the dance of changing NICs again and will document better what will go on. I expect the same problems.
