3CX Debian Instance - IP tables bombarding syslog

[DaveB-Opt]

I'm getting multiple entries on our Debian instance which seem to be having an impact on our server (call quality).
During the evening (when these entries decrease) we're getting a better call quality.
The entries provide a MAC address that's not valid.
What can I do to diagnose these entries?

Sep 3 13:16:01 OMG-3CX-VOIP kernel: [61693.269111] iptables[DOS]: IN=eth0 OUT= MAC=33:33:00:00:00:01:ac:86:74:d9:02:e0:86:dd SRC=fe80:0000:0000:0000:ae86:74ff:fed9:02e0 DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=52 TC=0 HOPLIMIT=1 FLOWLBL=822758 PROTO=UDP SPT=16962 DPT=16962 LEN=12
Sep 3 13:16:11 OMG-3CX-VOIP kernel: [61703.276693] iptables[DOS]: IN=eth0 OUT= MAC=33:33:00:00:00:01:ac:86:74:d9:02:e0:86:dd SRC=fe80:0000:0000:0000:ae86:74ff:fed9:02e0 DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=52 TC=0 HOPLIMIT=1 FLOWLBL=822758 PROTO=UDP SPT=16962 DPT=16962 LEN=12
Sep 3 13:16:21 OMG-3CX-VOIP kernel: [61713.285775] iptables[DOS]: IN=eth0 OUT= MAC=33:33:00:00:00:01:ac:86:74:d9:02:e0:86:dd SRC=fe80:0000:0000:0000:ae86:74ff:fed9:02e0 DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=52 TC=0 HOPLIMIT=1 FLOWLBL=822758 PROTO=UDP SPT=16962 DPT=16962 LEN=12
Sep 3 13:16:31 OMG-3CX-VOIP kernel: [61723.294381] iptables[DOS]: IN=eth0 OUT= MAC=33:33:00:00:00:01:ac:86:74:d9:02:e0:86:dd SRC=fe80:0000:0000:0000:ae86:74ff:fed9:02e0 DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=52 TC=0 HOPLIMIT=1 FLOWLBL=822758 PROTO=UDP SPT=16962 DPT=16962 LEN=12
Sep 3 13:16:41 OMG-3CX-VOIP kernel: [61733.303231] iptables[DOS]: IN=eth0 OUT= MAC=33:33:00:00:00:01:ac:86:74:d9:02:e0:86:dd SRC=fe80:0000:0000:0000:ae86:74ff:fed9:02e0 DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=52 TC=0 HOPLIMIT=1 FLOWLBL=822758 PROTO=UDP SPT=16962 DPT=16962 LEN=12
Sep 3 13:16:51 OMG-3CX-VOIP kernel: [61743.315151] iptables[DOS]: IN=eth0 OUT= MAC=33:33:00:00:00:01:ac:86:74:d9:02:e0:86:dd SRC=fe80:0000:0000:0000:ae86:74ff:fed9:02e0 DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=52 TC=0 HOPLIMIT=1 FLOWLBL=822758 PROTO=UDP SPT=16962 DPT=16962 LEN=12

 

[AWS2P]

Does it comes from outside LAN or can it be a device network card becoming crazy and polluting network ?
Can you temporarily remove outside link and see if problem stops?

 

[DaveB-Opt]

I disabled all incoming traffic from the router and the problem persisted.
Any idea what the MAC address is? It looks far too long to be a regular MAC

 

[AWS2P]

do you have lot of switches on your LAN ?

 

[Evolute IT]

I disabled all incoming traffic from the router and the problem persisted.
Any idea what the MAC address is? It looks far too long to be a regular MAC

Those look like IPV6 addresses, are you using IPv6? If not, try disabling it in 3CX then reboot. See if it persist.

 

[DaveB-Opt]

We have 4 in total

 

[AWS2P]

if they are stacked can you isolate one by one to see if you can reduce where it comes from

 

[DaveB-Opt]

if they are stacked can you isolate one by one to see if you can reduce where it comes from

Sure - will have to try that out of hours.

I'm trying to work out how to disable IPV6 as per Frederick's suggestion

 

[Evolute IT]

Sure - will have to try that out of hours.

I'm trying to work out how to disable IPV6 as per Frederick's suggestion

Settings -> Network -> Uncheck "Bind to IPv6".

Then reboot the PBX. Do this out of office hours please!

 

[AWS2P]

in MC

 

[DaveB-Opt]

Thanks all! Will turn this off first and reboot. Appreciate the response.

 

[AWS2P]

in SP3 default network setting will be to IPv4, IPV6 setting cause some weird behavior when network is not fully IPV6

 

[Evolute IT]

Thanks all! Will turn this off first and reboot. Appreciate the response.

Let us know if it fixed the syslog issue. Should, since all src/dst were IPv6-looking addresses.

If not, then I suggest you run a packet capture and try to find the real source.

 

[DaveB-Opt]

Let us know if it fixed the syslog issue. Should, since all src/dst were IPv6-looking addresses.

If not, then I suggest you run a packet capture and try to find the real source.

Hi. I disabled IPV6 and rebooted but getting the same issues.
I don't really know where to start with identifying that MAC on my network though!

 

[AWS2P]

Did you try a reboot also on router / firewall side? perhaps some cache may remains some settings until a reboot is done.

i'm not an expert in trame analysis but if you capture traffic with wireshark even if this mac adress seems not valid, you can surely filter packets to search where it comes from? ask to someone at ease with wireshark use.

or trivial way is to unstack switchs to reduce and isolate them until you find when it stops and search only on the switch it comes from.

 

[AWS2P]

In my past i was using snmp management on HP openview plateform, this was fantastic tool to manage wide network located everywhere and to find any problem really easily and fix nearly all problems without moving from office

 

[cobaltit]

That MAC address is OpenMesh. Do you have OpenMesh APs? They do some weird bridging stuff on their APs that product a lot of random ARP entries.

 

[DaveB-Opt]

That MAC address is OpenMesh. Do you have OpenMesh APs? They do some weird bridging stuff on their APs that product a lot of random ARP entries.

We do actually. Is this anything to worry about then?
Also, how did you find out it was OpenMesh from 33:33:00:00:00:01:ac:86:74:d9:02:e0:86:dd ?

Thanks

 

[JohnS_3CX]

By looking up ac:86:74:d9:02:e0:86:dd

AC:86:74 is assigned to OpenMesh as the vendor

 

[DaveB-Opt]

By looking up ac:86:74:d9:02:e0:86:dd

AC:86:74 is assigned to OpenMesh as the vendor

Ok thanks. Would you be concerned about the persistent syslog entries?