ARP Table weirdness - Not sure if this is pfSense
-
I'm not sure if pfSense has anything to do with this, or if it's just reporting, but the issue. It looks like pfSense might have corrupted it's arp table (or the switch did), or the workstation did something funky.
TLDR; Why would the prefex of a bunch of NICs change from "90:e2:ba" (Intel Corporate) to "30:5a:3a" (ASUSTek COMPUTER INC.)
The log is below... I've done some redaction, but it makes it easier to see what has changed all the 90:e2:ba:xx:xx:b2 were exactly the same, the 30:5a:3a:yy:yy:24, and the same for the 90:e2:ba:zz:zz:b1. No net to match all those extra digits.
The machine is a multi homed Linux Box (my workstation) running Minux Mint. The 172, is an intel nic on the Asus MB, and the 192, is one port of a 4 port intel nic. There are 2 other ports on the nic in operation, and neither of them s
As of right now: (These are the correct manufacturers)
172.16.XX.16 (em1.XX) is 30:5a:3a:yy:yy:24
192.168.YY.16 (em1.YY) ia 90:e2:ba:zz:zz:b1 onI know there are some sharp people here, I wondering if anyone has any thoughts?
Nov 21 20:15:00 pfsense php[89004]: [pfBlockerNG] Starting cron process. Nov 21 20:16:31 pfsense php[89004]: [pfBlockerNG] No changes to Firewall rules, skipping Filter Reload Nov 21 20:16:31 pfsense php[89004]: Nov 21 20:31:04 pfsense kernel: arp: 172.16.XX.16 moved from 90:e2:ba:xx:xx:b2 to 30:5a:3a:yy:yy:24 on em1.XX Nov 21 20:51:00 pfsense kernel: arp: 172.16.XX.16 moved from 90:e2:ba:xx:xx:b2 to 30:5a:3a:yy:yy:24 on em1.XX Nov 21 21:10:56 pfsense kernel: arp: 172.16.XX.16 moved from 90:e2:ba:xx:xx:b2 to 30:5a:3a:yy:yy:24 on em1.XX Nov 21 21:12:17 pfsense kernel: arp: 192.168.YY.16 moved from 90:e2:ba:zz:zz:b1 to 90:e2:ba:xx:xx:b2 on em1.YY Nov 21 21:12:22 pfsense kernel: arp: 192.168.YY.16 moved from 90:e2:ba:xx:xx:b2 to 90:e2:ba:zz:zz:b1 on em1.YY Nov 21 21:15:00 pfsense php[57763]: [pfBlockerNG] Starting cron process. Nov 21 21:16:23 pfsense php[57763]: [pfBlockerNG] No changes to Firewall rules, skipping Filter Reload Nov 21 21:16:23 pfsense php[57763]: Nov 21 21:30:52 pfsense kernel: arp: 172.16.XX.16 moved from 90:e2:ba:xx:xx:b2 to 30:5a:3a:yy:yy:24 on em1.XX Nov 21 21:50:48 pfsense kernel: arp: 172.16.XX.16 moved from 90:e2:ba:xx:xx:b2 to 30:5a:3a:yy:yy:24 on em1.XX Nov 21 22:10:44 pfsense kernel: arp: 172.16.XX.16 moved from 90:e2:ba:xx:xx:b2 to 30:5a:3a:yy:yy:24 on em1.XX Nov 21 22:12:17 pfsense kernel: arp: 192.168.YY.16 moved from 90:e2:ba:zz:zz:b1 to 90:e2:ba:xx:xx:b2 on em1.YY Nov 21 22:12:22 pfsense kernel: arp: 192.168.YY.16 moved from 90:e2:ba:xx:xx:b2 to 90:e2:ba:zz:zz:b1 on em1.YY Nov 21 22:15:00 pfsense php[58469]: [pfBlockerNG] Starting cron process. Nov 21 22:16:21 pfsense php[58469]: [pfBlockerNG] No changes to Firewall rules, skipping Filter Reload Nov 21 22:16:21 pfsense php[58469]: Nov 21 22:30:40 pfsense kernel: arp: 172.16.XX.16 moved from 90:e2:ba:xx:xx:b2 to 30:5a:3a:yy:yy:24 on em1.XX Nov 21 22:50:36 pfsense kernel: arp: 172.16.XX.16 moved from 90:e2:ba:xx:xx:b2 to 30:5a:3a:yy:yy:24 on em1.XX Nov 21 23:10:32 pfsense kernel: arp: 172.16.XX.16 moved from 90:e2:ba:xx:xx:b2 to 30:5a:3a:yy:yy:24 on em1.XX Nov 21 23:12:17 pfsense kernel: arp: 192.168.YY.16 moved from 90:e2:ba:zz:zz:b1 to 90:e2:ba:xx:xx:b2 on em1.YY Nov 21 23:12:22 pfsense kernel: arp: 192.168.YY.16 moved from 90:e2:ba:xx:xx:b2 to 90:e2:ba:zz:zz:b1 on em1.YY Nov 21 23:15:00 pfsense php[9238]: [pfBlockerNG] Starting cron process. Nov 21 23:23:41 pfsense php[9238]: [pfBlockerNG] No changes to Firewall rules, skipping Filter Reload Nov 21 23:23:41 pfsense php[9238]: Nov 21 23:30:28 pfsense kernel: arp: 172.16.XX.16 moved from 90:e2:ba:xx:xx:b2 to 30:5a:3a:yy:yy:24 on em1.XX Nov 21 23:50:24 pfsense kernel: arp: 172.16.XX.16 moved from 90:e2:ba:xx:xx:b2 to 30:5a:3a:yy:yy:24 on em1.XX -
@guardian said in ARP Table weirdness - Not sure if this is pfSense:
The machine is a multi homed Linux Box (my workstation) running Minux Mint.
Pfsense is just reporting that is saw the IP move to a new mac.. You need to look to your multihomed box for why.. Multihomed is almost never a good idea unless the box that has multiple interfaces is an actual router. Possible duplicate IP(s) normally common reason why you might see this.
BTW - what is the point of hiding rfc1918 space? It gives away nothing... Same with mac addresses - there is no possible way to track those - they are limited to the L2 they are on..
Unless that mac was the mac of your wifi router - it gives away nothing. Now if mac of your wifi router - and your wifi router is in a database - those do exist.. And pretty much everyones wifi ssid and mac are in those.. It doesn't give away anything.
So my pc mac is B0-4F-13-0B-FD-16, and its IP is 192.168.9.100 - what do you think you could do with that info? Other than figure out who the maker of my nic is ;)
edit: here you go for example
Oct 10 09:54:26 kernel arp: 192.168.4.56 moved from d4:a6:51:cf:c5:45 to 50:8a:06:23:d5:0d on igb2.4 Oct 10 09:51:25 kernel arp: 192.168.4.56 moved from 50:8a:06:23:d5:0d to d4:a6:51:cf:c5:45 on igb2.4 Oct 10 09:51:10 kernel arp: 192.168.4.56 moved from d4:a6:51:cf:c5:45 to 50:8a:06:23:d5:0d on igb2.4 Oct 10 09:49:38 kernel arp: 192.168.4.56 moved from 50:8a:06:23:d5:0d to d4:a6:51:cf:c5:45 on igb2.4 Oct 10 09:46:39 kernel arp: 192.168.4.56 moved from d4:a6:51:cf:c5:45 to 50:8a:06:23:d5:0d on igb2.4 Oct 10 09:45:07 kernel arp: 192.168.4.56 moved from 50:8a:06:23:d5:0d to d4:a6:51:cf:c5:45 on igb2.4 Oct 10 09:44:34 kernel arp: 192.168.4.56 moved from d4:a6:51:cf:c5:45 to 50:8a:06:23:d5:0d on igb2.4 Oct 10 09:43:05 kernel arp: 192.168.4.56 moved from 50:8a:06:23:d5:0d to d4:a6:51:cf:c5:45 on igb2.4 Oct 10 09:41:46 kernel arp: 192.168.4.56 moved from d4:a6:51:cf:c5:45 to 50:8a:06:23:d5:0d on igb2.4I had a problem with couple of my lightbulbs having the same IP.. Drove me nuts for a bit on why the lightbulb I was having issues with would sometimes work and sometimes not when I tried to turn it on or off..
-
@johnpoz, thanks for the reply!
@johnpoz said in ARP Table weirdness - Not sure if this is pfSense:
@guardian said in ARP Table weirdness - Not sure if this is pfSense:
The machine is a multi homed Linux Box (my workstation) running Minux Mint.
Pfsense is just reporting that is saw the IP move to a new mac.. You need to look to your multihomed box for why..
That's what I was thinking, but I wanted to see if there was something that I wasn't aware of. I suspect the problem was caused by playing with jails on my TrueNAS box. I messed up the network for awhile until I gave up and reverted my changes. It's quite possible I ended up with a duplicate IP, but I don't know if that would mess up the Linux box.
@johnpoz said in ARP Table weirdness - Not sure if this is pfSense:
Multihomed is almost never a good idea unless the box that has multiple interfaces is an actual router.
I have been doing it for several years with no obvious problem, but that doesn't mean that there isn't something that I'm not aware of. Can you please expand on this a bit?
@johnpoz said in ARP Table weirdness - Not sure if this is pfSense:
BTW - what is the point of hiding rfc1918 space? It gives away nothing... Same with mac addresses - there is no possible way to track those - they are limited to the L2 they are on..
An overabundance of caution.... I didn't know if it could possibly create an issue. Better safe than sorry.... over the years I've found that AI is making things a problem that I couldn't even imagined being a problem several years ago.
The main reason was ease of analysis. When I was figuring out what was happening I replaced each item with a different value and that made it very easy to see the different entities.
-
@guardian said in ARP Table weirdness - Not sure if this is pfSense:
made it very easy to see the different entities.
Maybe to you that gets what is what and your just replacing a 3 with a X, etc.. But from someone coming and taking a look not so much.. For one there is always the question did they F something up in their replacement. Its easier when its a picture or actual paste without anything hidden or replaced.. For all we know when someone "hides" something they are actually hiding what is causing the problem.
Multihomed for starters is a hole in your security - that box can touch all networks without having to go through a firewall. It can lead to asymmetrical traffic flow. Let me talk to host 192.168.2.100 from 192.168.1.50 box through the router.. But that 192.168.2.100 also has an interface in 192.168.1 network and answers from there. So the SA or the S is never seen but the syn,ack is etc..
Sure say a VM can hosts VMs on different networks. But those IPs should only be to talk to the vms and devices on that specific network. The host doesn't actually need an IP in that network for example. The vm host should be talked to on its management IP, and it should only have 1 of those in 1 network.
-
Multihomed clients make it much easier to introduce routing issues unintentionally. I can't tell you the number of support tickets I've handled that were asymmetric routing from specific clients that had interfaces in multiple subnets. It can produce confusing symptoms and be not at all obvious.
The only time you might want to do it, IMO, is if the alternative routing traffic through the firewall causes a very large loading. So if you have multiple 10G subnets for example. Routing that through pfSense will be slower and cause a load on the firewall that would affect other traffic.
If you find yourself doing that though you might consider a layer 3 switch at that point.Steve
-
@stephenw10 ^exactly but if your multihoming with a SAN only network or a backup network. Where the server/host has its own private network with say your nas or backup server that is easy to make sure no routing problems.
But yeah as Steve states - lots of issues with users just messing it up.. And I wouldn't multihome a box into multiple networks that other devices are going to talk to it from, etc.
Example I have my pc and nas multihomed so they can talk to each other over 2.5ge - but this is an isolated network that only they are in. These IPs have no gateway.. Its just a storage network.
