ARP reports bogons

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

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.

johnpoz

@deanfourie said in ARP reports bogans:

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.

No that is not what is happening at all.. It is sending out a probe, asking if anyone has that 172.16.101.11 address.

It then sends dhcp request asking for the IP..

There is nothing odd in your packet capture at all..

https://www.practicalnetworking.net/series/arp/arp-probe-arp-announcement/

edit: here is my pc sending out a arp probe, when I set its IP - its checking that there are nobody using that IP before it actually uses it. Then it sends out a gratuitous arp, the announcement hey this is the IP I am using, here is my mac - in case you want to talk to me ;)

Here is your capture..

Its asking if anyone using that IP, and then it requests that IP.. etc..

If your seeing floods of these from all your clients - maybe your having an issue with dhcp.. But probes are common on a network. And so are dhcp requests or discovers that would be from a source of 0.0.0.0

deanfourie

@johnpoz ok ok it seems I need to go back and study ARP as I thought I had that protocol down. Guess not :(

The next question is, why would I be loosing network and internet access, on then off, on then off. Constantly for like an hour at time?

The client should only request one DHCP lease in the entire night given that it is only connected once to the network correct? So I wouldn't blame DHCP.

Come to think of it, I do remember during the process I was doing a ipconfig and was only getting a link local address.

So something is kicking me off the network and then the DHCP server is unreachable.

stephenw10

Yeah, I don't really expect the pfSense ARP table to end up showing all the client MACs as 0.0.0.0. I don't think I've ever seen that before.
It could be that it does go through that when clients send out their DAD probes but it happens so fast that it's never in the table long enough to see.

But clients should not be doing that spontaneously when they already had a lease, they should just renew that lease. So, yeah, it looks likely to be some dhcp issue and the most common DHCP issue is some rogue dhcp server on the network.

What do the pfSense dhcp logs show when this is happening?

Steve

johnpoz

@deanfourie said in ARP reports bogans:

on then off, on then off. Constantly for like an hour at time?

Well does your client have its gateway in its arp table? Can it query dns? Does it even have an IP?

You sure its not unbound restarting on you - this would mess up internet since dns would be flaky as hell if its restarting ever minute or something. Registering dhcp can do that in your unbound settings.

What is your lease time for your dhcp.. I could see low lease time, lots of clients - they all trying to renew at the same time or near the same time - unbound constantly restarting as clients renew their lease, or get a lease if you have a problem with renewal, etc. etc..

fireodo

@deanfourie Offtopic: would you be so kind and change the subject from "bogans" to "bogons" (helps if someone search something regarding bogons) Thank you!