ARP reports bogons

deanfourie

So I am getting these, reporting on multiple hosts during which I loose complete network and internet access.
There are 100's of them a day.

Any ideas?

arpwatch 40642 bogon 0.0.0.0 c0:33:5e:31:9e:87

stephenw10

DHCP requests? Though I wouldn't expect arpwatch to trigger on those since that's expected.

What is that MAC address? Does it usually have a real IP?

Steve

johnpoz

@stephenw10 said in ARP reports bogans:

Though I wouldn't expect arpwatch to trigger on those since that's expected.

Wouldn't that depend on if you have it set not to report those.

stephenw10

Or that setting for 0.0.0.0 specifically. I don't use ARP watch other than to test it installs/runs.

Edit: The bogons/bogans typo amuses me everytime.

deanfourie

@johnpoz well I'm not sure I can block boons on '0.0.0.0' as isn't this a DHCP broadcast address?

Also, this is not arpwatch, that's from my arp table directly

deanfourie

@stephenw10 yes, it's ARP so it has to have a real IP.

It's updating my local ARP table to 0.0.0.0 for clients hence why everything just goes offline.

Arp says who has 182.168.0.4, 192.168.0.4 is at 0.0.0.0

And for all hosts

stephenw10

@deanfourie said in ARP reports bogans:

I'm not sure I can block boons on '0.0.0.0' as isn't this a DHCP broadcast address?

That setting doesn't block bogons it just stops ARP Watch reporting them. Because they are expected in a DHCP environment.
ARP Watch doesn't update anything, it just watches for ARP traffic and alerts on unexpected activity.

Steve

deanfourie

@stephenw10 so in my case that's not going to help.

johnpoz

@deanfourie so your saying when you look at your arp table you see no IPs, only 0.0.0.0?

Or on pfsense itself

stephenw10

@deanfourie said in ARP reports bogans:

so in my case that's not going to help.

It will prevent arpwatch reporting bogons which is what you initially reported.

It won't do anything about any connectivity issues you may be seeing. It's a symptom of that if anything. Or those could just be expected reports from DHCP clients is their lease is expiring before it renews, which shouldn't happen.

johnpoz

@deanfourie said in ARP reports bogans:

Arp says who has 182.168.0.4, 192.168.0.4 is at 0.0.0.0

That doesn't even make and sense - your saying you see this via a sniff.. Could you please attach this pcap..

So for example here are some arps, look at the request and the reply.. Did you mean it gives a mac of 00:00:00:00:00:00?

From the pcap you could see mac of who is answering.. when there is a broadcast for who has ipaddress.

deanfourie

@stephenw10 but it's got nothing to do with arpwatch reporting bogons.

The initial post is a paste straight from my pfSense ARP table, nothing to do with arpwatch.

The bogons are not "reporting", they are actually dynamically updating my ARP table to reflect hosts being at 0.0.0.0 rather then their legitimate IP.

IE. If I got to my pfSense ARP table, hosts show as xx:xx:xx:xx:xx:1b 0.0.0.0
xx:xx:xx:xx:xx:2b 0.0 0.0

And so on

deanfourie

@johnpoz Sure, here is a small pcap I managed to get. Not much but something in there.
I had to zip it as the format is not supported.

packetcapture.zip

deanfourie

@johnpoz and from a recent packet capture this morning.

08:48:46.351720 ARP, Request who-has 172.16.101.11 tell 0.0.0.0, length 46
08:48:47.234162 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 334
08:48:47.357364 ARP, Request who-has 172.16.101.11 tell 0.0.0.0, length 46
08:48:48.360040 ARP, Request who-has 172.16.101.11 tell 0.0.0.0, length 46
09:29:00.033120 ARP, Request who-has 172.16.101.11 tell 0.0.0.0, length 46
09:29:01.026670 ARP, Request who-has 172.16.101.11 tell 0.0.0.0, length 46
09:29:01.257459 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 334
10:09:16.459259 ARP, Request who-has 172.16.101.11 tell 0.0.0.0, length 46
10:09:17.458890 ARP, Request who-has 172.16.101.11 tell 0.0.0.0, length 46
10:09:18.244000 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 334
10:09:18.464750 ARP, Request who-has 172.16.101.11 tell 0.0.0.0, length 46
11:59:58.772823 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 302
11:59:59.768631 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 302
11:59:59.790965 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 312
12:13:59.758421 ARP, Request who-has 172.16.101.19 tell 0.0.0.0, length 46
12:13:59.866618 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 340
12:14:00.390573 ARP, Request who-has 172.16.101.19 tell 0.0.0.0, length 46
12:14:01.389049 ARP, Request who-has 172.16.101.19 tell 0.0.0.0, length 46

stephenw10

@deanfourie said in ARP reports bogans:

arpwatch 40642 bogon 0.0.0.0 c0:33:5e:31:9e:87

Looks like an arpwatch entry in the system log to me...

But clearly that is just a symptom of something actually updating the ARP table with 0.0.0.0.

And it looks like that thing is clients sending ARP requests with invalid source IPs.

In that last pcap are those all the same host? You see that for all the hosts on the subnet when that happens?

Those are bogus ARP requsts though. There are no replies because there's no way to reply to 0.0.0.0. That's bizarre!

stephenw10

Oh Ok, looks like that's part of duplicated address detection. But I only expect that to happen when the host interface first comes up. Before it gets an IP.

Hmm, might have to try to capture what happens when this event starts. What triggers the initial error.

deanfourie

@stephenw10 Yes its very suspicious behavior.

This just randomly starts flooding hosts for say 30 - 50 minutes at peak time of internet access.

I think its a DDoS.

deanfourie

@stephenw10 ok fair call, but what I was getting at was actually that the ARP table was being updated.

johnpoz

@stephenw10 that is an arp probe from whatever that ASUSTek device is with mac 78:24:af:36:1a:08

What is odd about it? he is asking if anyone is using that IP, then he sends out a dhcp request asking for that IP.

But you need to look to that client to why its acting like it is.. Not pfsense issue with anything, but probes are common, and so are dhcp requests.

Is the client bouncing between networks, say different wifi networks?

Is it a wifi device? Maybe coming out of sleep/standby - a tablet/phone maybe?

deanfourie

@johnpoz How is it not odd,

The client is asking for a IP address of a host on the LAN, and being told it is @ 0.0.0.0 - these are bogus ARP requests.

That has nothing to do with DHCP.

Also, it is not just happening to one host, it happens to all hosts.

It is a ethernet client 1a:08 in specific.